This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(16, 16%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EEC%3C/text%3E%3C/svg%3E)
Hi,
I'd like to get some guidance for value proposition between Azure Redis and Cosmos as distributed caching layer for applications.
It is quite a typical use case where we need a performing, highly available cache for slow changing datasets for real time lookup. Source of truth is a database from which cache is warmed and updated.
Azure Redis was initiate pick as supposedly, it is positioned perfectly for this use case. However, after I look closely and few PoCs, it doesn't look like the case anymore:
Cost optimisation: Premium P1 Redis costs $4500 AUD (we need zone redundancy and vNet integration) a year while our existing cosmos db serves 2K+ requests per day costs under $100 a year.
Reliability: Redis premium is of 99.9% while Cosmos is 99.99% with serverless set up
Performance efficiency: redis is charged by hour while Cosmos can be serveless.
Last but not least, I don't see any noticeable difference in E2E latency - see below. Note that Cosmos read in this case is a query rather than read by id (which makes is slightly slower) while redis read is by id on standard tier instead of permium.
2022-07-06T11:57:56.460 [Information] Redis read: 0.01117253303527832 secs
2022-07-06T11:57:56.883 [Information] Cosmos read: 0.02537059783935547 secs
The key takeaway is that with 20ms~ end to end latency for a read for Cosmos and other benefits mentioned above, I don't see the value proposition for redis for a lot of use cases as distributed caching Laye.
Hi @Eliot Chen ,
There are a couple of issues that I think will prevent you from choosing the integrated cache in Cosmos DB at this time:
To state the obvious, the integrated cache for Cosmos DB will be tied to Azure Cosmos DB. If you have use other databases (such as SQL Server), you wouldn't be able to use the integrated cache for Cosmos.
Hopefully this helps! It would be interesting to hear more about your use case if possible to go into a bit more depth with you on the integrated cache in Cosmos DB.
Thanks anonymous user-MSFT for making me aware of integrated cache in Cosmos DB.
However, my question and its associated comparison and PoC was done against Cosmos DB itself - see code snippet below. My point is, Cosmos BD itself (not integrated cache) is as performing as Redis Cache as a caching layer for reads, I question value proposition for Redis as I don't see it advantage over Cosmos from reliability, performance efficiency, cost optimisation and even raw performance perspective.
client = CosmosClient(url, credential=key)
database = client.get_database_client(database_name)
container = database.get_container_client(container_name)
for item in container.query_items(
query='SELECT * FROM mycontainer r WHERE r.id="item'+str(number)+'"',enable_cross_partition_query=True):
Thanks for clarifying @Eliot Chen
Some engineers like to use Cosmos as a cache and it can work, but with this, there are some things to keep in mind. You'll need to be mindful of the size of data that you are caching, as RU expenditure increases as the size of your data increases within an item. Indexing also plays a part here as the more properties your data has, the number of RUs consumed to write to Cosmos increases. You can counter this by limiting the number of indexed properties within your item that you cache: https://learn.microsoft.com/en-us/azure/cosmos-db/request-units#request-unit-considerations
From your code snippet, I'd recommend avoiding cross partition queries in Cosmos DB when looking up items in your cache. These queries fan-out to all physical partitions even if the data you are trying to query doesn't exist on that physical partition. This will cause bottlenecks in performance, slowing down your application: https://learn.microsoft.com/en-us/azure/cosmos-db/sql/how-to-query-container#cross-partition-query
In short, if you use Cosmos DB as a cache, keep the amount of data you cache small and ensure that you select a good partition key to optimize your queries and RU expenditure (maybe the document ID, based off that snippet). You can also implement Time-To-Live policies on that data to ensure the cache doesn't grow too large: https://learn.microsoft.com/en-us/azure/cosmos-db/sql/time-to-live
Thanks anonymous user-MSFT, I understand there is an upside of be paying by an hour if that it put a cap in your spend.
And in our use case, those datasets (reference data) are quite small (<500 records) and slow changing.
I appreciate your feedback on how to keep our cost down which is very useful!
I will close this question now.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(201.6, 74%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EHZ%3C/text%3E%3C/svg%3E)
Will, if you use point reads, cosmos RU is not a problem. Redis cache is way too expensive for the service it provides.
In terms of SLA, how does cosmos compare with the different tiers of redis cache?
Everything boils down to SLA if you assume cosmos point reads, ttls, small documents and no indexing.
Thoughts?