dharmashuklaMS

Hi, I am from the Azure Cosmos DB engineering team.

All five consistency levels (strong, bounded staleness, session, consistent prefix, and eventual) are available for your Cosmos account, regardless of the number of regions it is associated with.

To answer your specific question, yes, if you choose strong consistency, you will read the latest write in any of the regions associated with your Cosmos database.

If you choose bounded staleness consistency, you can configure the number of versions (k) or time (t) up to which you are willing to tolerate the staleness for your reads in return for the write to get ack’d immediately (after it is quorum committed in the local region).

The documents below describe the consistency levels and tradeoffs: https://docs.microsoft.com/en-us/azure/cosmos-db/consistency... https://docs.microsoft.com/en-us/azure/cosmos-db/consistency...

Thanks!

Hi, I am from Azure Cosmos DB Engineering Team.

The article is referring to the implementation details of automatic failover mechanisms inside of Cosmos DB service.

For the customers, automatic failover is available as a turnkey capability. Customers do not need to spend any time to implement automatic failover.

Thanks.

Cosmos DB codebase consists of multi-million lines of C++ code. It is fully asynchronous and like all large scale (stateful) distributed systems, it is also extremely complex. The database engine of Cosmos DB (including the b-tree and the log structured storage engine) is fully latch free; the engine, resource governance subsystem, global distribution infrastructure, partition management etc -- are all deeply integrated. Each of these subsystems have extremely complex state machines which are hard to describe with the required degree of precision using the English language. Any correctness bug that gets introduced because of lack of precision, can potentially lead to data loss, corruption, partial or complete failures of the entire service. This is where TLA+ comes in.

Background: Dr. Leslie Lamport's work has been a constant source of inspiration for the Cosmos DB team. A few of the engineers on the team had learnt TLA+ initially on their own and started seeing its benefits. Subsequently, other members of the team started applying it as well. Leslie had also taught a fantastic class on TLA+ (across Microsoft), which engineers on the Cosmos DB team attended. It was a wonderful, once in a lifetime opportunity for the team to learn TLA+ from Leslie.

To be clear, Leslie personally didn't write any of the TLA+ specs for Cosmos DB. It was Cosmos DB engineers who wrote the TLA+ specs to specify & verify the design (incl. consistency models). The net result is that TLA+ made Cosmos DB a more robust system, which is crucial to offer strict and comprehensive SLAs encompassing availability, consistency, throughput and latency at the 99th percentile. Further, writing TLA+ specs for the five consistency models which we have exposed (as well as many that we have experimented, internally) enabled us to precisely define the semantics for each of the consistency models. This in-turn enables developers building apps on top of Cosmos DB, to rely on the well-defined semantics.

Hope this is helpful.

Read only transactions existed in DocumentDB too. DocumentDB was a strict subset of the capabilities that Cosmos DB provides/existed underneath. Hence, read only transactions exist in Cosmos DB too. The first technical overview blog post attempted to provide you a high level overview. We are hoping to cover specific areas in either future blog posts, conference publications.

For supporting the "oops I accidentally deleted my table/collection/graph - how do I get it back?" scenario, Cosmos DB automatically takes periodic, full backups of all your data. Currently, we restore your backups on demand and its free - you just send a mail to us. In a few months, we will expose an API using which you can restore the data you accidentally deleted yourself.

Azure Cosmos DB is not related to the work on Corfu/CorfuDB.

Cosmos DB has native extensibility to support various APIs Azure Table Storage "APIs" is one of them. If you are a Azure Table Storage customers, by virtue of accessing Cosmos DB using the Table Storage API, you can now get all of the capabilities of Cosmos DB incl. automatic indexing, global distribution etc.

Your Table Storage queries should be really fast with Cosmos DB since, Cosmos DB supports efficient indexing and query.

As the Cosmos DB SLA doc describes, for any of the 5 consistency models the service supports, the service guarantees all the other three guarantees (latency at the 99th percentile, availability and throughput) at 99.99%. One of the benefits of well-defined consistency models is that for a given model, developers can clearly make the tradeoffs between (1) latency vs. consistency, (2) availability vs. consistency and (3) throughput vs. consistency. The service documentation covers some of these tradeoffs.

See (1) https://docs.microsoft.com/en-us/azure/documentdb/documentdb... and (2) https://docs.microsoft.com/en-us/azure/documentdb/documentdb... (also check out the references at the end of the page)

Cosmos DB does local persistence and replication both within a region and across any number of regions.All data is durable and made highly available via replication. You dont need to take backups or restore them for ensuring durability or availability. See (1) https://docs.microsoft.com/en-us/azure/cosmos-db/introductio... and (2) https://docs.microsoft.com/en-us/azure/cosmos-db/introductio.... That said, if you need backup/restore for the cases where you accidentally delete your data and want to resurrect it, Cosmos DB automatically takes backups for you periodically.

There are many significant differences in capabilities, and design approaches between other systems and Cosmos DB. At a very high level. differences are at two levels - the design of the database engine and the larger distributed system. The database engine design is inspired on LLAMA http://db.disi.unitn.eu/pages/VLDBProgram/pdf/research/p853-..., Bwtree - > https://pdfs.semanticscholar.org/7655/9c6cc259c6ab5baf7bd19d... and schema-agnostic indexing techniques -> http://www.vldb.org/pvldb/vol8/p1668-shukla.pdf. Please note that these papers are significantly behind the current state of the implementation. The most crucial aspect that these papers dont cover is the integration of the database engine with the larger distributed system components of Cosmos DB including the resource governance, partition management, and the implementation of replication protocol /consistency models etc. Our goal is to publish all of the design specifications including TLA+ specs over time.

Azure Cosmos DB has been many years in the making. Azure Cosmos DB started as “Project Florence” in late 2010 to address developer the pain-points faced by large scale applications inside Microsoft. Observing that the challenges of building globally distributed apps are not a problem unique to Microsoft, in 2015 we made the first generation of this technology available to Azure developers in the form of DocumentDB. Since that time, we’ve been steadily adding new capabilities both in the database engine as well as, larger distributed system components. Azure Cosmos DB is the result. It is the next big leap in globally distributed, at scale, cloud databases. As a part of this release of Azure Cosmos DB, DocumentDB customers, with their data, are automatically Azure Cosmos DB customers. They now have access to the new system and capabilities offered by Azure Cosmos DB today as well as, as we keep evolving the service.

Hi, This is Dharma from Azure Cosmos DB team. We are super excited to make the service available today.We published the first of the series of technical blog posts here -> https://azure.microsoft.com/en-us/blog/a-technical-overview-.... Would love to answer any Cosmos DB questions.