I've built systems than stream tons of data via this method, at times into some impressive requests per second. Also I've exposed files stored in this manner via a ftp interface with servers able to deliver near wire speed data in and out of the db storage.
When your into a load balanced environment, you have a private network/vlan between the webservers backend and the database servers. 100mbit link/segment dedicated to db traffic. No bottle neck there. You are right about streaming the same file again and again, but is this really a real world scenario in all apps. If your app leans in this direction, you can do some temporary caching on the webserver end (maybe in memory cache, or if your running a java container, just throw the objects into memory for a timespan, before deleting and re-fetching. If someone gains access to a webserver, they can walk around and steal all source code/files on the webserver (including your pdf's) .. If you were running compiled java code, or encoded php code (with connection strings in php) that would be alot more difficult for them to access the data. I had a very large filesystem storage project, which the file management/scalability/expandability just got out of hand. Migrating to db storage solved that totally and I've never looked back. On Wed, 7 Mar 2007, Alexander Lind wrote: > imagine a large system where pdf-files are accessed by clients a lot. > say 1 pdf file is access per second on average. > > also say that your database is on a machine separate from the > webserver(s) (as is common). > > do you really think its a good idea to pump the pdf data from the db > each time it needs to be accessed? > > it may seem easier to do this as you then would not have to replicate > the physical files across the webserver machines, but i would not say > that the slight increase of ease is worth the added load to the db and > the network. > following your reasoning, you'd also store all images in the db so that > you don't have to replicate these either? > > what is unsafe about having a pdf file on a webserver (not in a place > where the httpd can access it of course)? > > alec > > [EMAIL PROTECTED] wrote: > > I have to disagree with most, I would store the entire file in the > > database, metadata and all. Better security, if you have a backend > > database, it's much harder to get the data than pdf's sitting in a > > directory on the webserver. Plus if you ever want to scale to a > > multi-webserver environment, the db storage works great. > > > > > > On Wed, 7 Mar 2007, Ed wrote: > > > > > >> On Wednesday 07 March 2007 21:26, Alexander Lind wrote: > >> > >>> I would put the pdf as a regular file on the hd, and store the path to > >>> it in the db. > >>> Meta data could be things like the size of the pdf, author, owner, > >>> number of pages etc. > >>> > >>> Storing binary data from pdf:s or images or any other common binary > >>> format is generally not a good idea. > >>> > >>> Alec > >>> > >> Thank you all for your help. I get the gist of things... don't store the > >> binnary, store the path to it and details of it. > >> > >> Thank you all for your quick response. > >> -Ed > >> > >> -- > >> MySQL General Mailing List > >> For list archives: http://lists.mysql.com/mysql > >> To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > >> > >> > > > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
