Live data from Hacker News

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

muratbuffalo.blogspot.com

51–60 of 137 posts

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

#51
post #46

Earlier quoted context omitted.

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

Even better.

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

#52

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.

What tips in AWS's favor, roughly speaking? My general feel is GCP is slightly cheaper but is missing some offerings, while AWS is a mature 1-stop shop that's well documented.

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

#53
post #14

Earlier quoted context omitted.

Sort of. It doesn't really sanity-check anything, ever. It's more of a blank slate and you have to build whatever rules you want into your software layer. The default mode is to index every field, so you can't get into the OP's situation until you start trying to fine-tune it. He basically turned off the index and then tried to search by it. This is not expected for people who just bring their RDBMS assumptions in an…

I dont know if something changed, but there were no default indexes back when this happened (a year and a half ago). I had done no performance tuning, just created the document collections and added items to them.

It sounds like you inadvertently changed the index structure or deleted it. There have always been default indexes, and Microsoft's tuning advice is always to add special case indexes to the wildcard index they provision. If you know your data model well and want to improve write performance (RUs), you can delete the wildcard index. That's how the indexing policy has worked since the product launched.

https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-mana...

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

#54

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've used it briefly internally at Microsoft 2009, I had almost the same experience. Super slow, takes a while to even start the query, non-standard query language. For internal users there were even more hurdles: you had to get approval and quota before you were able to use it at all, and the default answer to both requests was "no", you really had to justify it. As an aside, at MS "no" was the answer to any request you make of Legal. Lots of bicycles were reinvented from scratch, with lots bugs, just because Legal would not approve the use of BSD or MIT licensed code.

Imagine my shock when I started at Google a year later and discovered Dremel (now BigQuery) where I could just run a query and get the results back in seconds over tens of terabytes of data, with no quotas or approvals.

I think having a system like Dremel is a huge competitive advantage, because you don't have to guess blindly about things, you can just query them and get results immediately. If Cosmos is still the best MS has internally, they need to roll their own Dremel asap. Lots of great people from SQL Server team work at Google now, but MS still has plenty of people who could do a competent petascale columnar DB with one hand tied behind their back.

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

#55

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.

Good luck with GCP support...

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

#56

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.

Could you go more into this? How did you go about the evaluation and what metrics were you using? How did you capture the 'developers just hated it' in a way that leadership understood?

I'm not disputing the outcome, just feel like it would be useful for others in a similar situation.

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

#57
post #11

FTA: "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.…

I can't for the life of me think of a compelling reason why regional fallover is something most companies would want in a db. It sounds great, but the reality is: the last time Azure had a regional failure, it also took down other regions. AWS and Google also have similar horror stories. On paper, regions are geographically isolated, but the reality is that in all of these instances of failure there was some "super-region" that has some core global infra that every region relied on, and it went down (AWS and us-east-1, Azure and south central US).

You don't actually want single-provider multi-regional, what you want is multi-provider, like what Anthos is trying to do. But that's a harder sell to CIOs, and Azure checks a lot of boxes on paper despite being just horrible.

The other funny thing about Azure is how they champion the number of regions they have (54), but many of these regions only have one AZ (only 8 have more than one). So when they say that something is multi-region or does regional fallover, its like, "great, that's TABLE STAKES for getting HA on Azure". But with AWS, you have at least two AZs in every region, so its not as big of a deal. GCP is the same way, but there's some language in their docs even AWS poked fun at during Re:Invent last year where they say that AZs "often" have isolated power and networking. Not always, just often. So are they truly isolated?

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

#58
post #2

Do they guarantee that if a write is done one region, when completed upon return, is available when read in another region?

I do not think so. When I last tried it they only allowed for "bounded staleness" consistency across regions despite supporting strong consistency within a region.

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

#59
post #50

Earlier quoted context omitted.

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.

I should have been more precise. Cosmo DB is their core distributed database offering. Neither of SQL server of PostgreSQL is a distributed database. Both require applications to deal with the presence of multiple database nodes (sharding).

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

#60
post #57
post #11

FTA: "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.…

I can't for the life of me think of a compelling reason why regional fallover is something most companies would want in a db. It sounds great, but the reality is: the last time Azure had a regional failure, it also took down other regions. AWS and Google also have similar horror stories. On paper, regions are geographically isolated, but the reality is that in all of these instances of failure there was some "super-r…

[deleted]
Post reply on HN