Memcached vs SQL Server cache
I've been reading a lot of articles that suggest putting a Memcached (or Velocity, etc) in front of a database is more efficient than hitting the database directly. It will reduce the number of hits on the database by looking up the data in a memory cache, which is faster than hitting the database.
However, SQL Server has it's own memory cache for objects in the database. When data is retrieved, SQL Server maintains its cache and will (if necessary) pull the row from it's memory and not hit the disk.
So if SQL Server has it's own cache, what is the benefit of an external Memcached (or similar) server?
Most of the articles I have been reading are around social networking sites, that mostly use MySql. However, an article about MySpace, that uses SQL Server, suggests caching is used on that system as well.
This article explains when caching should be used and this article is a counterpoint.
Answer
So if SQL Server has it's own cache, what is the benefit of an external Memcached (or similar) server?
Yes SQL Server has its own cache but he caches only:
- Query plans
- pages from the database files
but he does NOT cache:
- results from a query
e.g. you have a complex query which uses some aggregation on a lot of data ( think of: how many different countries we have in our customer database : SELECT DISTINCT Country from Customers GROUP BY country )
SQL Server will scan th WHOLE customer table, but your resultset will only a few entries long. When you reissue your query, SQL Server will reuse the query plan and will rescan the customer table, ( and if you are lucky the pages are still in memory )
When you use memcached you may store the few rows of your resultset and reuse them over and over again without connecting to the database server. So it takes some load from your database server.
NOTE: Beware of some stale data, if your data changes on the SQL server !!