From: | Jonathan Vanasco <postgres(at)2xlp(dot)com> |
---|---|
To: | PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Storing Video's or vedio file in DB. |
Date: | 2014-12-17 23:20:50 |
Message-ID: | 4683D2AC-7C10-4A5C-95D9-AF2BA8FE4265@2xlp.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 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 ?
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick Krecker | 2014-12-17 23:29:02 | Re: Re: Strange error message when reference non-existent column foo."count" |
Previous Message | David G Johnston | 2014-12-17 23:11:49 | Re: Strange error message when reference non-existent column foo."count" |