> To follow up with Ted, nobody said using the filesystem is bad, No, it is the most efficient way.
Not in my environment. All db servers have RAID 10 over 8 SCSI 15K disks. Pulling from them is always faster than a webserver pulling from its SATA drive. Also, there is issue of going to the database and going to the filesystem. Timing wise, you
Add an image server (or 20) and change the HTML to point to the image server.
I can't imagine Flickr doing that.
I believe that the only "new" thing I have to add is for newbies. I believe that for a newbie, it would be easier to use the filesystem rather than the DB. True, you then have to do some extra cleanup/management work for deleted records, so that the related images go away. But storing them in the DB invariably ends up with too many issues involving DB storage size and query buffer size, compounded by data escaping/security issues.
Strange... I came to the opposite conclusion. Using prepared statements eliminates data escaping issues, etc. And putting the files in the db removes the extra cleanup/management stuff. And easier to backup (though not efficient).
Again, the problem of replication or distribution does not require a database. If you are saying that your single database will contain all your bitmap files, then that's messed up and your database will be a bottleneck. You've stated a problem: A large amount of data spread across multiple machines, this is a real problem domain, but it absolutely does not say why a database is the right solution or even a solution at all.
I guess you skimmed what I wrote. What I wrote was about using a database for meta data and server and file location. I was talking about using that date to intelligently know where the file was .... on a file system. Mostly because it is cheaper to scale that way as you can tune things to add more replicas for redundancy and performance. Then that can hit scalability problems with many hundred of servers. But easy to solve by breaking down meta data and storage parts. Have fewer storage servers talk to a meta data (database) server such that you can run the databases on the same cheap machines that you run the storage stuff. Then you have a task server that manages the meta data servers and storage servers. Chaining things this may see like a lot of steps to go through. But it can be very efficient throughput wise, which matters far more than a benchmark. To anyone that has designed CPUs, this will look a little familiar (though more flexible). At that point you also never have a complete backup on one machine. I remember that being a weird thing.... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
