Re: Need suggestion

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
>

In response to

Browse pgsql-general by date

  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