Table Storage Service (Azure's implementation of nosql) vs Windows Azure Caching (unstructured in memory cached)

Question

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# (ie 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

Answer 1

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 (eg 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.