On Mon, 2007-06-18 at 08:41 -0700, Jim Lucas wrote: > Daniel Brown wrote: > > On 6/18/07, Tijnema <tijnema@xxxxxxxxx> wrote: > >> On 6/18/07, Daniel Brown <parasane@xxxxxxxxx> wrote: > >> > On 6/18/07, Tijnema <tijnema@xxxxxxxxx> wrote: > >> > > On 6/18/07, Daniel Brown <parasane@xxxxxxxxx> wrote: > >> > > > On 6/18/07, Colin Guthrie <gmane@xxxxxxxxxxxxxx> wrote: > >> > > > > clive wrote: > >> > > > > >> > >> > > > > >> I have no clue how big the files are, but you might want to > >> store them > >> > > > > >> in a database. That can speed up things, but don't ask me > >> how much ;) > >> > > > > >> > >> > > > > >> Tijnema > >> > > > > >> > >> > > > > > no dude, while database are convenient, files systems are > >> faster, I mean > >> > > > > > thats what they were designed for, serving files. > >> > > > > > > >> > > > > > For lots of files I would store them in directories and sub > >> directories. > >> > > > > > >> > > > > Yeah amen! > >> > > > > > >> > > > > I generally use a two character hex hash in my main folder to > >> give 255 > >> > > > > sub folders each containing files. > >> > > > > > >> > > > > In my case the hash is calculated from some known info - e.g. > >> a database > >> > > > > ID and then stored in a meta data table. > >> > > > > > >> > > > > Col > >> > > > > > >> > > > > -- > >> > > > > PHP General Mailing List (http://www.php.net/) > >> > > > > To unsubscribe, visit: http://www.php.net/unsub.php > >> > > > > > >> > > > > > >> > > > > >> > > > Tij, > >> > > > > >> > > > Referring to one of my earlier posts in this thread, as a > >> > > > refresher, database information is stored in files. So to store > >> files > >> > > > in a database means the following has to take place: > >> > > > > >> > > > 1.) Data is uploaded to the server. > >> > > > 2.) Data is processed by the database server. > >> > > > 3.) Data is compressed and encrypted. > >> > > > 4.) Data is written to disk. > >> > > > (4b. - optional) Data file is checked for integrity and > >> > > > correctness of write. > >> > > > > >> > > > Then, to serve the content, a similar reverse occurs: > >> > > > > >> > > > 1.) Request is sent to the server via a script. > >> > > > 2.) The script interfaces with the database to locate the > >> > > > desired data row. > >> > > > 3.) Once located, the data is pulled in raw form from the > >> database file. > >> > > > 4.) The data is then decompressed and decrypted. > >> > > > 5.) The data is streamed back to the script. > >> > > > 6.) The script decides how to handle it, based upon > >> hard-coded options. > >> > > > > >> > > > For a filesystem, it's simpler. Uploading: > >> > > > > >> > > > 1.) Data is uploaded. > >> > > > 2.) Data is written to disk. > >> > > > > >> > > > Serving: > >> > > > > >> > > > 1.) Request is sent via script, FTP, socket connection, or > >> > > > local request. > >> > > > 2.) File is served through via the method requested. > >> > > > > >> > > > So there are several pros and cons for each, but just to list > >> > > > three of each with regard to database storage: > >> > > > > >> > > > Pros: > >> > > > Can be stored centralized and portable, without needing > >> to archive. > >> > > > Automatically encrypted and compressed upon storage. > >> > > > Easier and faster to search. > >> > > > Cons: > >> > > > Slower storage and retrieval > >> > > > Much greater risk of corruption > >> > > > Not always cross-compatible across platforms, versions, > >> > > > installations, etc. > >> > > > > >> > > > -- > >> > > > Daniel P. Brown > >> > > > >> > > How sure are you about all this? > >> > > Benchmarks? > >> > > > >> > > What about search time for the harddrives etc? It needs to scan the > >> > > inode table to find the file, etc.., then it needs to locate that > >> file > >> > > on the harddrive, while the second file might be on the other side of > >> > > the disk.... > >> > > > >> > > Storing all files in one single filesystem means you have only 1 > >> inode > >> > > :) All data is stored at same place (atleast, it should be) > >> > > > >> > > Tijnema > >> > > > >> > > >> > Do I have benchmarks? No. Do I have the time to do them now? No. > >> > > >> > Do I feel confident enough that if you were to run those benchmark > >> > tests that it would prove me right? Damn straight. ;-P > >> > > >> > -- > >> > Daniel P. Brown > >> > >> I think I have some time to write a simple script in a few hours, I'd > >> like to see what the performance difference is :) > >> > >> Tijnema > >> > > > > Well, keep in mind that I don't expect that you'd see much > > difference at all with a single file, but try doing multiple files of > > ASCII and binary, various sizes, and also several simultaneous > > connections. > > > > Two other things I forgot to mention with database storage are a > > pro and con, respectively - caching and accessibility. > > > > and the fact that a lot of hosting environments have a DB on a different machine. > > This would make for a much worse performance then the local filesystem. Maybe on the occasional hit. I use a technique where a 404 request of a specially formulated filename causes the file to be retrieved from the remote centralized database server. If found the 404 is changed to a 200 response and the file is served. Subsequent requests directly access the file from the webserver without PHP. Obviously this is a caching technique, but it eliminates much of the overhead of the database while still providing a centralized repository for all the images. And FWIW, the special naming includes sizing information for the image so that it can be scaled if necessary once at request time. And just so people don't muck with the parameters there is salting and hashing of the parameters. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
