Re: Large objetcs performance

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Large objetcs performance
Дата
Msg-id b42b73150704120642p239ea6ddkef9de07afc5921f2@mail.gmail.com
обсуждение исходный текст
Ответ на Large objetcs performance  ("Alexandre Vasconcelos" <alex.vasconcelos@gmail.com>)
Список pgsql-performance
On 4/4/07, Alexandre Vasconcelos <alex.vasconcelos@gmail.com> wrote:
> We have an application subjected do sign documents and store them
> somewhere. The files size may vary from Kb to Mb. Delelopers are
> arguing about the reasons to store files direcly on operating system
> file system or on the database, as large objects. My boss is
> considering file system storing, because he is concerned about
> integrity, backup/restore corruptions. I'd like to know some reasons
> to convince them to store these files on PosgtreSQL, including
> integrity, and of course, performance. I would like to know the file
> system storing disadvantages as well.

This topic actually gets debated about once a month on the lists :-).
Check the archives, but here is a quick summary:

Storing objects on the file system:
* usually indexed on the database for searching
* faster than database (usually)
* more typical usage pattern
* requires extra engineering if you want to store huge numbers of objects
* requires extra engineering to keep your database in sync.  on
postgresql irc someone suggested a clever solution with inotify
* backup can be a pain (even rsync has its limits) -- for really big
systems, look at clustering solutions (drbd for example)
* lots of people will tell you this 'feels' right or wrong -- ignore them :-)
* well traveled path. it can be made to work.

Storing objects on the database:
* slower, but getting faster -- its mostly cpu bound currently
* get very recent cpu. core2 xeons appear to be particularly good at this.
* use bytea, not large objects
* will punish you if your client interface does not communicate with
database in binary
* less engineering in the sense you are not maintaining two separate systems
* forget backing up with pg_dump...go right to pitr (maybe slony?)
* 1gb limit. be aware of high memory requirements
* you get to work with all your data with single interface and
administrate one system -- thats the big payoff.
* less well traveled path.  put your r&d cap on and be optimistic but
skeptical.  do some tests.

merlin

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

Предыдущее
От: Ron
Дата:
Сообщение: Re: Slow Postgresql server
Следующее
От: Guido Neitzer
Дата:
Сообщение: Re: Slow Postgresql server