azure-docs
azure-docs copied to clipboard
What do you mean by "covering" and "non-covering" cache in Azure SQL Hyperscale?
In the architecture diagram of Azure SQL Hyperscale, there's two types of cache: covering SSD cache and non-covering SSD cache which are denoted by blue and yellow color respectively. But what do you mean by "covering"? Google Search suggests the only place where such terminologies are used is this document, and even on this document there's no explanation of "covering". I can only guess that "covering" means all SSD cache on Page servers coolectively constitutes a full copy of the database whereas the non-covering SSD cache on Compute nodes only stored part of it. But I don't know if this is correct and I really think it needs explicit clarification since this document is the only place where they're used.
This property is also unspecified in Microsoft Socrates's paper as well.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.
- ID: 5724fceb-f8c8-f459-c4ab-546876c61b1d
- Version Independent ID: c72458b7-c9ff-5faf-d24c-a730327ccdb3
- Content: Hyperscale distributed functions architecture - Azure SQL Database
- Content Source: azure-sql/database/hyperscale-architecture.md
- Service: sql-database
- Sub-service: service-overview
- GitHub Login: @dimitri-furman
- Microsoft Alias: dfurman
#assign:WilliamDAssafMSFT
#assign:dimitri-furman
Thanks @Ray-Eldath for contacting Microsoft with feedback about our product documentation. It could take from a few business days to a few weeks to look further into this with the product team and decide on how to address. A conversation about your feedback on this image is already underway. We'll contact you if we need further information, and you'll receive an email message each time we mention you in a comment.
I think I've figured it out. I just checked the Microsoft's Socrates paper which is the acadamic prototype of Azure SQL Hyperscale, and in Section 4.6 Page Servers it says
SQL DB Hyperscale currently implements Page Servers using a covering cache; i.e., all pages of the partition are stored in the Page Server’s RBPEX. ... Since the Page Server’s cache is dense, the Pager Server does not suffer from read amplification while the sparse RBPEX caches at Compute nodes do.
So I think it's clear now "covering" means each Page Server cache all data it is responsible for in a sequential and dense way, as opposed to "non-covering" cache in those Compute nodes that only cached data in a on-demand fashion (thus sparse). and if the common understanding of "partition" (a database is partitioned into several partitions, nothing left and no gap inbetween) holds true for Hyperscale as well, this also means that "all SSD cache on Page servers collectively constitutes a full copy of the database" which justifies my conjecture from the beginning. Nonetheless, such explanation should be noted in the Azure SQL Hyperscale's document since nothing but there are these terms ("covering cache") used and people don't always refer to paper for explanation.
Thanks again @Ray-Eldath for taking the time to provide this documentation feedback. After a conversation with the PG I think we can make this more clear, a doc update is in flight. Thanks again for this feedback, your suggestions help improve our documentation.
#please-close
Has this been resolved in our documentation? If yes, can you point me to it because it seems it hasn't been indexed by search engines.