From: | "Ciprian Dorin Craciun" <ciprian(dot)craciun(at)gmail(dot)com> |
---|---|
To: | "Diego Schulz" <dschulz(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Using Postgres to store high volume streams of sensor readings |
Date: | 2008-11-22 06:50:45 |
Message-ID: | 8e04b5820811212250o3bbb6c73q6d23498a1c43dd32@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Nov 21, 2008 at 10:26 PM, Diego Schulz <dschulz(at)gmail(dot)com> wrote:
>
>
> On Fri, Nov 21, 2008 at 9:50 AM, Ciprian Dorin Craciun
> <ciprian(dot)craciun(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2008-11-22 08:58:02 | Re: pgAdmin error |
Previous Message | David | 2008-11-22 06:35:19 | pgAdmin error |