Re: Using Postgres to store high volume streams of sensor readings

Поиск
Список
Период
Сортировка
От Sam Mason
Тема Re: Using Postgres to store high volume streams of sensor readings
Дата
Msg-id 20081121144934.GX2459@frubble.xen.chris-lamb.co.uk
обсуждение исходный текст
Ответ на Using Postgres to store high volume streams of sensor readings  ("Ciprian Dorin Craciun" <ciprian.craciun@gmail.com>)
Ответы Re: Using Postgres to store high volume streams of sensor readings  (Greg Smith <gsmith@gregsmith.com>)
Список pgsql-general
On Fri, Nov 21, 2008 at 02:50:45PM +0200, Ciprian Dorin Craciun 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;

It's not quite what you're asking for; but have you checked out any
of the databases that have resulted from the StreamSQL research?  The
Borealis engine[1] looks like the most recent development, but I'm
not sure how you are with academic style code.  I've never used it
before, but it sounds as though it was designed for exactly your sort of
problem.


  Sam

 [1] http://www.cs.brown.edu/research/borealis/public/

В списке pgsql-general по дате отправления:

Предыдущее
От: Scara Maccai
Дата:
Сообщение: [Fwd: Re: return MAX and when it happened]
Следующее
От: "Ciprian Dorin Craciun"
Дата:
Сообщение: Re: Using Postgres to store high volume streams of sensor readings