The Mighty Server and the Killer Queries
time to read 2 min | 294 words

I just read a comment that really annoyed me, talking about the lack of need for caching.

These days DBMS are not just a “persistent storage”; a DBMS is designed to handle many concurrent hits and transaction processes using multi CPU support and terabytes of memory pages. I don’t understand why we developers are so obsessed with the number of hits.

Just to note, I have caused a 32Gb, 64bits, 4 CPU Server to weap tears of shame when I run 900 concurrent queries traversing just under Billion rows. It worked, but it wasn't pretty. That, however, is not a core scenario in most cases.

What is a core scenario is the time that responsiveness of the application, how long it takes to serve a single request. Here, it doesn't matter how smart the database is. The deciding factor is the amount of queries performed, each of them, to remind you, is a remote call, which is easily a hundred times more expensive than anything that you might do locally.

The problem with the comment above is that it is also ignoring several other factors, including the query complexity, the number of concurrent connections, how much IO and computing each query takes, etc. I think that it is safe to say that it is at least an order of magnitude harder to scale the database (up and wide) than to scale the application, so anything that reduce the amount of work the database need to do is a Good Thing.

Tweet Share Share 0 comments
Tags: