4

We want to implement caching in Azure for two main reasons:

  1. Speed up repetive data access
  2. Reduce stress on the database

Here are the characteristics of the data we are planning to cache:

  1. Relatively small (1 - 100 kb)
  2. Specific to each customer
  3. Not private, but we don't really want random people navigating through our entire cache
  4. XML or JSON
  5. Consumed by C# (i.e. not linked to directly in the html)
  6. Most weeks the data will not change, although some days the data could change several times

For this specific purpose Table storage appears better than Blob storage (we did just implement Blob storage for images, CSS, and JavaScript) and Windows Azure Caching appears better than Windows Azure Shared Cache (perhaps almost always better and the shared caching is mostly a legacy feature at this point).

The programming API of both appears straight forward. Compared to what we pay for cloud sites the cost of each seems to be negligible.

So far we are leaning toward Table Storage due to what we perceive to be the pros and cons of Azure Caching. As old .Net guys we are much more familiar with In-Memory Cache than NoSql style solutions:

Problems with Windows Azure Caching:

  1. If the VM is moved to a different server (by Microsoft for load balancing or whatever reasons) is the in-memory cache moved intact?
  2. We are guessing that whenever we publish changes to the cloud it wipes out the existing in-memory cache
  3. While the users rarely make changes to the cached data when they do make changes it is likely that they may make multiple updates within seconds and we are not sure how this is going to work with cache located across multiple nodes running web roles especially with increased traffic. (this is probably a concern with table storage as well!)
  4. Table storage appears like it will be easier to debug

Advantages of Windows Azure Caching

  1. somewhat faster
SemanticZen
  • 1,141
  • 14
  • 21
  • Greiner's [answer here](http://stackoverflow.com/a/14204602/859857) is probably a good default solution, use table storage first and if some data becomes a bottle neck due to extremely high usage move it to the Cache. Then the solution is to have 2 layers of a cache. – SemanticZen Mar 12 '13 at 15:44
  • So for data that is accessed regularly but rarely edited use Command-Query Responsibility Segregation via NoSql and if nosql's performance degrades for any values move that in-memory? – SemanticZen Mar 12 '13 at 15:57

1 Answers1

5

Your familiarity with in-memory caching is the model that you need to understand to implement caching on Windows Azure. The 'NoSql style' is not caching, but storage. So table storage rather replaces SQL than it replaces caching. Table storage is for persistent, reliable storage — with all of the latency and other disadvantages of persistence that do not exist with in-memory cache.

Writing to cache is always secondary. When your users 'make changes to the cached data' you will always be writing out the data to disk (e.g. SQL), and then writing out the same data to the cache because you might as well, since you have the data on-hand (although secondary effects on written data may mean that you should invalidate or re-read the cached item).

The wiping out of data when a machine recycles should not be much of a concern, as the data is stored elsewhere. Every read from the cache should be followed by an 'if not found then read from database' kind of statement. You can warm-up the cache when a role starts to pre-populate items that you know that you are going to need.

Caching on Azure is distributed across the nodes and updating an existing item will always update on the node that it resides. Quick updates may be less of a problem than you think.

For in-memory caching use Windows Azure caching (you are right about shared caching being legacy) and, depending on your needs, look at other caching technologies like memcached. Caching and table storage are not comparable. Table storage is for long-term persistence. Don't unnecessarily hack table storage to do caching — making table storage temporary creates a whole bunch of things that you need to worry about yourself, like expiry and invalidation.

Simon Munro
  • 5,399
  • 6
  • 33
  • 40
  • Simon thanks for the detailed response! It sounds like Table Storage won't necessarily be faster than SQL. Table storage is more useful as a way to scale by taking load of SQL? So Azure cache probably has much better performance. – SemanticZen Mar 12 '13 at 16:28
  • It looks like [memcached could be a useful way to granularly mange Azure Cache](http://msdn.microsoft.com/en-us/library/windowsazure/hh914167.aspx) (if we ever need that ability). – SemanticZen Mar 12 '13 at 16:36
  • Cloud applications in general, and Azure specifically, will store data in multiple stores across workloads, so yes table storage does take load of SQL (see the [data model in CALM](https://github.com/projectcalm/Azure-EN)). Using the memcached protocol for Azure cache is a good idea because it allows you to swap in memcached later and was a good move by the Azure team. – Simon Munro Mar 12 '13 at 16:56
  • If the application programmatically removes an item from the cache (because it has changed) will the item be removed from all nodes in Azure Caching or just the local node? – SemanticZen Mar 12 '13 at 19:22
  • 1
    Items are only ever on a single node. The cluster directs the request for data to the relevant node. Removal from a single node will also make in inaccessible to other nodes. – Simon Munro Mar 12 '13 at 19:58