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.
|
Список | pgsql-general |
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 filewith 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 notfun. 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 serverlike nginx can handle 10k connections easily, and with little or no overhead. While the speed is comparable to theOS, you end up using a resource from a limited database connection pool. And you run the risk of a slow/dropped clienttying 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 по дате отправления: