Re: Storing sensor data
От | Ivan Voras |
---|---|
Тема | Re: Storing sensor data |
Дата | |
Msg-id | 9bbcef730905280758p4400d600k8e5e4345cd07100@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Storing sensor data (Nikolas Everett <nik9000@gmail.com>) |
Список | pgsql-performance |
2009/5/28 Nikolas Everett <nik9000@gmail.com>: > Option 1 is about somewhere between 2 and 3 times more work for the database > than option 2. Yes, for writes. > Do you need every sensor update to hit the database? In a situation like We can't miss an update - they can be delayed but they all need to be recorded. > this I'd be tempted to keep the current values in the application itself and > then sweep them all into the database periodically. If some of the sensor > updates should hit the database faster, you could push those in as you get > them rather than wait for your sweeper. This setup has the advantage that > you can scale up the number of sensors and the frequency the sensors report > without having to scale up the disks. You can also do the sweeping all in > one transaction or even in one batch update. It would be nice, but then we need to invest more effort in making the front-end buffering resilient.
В списке pgsql-performance по дате отправления: