Earlier quoted context omitted.
Cockroachdb is a proper SQL Database, Cosmos is just a Document Store that also has an SQL interface.
Can you explain in some precision what you mean by that?
Sounds petty precise to me already
Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
21–30 of 137 posts
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#22After trying CosmosDB I put it down pretty quickly. I can't say I'd recommend it to anyone. Shockingly poor perf. Is CosmosDB really that bad or did we have it misconfigured? We're not sure, the docs didn't help us understand. Random failures when connecting. Random errors (or worse, no errors but unexpected results) when querying. Largely undocumented. Painful interop with non-azure proprietary offerings. Almost zer…
I can say this exact thing about most Azure services. Nothing really works as documented and everything is more expensive than it should be. I always feel like I’m missing something.
It's hard to get behind cloud services that require you to send an email to support engineers to reboot your instance.
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#23FTA: "say datacenter automatic failover component, in one part of the territory. Getting this component right may take months of your time. But it is OK. You are building a new street in one of the suburbs, and this adds up to the big picture." Wait, what?! Driving metaphor aside... 'MONTHS of your time' to implement failover? People, this is WHY the cloud was invented, so we didn't have to spend months re-inventing.…
He's talking about building the underlying failover mechanism for CosmoDB. For a customer it's easy and automatic, but GCP and AWS and Azure have to build it first.
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#24After trying CosmosDB I put it down pretty quickly. I can't say I'd recommend it to anyone. Shockingly poor perf. Is CosmosDB really that bad or did we have it misconfigured? We're not sure, the docs didn't help us understand. Random failures when connecting. Random errors (or worse, no errors but unexpected results) when querying. Largely undocumented. Painful interop with non-azure proprietary offerings. Almost zer…
To the brave, I recommend trying to make a copy of a CosmosDb collection.
The only solution that doesn't require spinning up a VM, reading all the data and writing it back again is the Azure Data Factory [0]. Which according to Azure's own benchmarks [1] manages to copy only 2MBps between two CosmosDb instances each with 100,000 RUs ("Resource Units"). That's more than half a day for a small 100GB collection.
And in case you're wondering whether 100K RUs is a lot, consider the cost: 5840$/Month for single-region writes. 11680$/Month for multi-region writes [2].
Oh, and as a bonus - can you guess the official procedure for restoring a collection from a backup? [3]:
> If you have accidentally deleted or corrupted your data, you should contact Azure support within 8 hours so that the Azure Cosmos DB team can help you restore the data from the backups.
And yeah, it's 8 hours because they backup the database every 4 hours and keep the last two backup copies [3]
[0]: https://docs.microsoft.com/en-us/azure/data-factory/introduc...
[1]: https://docs.microsoft.com/en-us/azure/data-factory/copy-act...
[2]: https://azure.microsoft.com/en-us/pricing/details/cosmos-db/
[3]: https://docs.microsoft.com/en-us/azure/cosmos-db/online-back...
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#25Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#26This was a really interesting write up. Doing a sabbatical with a large distributed systems team sounds really cool.
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#27FTA: "say datacenter automatic failover component, in one part of the territory. Getting this component right may take months of your time. But it is OK. You are building a new street in one of the suburbs, and this adds up to the big picture." Wait, what?! Driving metaphor aside... 'MONTHS of your time' to implement failover? People, this is WHY the cloud was invented, so we didn't have to spend months re-inventing.…
He's talking about building the underlying failover mechanism for CosmoDB. For a customer it's easy and automatic, but GCP and AWS and Azure have to build it first.
But months?
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#28After trying CosmosDB I put it down pretty quickly. I can't say I'd recommend it to anyone. Shockingly poor perf. Is CosmosDB really that bad or did we have it misconfigured? We're not sure, the docs didn't help us understand. Random failures when connecting. Random errors (or worse, no errors but unexpected results) when querying. Largely undocumented. Painful interop with non-azure proprietary offerings. Almost zer…
That's sad to hear. I've had a lot of fun playing around with Azure's table/blob storage services. Never deployed a large production app with them, but the performance seemed decent (eg. when using table storage as a json store). I did look at Cosmos DB but decided not to give it a try when I saw the pricing.
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#29The absolute worst bug I have ever had to debug was using CosmosDB as table storage. Everything worked fine up until we hit about 1700 records in table storage. Once we hit that point it just stopped returning any records. We eventually find out that if you query using a field that isn't indexed instead of throwing an error or something sane like that it acts like everything is fine and returns an empty set of record…
That must be the famous Mognodb compatibility layer kicking in. ~/s
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#30After trying CosmosDB I put it down pretty quickly. I can't say I'd recommend it to anyone. Shockingly poor perf. Is CosmosDB really that bad or did we have it misconfigured? We're not sure, the docs didn't help us understand. Random failures when connecting. Random errors (or worse, no errors but unexpected results) when querying. Largely undocumented. Painful interop with non-azure proprietary offerings. Almost zer…
You also forgot to mention that it is crazy expensive if you have lots of collections