Re: Using Postgres to store high volume streams of sensor readings
От | Ciprian Dorin Craciun |
---|---|
Тема | Re: Using Postgres to store high volume streams of sensor readings |
Дата | |
Msg-id | 8e04b5820811212250o3bbb6c73q6d23498a1c43dd32@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Using Postgres to store high volume streams of sensor readings ("Diego Schulz" <dschulz@gmail.com>) |
Ответы |
Re: Using Postgres to store high volume streams of sensor
readings
|
Список | pgsql-general |
On Fri, Nov 21, 2008 at 10:26 PM, Diego Schulz <dschulz@gmail.com> wrote: > > > On Fri, Nov 21, 2008 at 9:50 AM, Ciprian Dorin Craciun > <ciprian.craciun@gmail.com> wrote: >> >> Currently I'm benchmarking the following storage solutions for this: >> * Hypertable (http://www.hypertable.org/) -- which has good insert >> rate (about 250k inserts / s), but slow read rate (about 150k reads / >> s); (the aggregates are manually computed, as Hypertable does not >> support other queries except scanning (in fact min, and max are easy >> beeing the first / last key in the ordered set, but avg must be done >> by sequential scan);) >> * BerkeleyDB -- quite Ok insert rate (about 50k inserts / s), but >> fabulos read rate (about 2M reads / s); (the same issue with >> aggregates;) >> * Postgres -- which behaves quite poorly (see below)... >> * MySQL -- next to be tested; > > I think it'll be also interesting to see how SQLite 3 performs in this > scenario. Any plans? > > regards > > diego I would try it if I would know that it could handle the load... Do you have some info about this? Any pointers about the configuration issues? Ciprian.
В списке pgsql-general по дате отправления: