4 ms·

Is Memcached a Good or Bad Sign for MySQL?

11 points by vladocar 17y ago

patio11 17y ago
From my point of view, memcached isn't a godsend because the database is weak, it is a godsend because it prevents you from trying to do things that no database should be asked to do. My personal projects use memcached recently, but not for anything interesting. At the day job, we have a particular case where we render a per-user sidebar. The data for the sidebar is volatile, but unpredictably volatile -- i.e. it should be unchanging for the length of a user session except when it isn't, but when it isn't the user requires us to know Right The Heck Now (TM). That data is actually stored on another system, and accessing it requires hitting a web service on the other system. Accessing the web service is, obviously, an overhead, and the service it calls is very heavy. Obviously, big win for us if we can avoid hitting that service on every request for a webpage with a sidebar. Enter memcached. It is a fairly simple way to keep the sidebars for 3+ app servers synced with each other, and the other system can force-expire the cache if it wants to. This isn't a knock against the database running on the other system -- it doesn't and shouldn't care about what format we use their data in, just that they're keeping the contract about providing it when we ask and pinging us when it needs expiry.
- bobbyi 17y ago
  How are you having the other system expire the cache?
  - henriklied 17y ago
    As I've been involved in a similar project, for my part I set up a very simple web service that handled the invalidation. The third-party service only needed to know the user session key or the user database ID, and then send a HTTP DELETE to the relevant API method, and the main app server did the rest.
russss 17y ago
He's getting it wrong (unsurprisingly). If you just use Memcache to cache the same results you get out of a DB, of course you might as well just throw that RAM at the DB. With any sane DBMS this will result in the same performance improvement. The problem with that is that it limits you to the amount of RAM you can throw into the DB. The biggest Memcache clusters reach well into the multi-terabyte range. Secondly, you can use Memcache to store constructed objects which could take many DB calls (or CPU time) to generate. Now you're getting one Memcache hit instead of several DB hits, which is a distinct bonus. Since it's shared-nothing, Memcache also gives you the ability to massively parallelize queries to many cache servers at once, and get a much quicker overall response than just hammering one DB into the ground.
- pj 17y ago
  I've never used memcache, but my understanding is that memcache stores the results of queries whereas adding ram to the database will perhaps help it store indexes, tables, and query compiles, but to the best of my knowledge, the results of queries are not stored by DBMSs -- this is why memcache is used. If my understanding of memcache is correct, throwing more ram at the db won't provide the same performance improvements that memcache will provide.
  - rythie 17y ago
    MySQL has a query cache which stores results of queries, though it's not very useful if you have frequent writes. Linux and other operating systems tend to use any free memory for disk cache which will end up caching the whole database if needed. Innodb has a key cache. Memcached probably helpful on the database server but it's really designed to be ran somewhere else so that database server has as much memory as possible of it's own.
  - nomoresecrets 17y ago
    mysql has a query cache, which stores the query and results: http://dev.mysql.com/doc/refman/5.1/en/query-cache.html http://dev.mysql.com/doc/refman/5.1/en/query-cache.html
neovive 17y ago
The increase in development for memcached is a good thing since it's a relatively easy and less expensive way to scale. As mentioned in the article, relational databases will be around for a while and were never designed for the kind of scale that many companies require today. It's a proven technology that just needs a boost in certain situations. The combination of MySQL + Memcached is a great solution to for many small companies to scale.
- silentbicycle 17y ago
  > As mentioned in the article, relational databases will be around for a while and were never designed for the kind of scale that many companies require today. MySQL is not representative of all relational databases.

11 points by vladocar 17y ago

From my point of view, memcached isn't a godsend because the database is weak, it is a godsend because it prevents you from trying to do things that no database should be asked to do. My personal projects use memcached recently, but not for anything interesting. At the day job, we have a particular case where we render a per-user sidebar. The data for the sidebar is volatile, but unpredictably volatile -- i.e. it should be unchanging for the length of a user session except when it isn't, but when it isn't the user requires us to know Right The Heck Now (TM). That data is actually stored on another system, and accessing it requires hitting a web service on the other system. Accessing the web service is, obviously, an overhead, and the service it calls is very heavy. Obviously, big win for us if we can avoid hitting that service on every request for a webpage with a sidebar. Enter memcached. It is a fairly simple way to keep the sidebars for 3+ app servers synced with each other, and the other system can force-expire the cache if it wants to. This isn't a knock against the database running on the other system -- it doesn't and shouldn't care about what format we use their data in, just that they're keeping the contract about providing it when we ask and pinging us when it needs expiry.

bobbyi 17y ago
How are you having the other system expire the cache?
- henriklied 17y ago
  As I've been involved in a similar project, for my part I set up a very simple web service that handled the invalidation. The third-party service only needed to know the user session key or the user database ID, and then send a HTTP DELETE to the relevant API method, and the main app server did the rest.

russss 17y ago

He's getting it wrong (unsurprisingly). If you just use Memcache to cache the same results you get out of a DB, of course you might as well just throw that RAM at the DB. With any sane DBMS this will result in the same performance improvement. The problem with that is that it limits you to the amount of RAM you can throw into the DB. The biggest Memcache clusters reach well into the multi-terabyte range. Secondly, you can use Memcache to store constructed objects which could take many DB calls (or CPU time) to generate. Now you're getting one Memcache hit instead of several DB hits, which is a distinct bonus. Since it's shared-nothing, Memcache also gives you the ability to massively parallelize queries to many cache servers at once, and get a much quicker overall response than just hammering one DB into the ground.

pj 17y ago
I've never used memcache, but my understanding is that memcache stores the results of queries whereas adding ram to the database will perhaps help it store indexes, tables, and query compiles, but to the best of my knowledge, the results of queries are not stored by DBMSs -- this is why memcache is used. If my understanding of memcache is correct, throwing more ram at the db won't provide the same performance improvements that memcache will provide.
- rythie 17y ago
  MySQL has a query cache which stores results of queries, though it's not very useful if you have frequent writes. Linux and other operating systems tend to use any free memory for disk cache which will end up caching the whole database if needed. Innodb has a key cache. Memcached probably helpful on the database server but it's really designed to be ran somewhere else so that database server has as much memory as possible of it's own.
- nomoresecrets 17y ago
  mysql has a query cache, which stores the query and results: http://dev.mysql.com/doc/refman/5.1/en/query-cache.html http://dev.mysql.com/doc/refman/5.1/en/query-cache.html

neovive 17y ago

The increase in development for memcached is a good thing since it's a relatively easy and less expensive way to scale. As mentioned in the article, relational databases will be around for a while and were never designed for the kind of scale that many companies require today. It's a proven technology that just needs a boost in certain situations. The combination of MySQL + Memcached is a great solution to for many small companies to scale.

silentbicycle 17y ago
> As mentioned in the article, relational databases will be around for a while and were never designed for the kind of scale that many companies require today. MySQL is not representative of all relational databases.