Re: Storing Video's or vedio file in DB.

Поиск
Список
Период
Сортировка
Искать
От
Jonathan Vanasco
Тема
Re: Storing Video's or vedio file in DB.
Дата
Msg-id
4683D2AC-7C10-4A5C-95D9-AF2BA8FE4265@2xlp.com
Ответ на
Список
Дерево обсуждения
Storing Video's or vedio file in DB. VENKTESH GUTTEDAR <venkteshguttedar@gmail.com>
Re: Storing Video's or vedio file in DB. Vincent Veyron <vv.lists@wanadoo.fr>
Re: Storing Video's or vedio file in DB. Jonathan Vanasco <postgres@2xlp.com>
Re: Storing Video's or vedio file in DB. Arthur Silva <arthurprs@gmail.com>
Re: Storing Video's or vedio file in DB. Adrian Klaver <adrian.klaver@aklaver.com>
Re: Storing Video's or vedio file in DB. Albe Laurenz <laurenz.albe@wien.gv.at>
Re: Storing Video's or vedio file in DB. Thomas Kellerer <spam_eater@gmx.net>
Re: Storing Video's or vedio file in DB. Alan Hodgson <ahodgson@simkin.ca>
Re: Storing Video's or vedio file in DB. Vincent Veyron <vv.lists@wanadoo.fr>
Re: Storing Video's or vedio file in DB. John R Pierce <pierce@hogranch.com>
Re: Storing Video's or vedio file in DB. Albe Laurenz <laurenz.albe@wien.gv.at>
Re: Storing Video's or vedio file in DB. Alban Hertroys <haramrae@gmail.com>
Re: Storing Video's or vedio file in DB. Merlin Moncure <mmoncure@gmail.com>

I wouldn't even store it on the filesystem if I could avoid that.
Most people I know will assign the video a unique identifier (which is stored in the database) and then store the video file with a 3rd party (e.g. Amazon S3).

1. This is often cheaper.  Videos take up a lot of disk space.  Having to ensure 2-3 copies of a file as a failover is not fun.
2. It offloads work from internal servers.  Why deal with connections that are serving a static file if you can avoid it?

In terms of FS vs DB (aside from the open vs streaming which was already brought up)

I think the big issue with storing large files in the database is the input/output connection.
Postgres has a specified number of max connections available, and each one has some overhead to operate. Meanwhile, a server like nginx can handle 10k connections easily, and with little or no overhead.  While the speed is comparable to the OS, you end up using a resource from a limited database connection pool.  And you run the risk of a slow/dropped client tying up the connection.  
Why allocate a resource to these operations, when there are more lightweight alternatives that won't tie up a database connection ?


В списке pgsql-general по дате отправления
От: David G Johnston
Дата:
От: Patrick Krecker
Дата:
FAQ