Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Memcached Presentation


Published on

Provides a detailed overview of memcached and usage patterns

Published in: Technology
  • Be the first to comment

Memcached Presentation

  1. 1. MEMCACHED An Overview Quick overview and best practices - Asif Ali / Oct / 2010 / Image courtesy: memcached offical website
  2. 2. “The Disk is the new tape!” Quoted from somewhere
  3. 3. What is memcache? • Simple in memory caching system • Can be used as a temporary in-memory data store • Stores data in-memory only. • Excellent read performance. • Great write performance. • Data distribution between multiple servers. • API available for most languages
  4. 4. Memcache • NO – acid, data structures, etc etc. • If you’re looking for a replacement for your DB then you’re looking at the wrong solution. • Simple “put” a data using a key • Get the data using the key. • Generally, your app remembers the key. • Data typically expires or gets flushed out (so has a short life). • Does not auto commit to disk
  5. 5. When should I use memcached? • When your database is optimized to the hilt and you still need more out of it. – Lots of SELECTs are using resources that could be better used elsewhere in the DB. – Locking issues keep coming up • When table listings in the query cache are torn down so often it becomes useless • To get maximum “scale out” of minimum hardware
  6. 6. Use cases for memcached • Anything what is more expensive to fetch from elsewhere, and has sufficient hit rate, can be placed in memcached • Web Apps that require extremely fast reads • Temporary data storage • Global data store for your application data • Session data (ROR) • Extremely fast writes of any application data (that will be committed to an actual data store later) • Memcached is not a storage engine but a caching system
  7. 7. NoSQL & SQL • We’re not going to debate about the pros and cons of the different NoSQL vs SQL solutions. • My View: It really depends upon your requirements. • NoSQL caters to large but specific problems and in my opinion, there is no all in one solution. • Your comfort of MySQL or SQL statements might not solve certain scale problems
  8. 8. For Example • If you have hundreds of Terra Bytes of data and would like to process it, then clearly – Map Reduce + Hive would be a great solution for it. • If you have large data and would like to do real time analytics / queries where processing speed is important then you might want to consider Cassandra / MongoDB • If your app needs massive amounts of simple reads then clearly memcached is probably the solution of choice • If you want large storage of data with non aggregate processing and very comfortable with MySQL then a MySQL based sharded solution can do wonders.
  10. 10. Memcached Server Info • Memcache server accepts read / write TCP connections through a standalone app or daemon. • Clients connect on specific ports to read / write • You can allocate a fixed memory for memcached to use. • Memcached stores data in the RAM (of course!) • Memcached uses libevent and scales pretty well (theoritical limit 200,000)
  11. 11. Configuration options • Max connections • Threads • Port number • Type of process – foreground or daemon • Tcp / udp
  12. 12. Read write (Pseudo code) • Set “key”, “value”, ”expire time” • A = get “key”
  13. 13. Sample Ruby code • Connection: – With one server: M = ‘localhost:11211’, :namespace => ‘my_namespace’ – With multiple servers: M = %w[], :namespace => ‘my_namespace’
  14. 14. Sample Ruby code • Usage – m ='localhost:11211') – m.set 'abc', 'xyz‘ – m.get 'abc‘ => ‘xyz’ – m.replace ‘abc’, ‘123’ – m.get ‘abc’ => ‘123’ – m.delete ‘abc’ => ‘DELETED’ – m.get ‘abc’ => nil
  15. 15. Memcached data structure • Generally simple strings • Simple strings are compatible with other languages. • You can also store other objects example hashes. • Complex data stored using one language generally may not be fetchable from different systems
  16. 16. Sample Ruby code • Memcache can store data of any data types. – m ='localhost:11211') – m.set ‘my_string’, ‘Hello World !’ – m.set ‘my_integer’, 100 – m.set ‘my_array’, [1,”hello”,”2.0”] – m.set ‘my_hash’, {‘1’=>’one’,’2’=>’two’} – m.set ‘my_complex_data’, <any complex data>
  17. 17. Limits of memcached • Keys can be no more then 250 characters • Stored data can not exceed 1M (largest typical slab size) per key • There are generally no limits to the number of nodes running memcache • There are generally no limits the the amount of RAM used by memcache over all nodes – 32 bit machines do have a limit of 4GB though
  18. 18. FEATURES
  19. 19. Memcached can replicate for high availability Memcached 1 Data structure A Memcached 2 Copy of Data structure A
  20. 20. Data can be distributed using memcached Memcached 1 Part 1 - Data structure A Memcached 2 Part - 2 The connecting client can connect to either memcached 1 or memcached 2 to fetch any data that is distributed across the two servers
  21. 21. Memcached can store any object • Simple String • Hash • Other • Strings can be read / written among heterogenous systems.
  22. 22. Memcached best practices
  23. 23. Best Practices • Allocate enough space for memcached. • Memcache does not auto save data into disk so don’t forget to serialize your data if you need to. • A memcached crash could lead to a large downtime if you have to load a lot of data to load (into memcache) so you should – Replicate memcached data OR – Find algorithms to store data as fast as you can OR – Have redundant servers with similar data and handle “no data” situation well.
  24. 24. Best Practices • Shared nothing, non replicated set of servers works the best. • Don’t try to replicate your database environment into Memcached. It is not what it was meant for. • Don’t store data for too long in memcached. Least recently used items (LRU) are evicted automatically in certain scenarios. • Reload data that is required for your reads as often as possible • Don’t go just by existing benchmarks; Find out your application benchmarks in your environment and use that variable to scale.
  25. 25. What to look out for • Memcached performance can hit roadblocks under very high reads and writes on a single instance so try to isolate read / write instances or see what works best for your app. • Data increments on memcache values – remember this is a shared memory space and data is not always “locked” before being updated.
  27. 27. Usage History • Considered using memcached more than 2 years ago due to problems in high volumen MySQL read and writes. • Used it first as a way to store Mongrel’s session variables instead of MySQL.
  28. 28. The Problem we tried to solve • Deliver a matching ad to a complex set of variables • 6000+ devices in device db. • 8-10m records in ip data • Country / carrier / manufacturer / channel / targeting • IP filters, black lists • Bot Filtering • Ad moderation etc etc etc.. • Typical In an ad network scenario
  29. 29. The solution needed to • Make data fetching as fast as possible • Make data structures simple • Make processing extremely simple (for example a string comparision vs a SQL Query) • Make processing of data as fast as possible. • Complete all processing 50 ms or less.
  30. 30. ..continued • Using a database was possible in low traffic scenario. • Traffic grew and so did database nightmares.
  31. 31. Our usage of memcached • Hundreds of millions of reads daily; small chunks of data. Infrequent writes. • More than 60G of memcached shared data space. • MySQL was fine until we moved our performance metric from seconds to ms. • Current total transaction time between 21- 50ms.
  32. 32. Our partial stack
  33. 33. Memcached clients currently used • • • There are newer and better clients that can be used.
  34. 34. Questions?