Jeff AA wrote: > Interestingly MySQL and other DBs are often as fast as simple disk > access - contrary to popular wisdom, most DB engines actually cache in > memory, with more data access information and hence effective cache > memory usage than is available to external cache components. Yes, > Network transference can be an issue - but hey! be a masochist, buy a > switch!
It's a simple rule: if you do less work, you will finish faster. Reading a file will go to the file system code in the kernel, which uses some sort of in-memory cache on any modern OS. That means that for any frequent access data you are reading it from memory using system-level calls. By contrast, MySQL has to deal with network transfers and SQL parsing before it reaches that stage. It's not a huge difference, but it is a difference. I'll have numbers on this stuff soon as part of my article on data sharing with mod_perl, so that people can compare and see if it's worth the effort for them. The more important reason to cache is scalability. Every time you don't hit the database, that means more resources are available to handle the queries that can't be cached. On a site with heavy traffic, that's very important. > I parse 'use a cache for db stuff' as 'my XYZ cache component is way > smarter than all the guys at 'Oracle|Sybase|MySQL' combined', or 'I know > my data better than the database, cos I'm a kewl Koder'. Actually, I > really parse 'use a cache for db stuff' as 'I don't really understand > databases, 3NF and indexing, and can't be bothered learning to use them > well'. I've worked with some good DBAs, but there is a limit to what they can do. Ultimately, a database is designed to always give 100% correct up-to-date results, but in most web applications people would prefer to get slightly out-of-date results if they can get them much faster. Databases don't know how to do that. Why should you go to MySQL every time someone hits the front page of Slashdot just to give them the very latest count on comments? Caching that page for 1 minute takes a ton of load off the database and doesn't really impact the user experience. I fully agree that optimizing the database and SQL is the first step, but correct use of caching can make a huge difference on high-volume sites. - Perrin
