18

We currently use Redis as our persistent cache for our web application but with it's limited memory and cost I'm starting to consider whether Table storage is a viable option.

The data we store is fairly basic json data with a clear 2 part key which we'd use for the partition and row key in table storage so I'm hoping that would mean fast querying.

I appreciate one is in memory and one is out so table storage will be a bit slower but as we scale I believe there is only one CPU serving data from a Redis cache whereas with Table storage we wouldn't have that issue as it would be down to the number of web servers we have running.

Does anyone have any experience of using Table storage in this way or comparisons between the 2.

I should add we use Redis in a very minimalist way get/set and nothing more, we evict our own data and failing that leave the eviction to Redis when it runs out of space.

Simon
  • 1,613
  • 1
  • 12
  • 27
  • I know it's been a while - what did you do here? I am considering the same move. The cost of Redis (connections and storage) make table storage a very reasonable option (storage accounts, tables and partitions allow for easy workarounds to any limits) – Tony Basallo Nov 21 '20 at 13:26
  • We went with storage tables for the caching, response time is generally single digits milliseconds so was fast enough for our needs. Only thing to be mindful of is making too many calls to the storage, as it doesn't have the normal underpinnings of a cache in terms of auto expiry, subscribing to changes etc. you need to implement a lot of that yourself in code. You need to think carefully about how you group, expire and stale data otherwise it can lead to excessive storage requests. – Simon Nov 23 '20 at 09:36
  • But ultimately, even if expired, it's a call to the service. My code still calls Redis for the cache object and then Redis says "nope, expired" at which point I call the underlying service and then re-populate Redis. So I don't see how that get's minimized. The real disadvantage is auto-expiry, so you might have storage being used that's invalid, that'll need some maintenance. Also pub/sub scenarios - which I don't have ATM. (and request limits for very busy sites). Again, this is an issue with Redis and requires $$$ to move up to bigger services, so I see similar issues there. – Tony Basallo Nov 24 '20 at 13:52
  • Yes, sorry I meant anything Redis native like auto expiry and pub/sub etc. Regarding the grouping I was just mentioning it so you avoid the initial mistakes we made in terms of having cache items that were too granular which led to waaay more cache requests than we needed. We were new to caching at the time so they were, in hindsight, obvious design considerations for anyone whose done website caching at least once in their career :-) – Simon Nov 24 '20 at 20:24

3 Answers3

20

This is a fairly broad/opinion-soliciting question. But from an objective perspective, these are the attributes you'll want to consider when deciding which to use:

  • Table Storage is a durable, key/value store. As such, content doesn't expire. You'll be responsible for clearing out data.
  • Table Storage scales to 500TB.
  • Redis is scalable horizontally across multiple nodes (or, scalable via Redis Service). In contrast, Table Storage will provide up to 2,000 transactions / sec on a partition, 20,000 transactions / sec across the storage account, and to scale beyond, you'd need to utilize multiple storage accounts.
  • Table Storage will have a significantly lower cost footprint than a VM or Redis service.
  • Redis provides features beyond Azure Storage tables (such as pub/sub, content eviction, etc).
  • Both Table Storage and Redis Cache are accessible via an endpoint, with many language-specific SDK wrappers around the API's.
David Makogon
  • 69,407
  • 21
  • 141
  • 189
  • 1
    Hi, appreciate the response and info. Key for me is the cost reduction but if that comes at a performance hit of 1000% then it's less appealing. Not really looking for opinion more hoping for info from anyone who might have tried this or who has used both and has a rough idea of how they compare performance wise. My dev availability is fairly limited so want to see if its at least viable then I'll start on an proof of concept exercise but don't want to waste valuable time if it's a clear non-starter. Particularly if there is some key thing I've overlooked in using Tables for a web cache, Ta. – Simon Oct 18 '16 at 09:23
  • I really think this is up to you to benchmark, to see which one works best for you. Performance is going to vary based on your app, your VM/app service sizing, etc. – David Makogon Oct 18 '16 at 09:28
6

I find some metrials about the azure redis and table, hope that it can help you.There is a video about Azure Redis that also including a demo to compare between table storage and redis about from 50th minute in the videos. Perhaps it can be as reference. But detail performance it depends on your application, data records and so on. The pricing of the table storage depends on the capacity of table storage, please refer to details. It is much cheaper than redis.

Tom Sun - MSFT
  • 24,161
  • 3
  • 30
  • 47
  • Hi, that's interesting as in the example he uses Redis to get the partition and row key and then goes to table storage and it's still very fast given its a Redis+Table call and as we'll be querying table storage by partition and row and never need more complex queries that does make the speed less of a concern. Cheers. – Simon Oct 19 '16 at 10:34
1

There are many differences you might care about, including price, performance, and feature set. And, persistence of data, and data consistency.

Because redis is an in-memory data store it is pretty expensive. This is so that you may get low latency. Check out Azure's planning FAQ here for a general understanding of redis performance in a throughput sense. Azure Redis planning FAQ

Redis does have an optional persistence feature, that you can turn on, if you want your data persisted and restored when the servers have rare downtime. But it doesn't have a strong consistency guarantee.

Azure Table Storage is not a caching solution. It’s a persistent storage solution, and saves the data permanently on some kind of disk. Historically (disclaimer I have not look for the latest and greatest performance numbers) it has much higher read and write latency. It is also strictly a key-value store model (with two-part keys). Values can have properties but with many strict limitations, around size of objects you can store, length of properties, and so on. These limitations are inflexible and painful if your app runs up against them.

Redis has a larger feature set. It can do key-value but also has a bunch of other data structures like sets and lists, and many apps can find ways to benefit from that added flexibility.

See 'Introduction to Redis' (redis docs) .

CosmosDB could be yet another alternative to consider if you're leaning primarily towards Azure technologies. It is pretty expensive, but quite fast and feature-rich. While also being primarily intended to be a persistent store.

Tim Lovell-Smith
  • 15,310
  • 14
  • 76
  • 93