Live data from Hacker News

Azure Cosmos DB, a globally distributed database

docs.microsoft.com

101–110 of 120 posts

Re: Azure Cosmos DB, a globally distributed database

#101

Earlier quoted context omitted.

We just did a benchmarking for a PoC on DocumentDB side-by-side Cassandra. It does the job, I have not yet seen anything revolutionary. Cassandra benchmarks seemed better.

One key difference is the cost difference between running Cosmos DB and Cassandra. We have a TCO paper ( https://aka.ms/documentdb-tco-paper ) that shows that for a 1M operations/second workload, Cosmos DB is significantly 3x-10x cheaper than other systems.

And white papers are full of it. Has random things like s Cassandra cluster needs 1 full time engineer per 100 nodes. Where do you come up with this stuff?

Re: Azure Cosmos DB, a globally distributed database

#103

Earlier quoted context omitted.

One key difference is the cost difference between running Cosmos DB and Cassandra. We have a TCO paper ( https://aka.ms/documentdb-tco-paper ) that shows that for a 1M operations/second workload, Cosmos DB is significantly 3x-10x cheaper than other systems.

And white papers are full of it. Has random things like s Cassandra cluster needs 1 full time engineer per 100 nodes. Where do you come up with this stuff?

In my experience of Cassandra (working on an application client, not managing it), one FTE per hundred nodes is extremely generous.

Re: Azure Cosmos DB, a globally distributed database

#104
post #8

Earlier quoted context omitted.

this is a little bit hard to believe. Inter region Ping can even take longer than 15ms... I guess this SLA is for eventual consistency model not strong consistency model

The latency SLAs are within the same Azure region. You can distribute your data across any of the 30+ regions that Azure is available in. Your apps always read from the local/closest region with the homing APIs.

That didn't answer the question: will all regions be always consistent?

Re: Azure Cosmos DB, a globally distributed database

#106
post #100

Earlier quoted context omitted.

Actually, I wish Microsoft would stop referring to replication when asked about backup. It's the modern way of saying "You probably don't need backup, because you have RAID". There's a reason Azure SQL Database has self-service point-in-time-recovery despite also having replication. Do you see many use cases where there is no need for backup to protect against accidental deletion, overwriting, deletion by application…

Totally agree with you. Even if you have delayed copies, you still need proper backup in place. They recently implemented long term retention for Azure SQL backups in Azure: https://azure.microsoft.com/en-us/blog/azure-sql-database-no... as it was only allowing 'til 35 days. I would expect that something similar is provided also for this type of DBs

One can hope. Blob and table storage still have no form of backup ~8 years after introduction.

When I've asked they have been referring to replication and to call them if we accidentally lose data. But we need to contact them within two hours otherwise it's too late. And of course Azure Support never responds that quickly when I submit a case to them.

Re: Azure Cosmos DB, a globally distributed database

#107
post #104

Earlier quoted context omitted.

The latency SLAs are within the same Azure region. You can distribute your data across any of the 30+ regions that Azure is available in. Your apps always read from the local/closest region with the homing APIs.

That didn't answer the question: will all regions be always consistent?

We would invite you to explore the consistency levels available in Cosmos DB. As a developer you can choose what makes most sense in distributed scenario. https://docs.microsoft.com/en-us/azure/documentdb/documentdb... Eventual is one end of the consistency. But then consistent prefix, session (if you can control) and bounded staleness all can play a role.

Re: Azure Cosmos DB, a globally distributed database

#108
post #62

Earlier quoted context omitted.

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. S…

Is GROUP BY support a possibility in the future? I was a little disappointed to see aggregates implemented without them after waiting for so long... Here's a link for anyone who would like to vote for this feature. https://feedback.azure.com/forums/263030-documentdb/suggesti...

Thanks - this and other features are planned. Please stay tuned.

Re: Azure Cosmos DB, a globally distributed database

#109
post #84

Does it provide search? It's a strange thing, but almost all new database technologies seem to leave search as an afterthought for some later day instead of starting on day one with the assumption that "it's all about search". A database system that doesn't support rich search capabilities is restricted to very limited types of applications. Often search is left unimplemented for years, or perhaps never implemented.

[Full disclosure, I work on the Azure Search team]

Cosmos DB has tight integration with Azure Search, to the point that you can choose to extend your Cosmos DB to Azure Search with a few clicks right from the portal to allow for full text search over this content.

You can learn more about how to do this at these two links: https://azure.microsoft.com/en-us/blog/adding-search-to-docu...

https://docs.microsoft.com/en-us/azure/search/search-howto-i...

Liam

Re: Azure Cosmos DB, a globally distributed database

#110

Is Cosmos related to the work on Corfu/CorfuDB [2] [1] in any way? [1] https://www.microsoft.com/en-us/research/publication/corfu-a... [2] https://github.com/CorfuDB/CorfuDB

AS Dharma mentioned - 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.

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.

Post reply on HN