Re: Storing sensor data
От | Nikolas Everett |
---|---|
Тема | Re: Storing sensor data |
Дата | |
Msg-id | d4e11e980905280638j41f25d0fq594e181e36cd0d62@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Storing sensor data (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Storing sensor data
|
Список | pgsql-performance |
Option 1 is about somewhere between 2 and 3 times more work for the database than option 2.
Do you need every sensor update to hit the database? In a situation like 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 c0an 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.
Do you need every sensor update to hit the database? In a situation like 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 c0an 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.
On Thu, May 28, 2009 at 9:31 AM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
Amen. Do that.
Ivan Voras wrote:Whichever design you choose, you should also consider partitioning the data.The volume of sensor data is potentially huge, on the order of 500,000
updates per hour. Sensor data is few numeric(15,5) numbers.
Amen. Do that.
В списке pgsql-performance по дате отправления: