From: | Esmin Gracic <esmin(dot)gracic(at)gmail(dot)com> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Need suggestion |
Date: | 2011-06-04 10:18:35 |
Message-ID: | BANLkTiks4eHUuv7xC1r0ABW_TRF1ddG38g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
*(or files if you organize it that way)*
if the problem was so simple, I guess Carl would not have asked the question
in the first place.
there could be one sqlite db file for each day, week or month (1TB over 365
days). Something like partitioning on date dimension.
Actually, sqlite scales well up to 2 TB so it's not so *unwonderfull* idea
even using one file per year (especially on XFS file system).
I would use postgres + sqlite as image storing engine.
"...but is must be searchable, and any document must be retrieved within 1
hour..." - this is not bleeding edge requirement, so I would use filesystem
if this was 10 sec or something, but having 1 hour timeframe would
definitely made me choose db over filesystem.
Esmin.
On Sat, Jun 4, 2011 at 12:44 AM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> On 06/03/11 3:09 PM, Esmin Gracic wrote:
>
>> another option is using sqlite for storing images. All data is in single
>> file. (or files if you organize it that way) easier backup etc... you have
>> some db benefits and retaining solid speed vs file system. Haven't used
>> this, but seems as viable option to explore.
>>
>
> a single multi-terabyte file? what a *wonderful* idea. *NOT*
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Smark | 2011-06-04 11:12:04 | Converting an hstore into a key/value record |
Previous Message | CSS | 2011-06-04 03:38:38 | Tuning for a tiny database |