I'd like to see an in-depth comparison with Google Cloud Spanner.
They're very different things. It's like wanting an in-depth comparison between SQL Server and Redis.
Azure Cosmos DB, a globally distributed database
81–90 of 120 posts
Re: Azure Cosmos DB, a globally distributed database
#82Earlier quoted context omitted.
I didn't claim cross-dc consistency. I said failover, which is shockingly hard to make many competitors do. The key here is that only one DC can take writes but the failover works transparently with your client (also with clear SLAs).
Why do you need failover if you have global multimaster like Spanner?
An interesting thing to point out is the current beta for Cloud Spanner does not have multi-region deployments... and instead, allows you to do single-region deployment in your choice of 3 (not >30) regions:
https://cloud.google.com/spanner/docs/instance-configuration
Re: Azure Cosmos DB, a globally distributed database
#83Databases is one area that Amazon is way behind Google and Microsoft. DynamoDB is thoroughly awful so good to see some competition.
Re: Azure Cosmos DB, a globally distributed database
#84Does 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.
Re: Azure Cosmos DB, a globally distributed database
#85Does 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.
It does support search through SQL like queries. You can use existing functions or implement new ones in Javascript. If you want free text search, you would be disappointed, but otherwise it is pretty decent.
Re: Azure Cosmos DB, a globally distributed database
#86Does 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.
It does support search through SQL like queries. You can use existing functions or implement new ones in Javascript. If you want free text search, you would be disappointed, but otherwise it is pretty decent.
So half marks on search for Azure Cosmos DB.
If free text search is such a hard problem then you'd think that would be even more reason to start with solving that toughest of all problems. If it's a really hard problem then it will be even harder to retrofit later into some system that is already architected and built.
A light spanking for the architect. No search would have been a thorough spanking.
Re: Azure Cosmos DB, a globally distributed database
#87What's the CAP tradeoffs of Cosmos? It's not clear to me looking at the SLA docs.
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)
Re: Azure Cosmos DB, a globally distributed database
#88From the intro page[1]... Many of the descriptions comparing to NoSQL are wrong. There are plenty of NoSQL options that have similar features, though it isn't universal, it can and often is there. Cassandra, for example, probably does just as well in multi-zone/dc concurrency. Consistency options are also similarly tunable. Cockroach 1.0 was announced earlier as well. It's not that I don't appreciate the option. This…
Azure Table Storage? Uggh. Nasty. I've tried half a dozen times to use them, and every time I've given up. Great for write-only data that you never want to see again. Horrible for real-world querying.
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.
Re: Azure Cosmos DB, a globally distributed database
#89I can't seem to find the old DocumentDB prices any more, but it seems like it's a lot cheaper now? Also, is User-Defined Performance something new? since last time I looked into DocumentDB you had to pay the monthly RU fee per 10GB disk.
One more thing, as someone who went from DocumentDb to Azure Storage (Tables) back in April 2016 because of the higher price, slower queries, and scalability problems, is there anything that may make Cosmos DB a better option?
Re: Azure Cosmos DB, a globally distributed database
#90Hi, 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.
Are graph ops/queries atomic? i.e. if you run a tree query on a tree-graph, at the same time you're re-parenting a treenode, is there a chance that the node could end up in the result tree twice or zero times?
Also, if they're atomic, are they optimistic or pessimistic transactions? Also if they're atomic, does that mean queries done on the write server? (My understanding is that readonly transactions on read-replicas are not supported, or at least they weren't under DocDB).
Any lay-programmer insight into what's going on under the hood, or at least performance/atomicity implications, without giving up too much proprietary info, would be appreciated.