On Sat, Dec 13, 2003 at 02:01:30AM +0000, Timwi wrote:
Lars Aronsson wrote:
Blob-like data can be stored on file instead, with only a filename in the database.
For reasons I don't understand, many people keep coming up with this idea, but it's a really bad idea.
First of all, there is no reason to believe that reading from one file out of thousands is any faster than reading one record in the DB out of thousands. Secondly, it makes atomic transactions impossible. It makes backing up a consistent state of the database/file-system mix virtually impossible. It is too difficult to move data around without violating the consistency of the construct. And lastly, it makes creating a full-text search index quite a bit harder.
Convinced yet? ;-)
No at all. There are good reasons to expect much higher performance.
* filesystem resides in kernel and uses extremely very fast context switches between kernelspace and userspace, database server has to communicate using sockets, what's MUCH slower. Because it's inside a kernel it has more access to disk drivers, can implement zero-copy data transfer, can use much faster locks, more efficient SMP etc. * unless you store databases on raw partitions, you have to cope with problems like inefficient double caching of data, discontiguous storage, and lack of information about physical structure of data on disk * filesystems are very specialized - they only provide a few operations for which they're extremely fast. If the operations needed happen to be those provided by the filesystem, we're likely to achieve really great performance, otherwise, we have to implement the operations needed ourselves, and the results probably won't be as good.
I think that we're going to see databases that are at least partially kernel-space some day (some databases use raw partitions already). Just look at the difference in speed between Apache and Tux. Reiserfs4 is supposed to be something between a filesystem and a database, so what I'm saying isn't as off-base as it may seem to people used to LAMP paradigm. Maybe it'll become LTuxReiserfs4P soon.
Backing up a Wiki was much easier in Phase I, when it was possible to use rsync. Mirroring Wikipedia after the switch to MySQL started to require about two orders of magnitude more bandwidth and CPU, and it became impossible to do it in real time. Now you can only synchronize once a day.
And with regard to full-text index, it isn't any good now - it's slow, turned off most of the time, and usually returns rather bad results. Moving away from MySQL would allow us to create index that would provide better results.