Live data from Hacker News

Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

muratbuffalo.blogspot.com

41–50 of 137 posts

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#41
post #8

Cosmosdb still doesn’t support skip and take. And aggregate queries are incredibly inefficient. We’ve had to move a heap of data from cosdb to sql server, our reports ran from 3 hours, to now 5 minutes after moving to SQL.

I may be taking your post at face value, but I suggest if you are using skip, i.e. LINQ Skip(), that you stop. SQL's performance using OFFSET is pretty terrible when you start getting into the 10's of thousands of records. Instead, use seek instead.

Here's some random google result that talks about the concept. There are plenty out there though.

https://blog.jooq.org/2013/10/26/faster-sql-paging-with-jooq...

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#42
post #36

Earlier quoted context omitted.

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.

Surely you're referring to Microsoft's team's time to implement failover to the product offering, not time every customer spends on implementation??? FTA: "if _you_ are an engineer working on a small thing, say datacenter automatic failover component" (emphasis added). Pretty sure he's talking about EVERY customer spending months to turn on fail-over.

The previous poster is correct, I think you are mistaken. It should read like this:

"if you are an engineer at Microsoft working on a small azure component, say datacenter automatic failover component"

At least this is how I read it since the OP works at MS it appears.

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#43

After 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…

Unfortunately, I could only second this opinion and add a few points of mine.

1. Many unexpected behaviours which you would not encounter in any other software - for example when you're blocked by its firewall, it would let you connect on all 7 OSI layers, then kick you out with "Command failed with error 13: 'Not Authenticated' on server xyz:10255'". By the way even Azure Portal itself doesn't know how to handle this behaviour correctly and when not included in the firewall whitelist just blinks like crazy.

2. Many seemingly basic features commonly found on other database systems are for some reason missing here - it doesn't support users as such, just issuing resource tokens[1] (which you must implement yourself). Thus, most CDB users just go straight with the master key even on production.

3. It is not fully (nor at least nearly fully) compatible with any of the advertised APIs - SQL doesn't support joins, MongoDB misses quite a few features and adds a requirement for the shardkey to be part of the query. Which is not supported by Spring Data, so you must do low-level queries for everything but select (think updates field by field with null checks).

4. The tooling is horrible - as it is not compatible with neither mongodb nor traditional sql, you would need to include the "CosmosDB Emulator" in your build in order to have at least some predictability. The problem? It only runs on docker4win and a Windows VM would need to be running by all developers on the team and workers of the CI/CD. As of April 2019

5. It is CRAZY expensive and the pricing is not really transparent - in our case we had 20 MB of data, 4 1000RUs collections and multi-master write in Western and Northern Europe. The monthly bill? 300 EUR even though Azure Portal was displaying 1/6 of that cost - apparently for multi-master you multiply by the number of regions + 1 (2+1 = 3) and for geo-redundancy only by the number of regions (2), thus the 6x higher cost. The result of that was that we were paying several times more to manage 20MB of data than for all the remaining data - hundreds of GB.

Maybe if you really, really need the planetary scale, the master-master replication and the 1. https://docs.microsoft.com/en-us/azure/cosmos-db/secure-acce...

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#44

After 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

I usually put multiple document types into a single collection and have a “type” field to get around this. The fields are indexed so this is efficient. To decide when to use a different collection I look at the scalability and other settings at the collection level, and group things that have similar needs together.

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#45
post #43

After 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…

Unfortunately, I could only second this opinion and add a few points of mine. 1. Many unexpected behaviours which you would not encounter in any other software - for example when you're blocked by its firewall, it would let you connect on all 7 OSI layers, then kick you out with "Command failed with error 13: 'Not Authenticated' on server xyz:10255'". By the way even Azure Portal itself doesn't know how to handle thi…

> It is CRAZY expensive and the pricing is not really transparent - in our case we had 20 MB of data, 4 1000RUs collections and multi-master write in Western and Northern Europe. The monthly bill? 300 EUR even though Azure Portal was displaying 1/6 of that cost - apparently for multi-master you multiply by the number of regions + 1 (2+1 = 3) and for geo-redundancy only by the number of regions (2), thus the 6x higher cost. The result of that was that we were paying several times more to manage 20MB of data than for all the remaining data - hundreds of GB.

I get your point and they should definitely fix either the cost calculation, or paste a disclaimer for multi-region pricing. But I want to (sincerely) ask how you could assume that multi region would _not_ cost more than single region.

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#46

After 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…

I am sorry to have to argue, but the multi-region writes are calculated N + 1, where N is the number of regions. So it would actually set you back $17520 [0]. And yes, I know that even their own documentation and calculator conflict on this, but they do charge the higher number.

0. https://docs.microsoft.com/bg-bg/azure/cosmos-db/optimize-co...

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#47
post #45
post #43

Earlier quoted context omitted.

Unfortunately, I could only second this opinion and add a few points of mine. 1. Many unexpected behaviours which you would not encounter in any other software - for example when you're blocked by its firewall, it would let you connect on all 7 OSI layers, then kick you out with "Command failed with error 13: 'Not Authenticated' on server xyz:10255'". By the way even Azure Portal itself doesn't know how to handle thi…

> It is CRAZY expensive and the pricing is not really transparent - in our case we had 20 MB of data, 4 1000RUs collections and multi-master write in Western and Northern Europe. The monthly bill? 300 EUR even though Azure Portal was displaying 1/6 of that cost - apparently for multi-master you multiply by the number of regions + 1 (2+1 = 3) and for geo-redundancy only by the number of regions (2), thus the 6x higher…

You are perfectly correct, but I assumed that for 2 regions it would cost twice the amount, not 6 times.

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#48

After 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 second this. We evaluated AWS, Azure and GCP for a very large healthcare company and found that Azure was the worst cloud services provider for anything. This was in spite a big push by leadership to encourage Azure, developers just hated it Between AWS and GCP even though AWS come out on top, GCP wins in quite a few services.

Well Azure comes with the biggest compliance/certification package - of course upper management will love it.

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#49

After 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

It actually supports throughput provisioning on database-level (or container-level as they sometimes call it). The only catch is that you'll have to recreate the db (on creation is the only time when you can enable it) and data migration is not exactly quick.

Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database

#50

After 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 sounds really bad. I wonder how did Azure gain marketshare with a core offering (database) being so broken.

The core database is SQL Server and they also have PostgreSQL. This is what most people are using.
Post reply on HN