diary | | | geek interests | | | publications | | | projects | | | web |
12/24/2002 01:45:00 AM |
I was contemplating over how modern web servers integrate (or don't) with various databases. I'm talking about the ones that hold large binary content to be served over the wire. Now of course this is keeping in mind large amounts of concurrent requests with minimum hold up time per connection. As far as I can see, there's no way large binary content stored in any database storage system can be served efficiently with acceptable responsiveness without the server natively (or by means of plugins) being able to retrieve contents from a database as it does with the filesystem (i.e. seek and read content piece by piece starting from random offesets in chunks). My questions is why hasn't there been any attempt at addressing that issue with the mainstream webservers? Is it simply because nobody sees any real need to store such objects in the database when the file system handles the task efficiently and well? I suppose the real question is what does storing such binary objects into databases buy one as opposed to just simply using the file system. To me unification of storage architecture alone is a big winner. With the database access layer sitting on top any authorized user can get at that object. Otherwise you're saving all sorts of meta information about a binary ojbect in the database, but the actual object in the filesystem. This means additional implementation below the database access layer needs to be in place for that object to be externally reachable. Now throw in additional security measures, etc... Just seems a bit unclean to me... I wonder what wisdom BeOS could provide me with in this regards... I mean this isn't a particularly "hard" problem per se. There are certain trade-offs and design decisions that has to be made, but there's nothing inherently difficult... Then why is it that there's no work that has gone into tackling this issue in the commercial realm... I suppose it's cuz the filesystem is there and it does what they want just fine? Perhaps people are content with having the database and filesystem coexist? I'm just rambling on, but somebody please explain to me why nobody is interested in this.... According to BeOS' File I/O Interface API docs you have all the typical File IO functions that work the way you'd expect a File System to provide. Moreover, a company called Namesys whose funded by similar sources as us also seem to provide a filesystem based on database storage techology... I guess now that Microsoft tries to make the world think they're doing something innovative by saying that they're gonna *GASP* use database based file system in their next generation OS, at least the SQL server folks will be tackling this issue in the mainstream... |
Be the first to comment on this entry. |