Live data from Hacker News

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

muratbuffalo.blogspot.com

121–130 of 137 posts

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

#121
post #114

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's good to know. My team is currently using Neo4j, but may be forced to switch to either Neptune or Cosmos. I figured those were probably pretty similar, but this sounds like Cosmos might be a really bad idea.

I am a Cosmos DB graph engineer and would encourage you to take the service for a spin and build your opinion. This thread unfortunately has more emotions than truth to it. We build the service with best intentions in mind.

Feel free to reach out to us at askcosmosdb@microsoft.com any time with any questions.

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

#122
post #116

Earlier quoted context omitted.

Yes, I said exactly that. Multi-model is a hard problem and only really works with similar data models. It's also confusing since people conflate SQL and relational semantics when it's really just a query language. It does work well enough if you have an OLTP document use-case like MongoDB, Cassandra, and JSON/SQL.

Disagree about "conflate". SQL is very geared towards relational semantics. They may be independent in theory (a stretch), but any non-trivial SQL query (say a medium sized one with 50 lines abd 10 tables) is meaningless without a relational DB underneath. What Cosmos calls "SQL" is not SQL at all, it lacks almost everything, it just borrows a few keywords. If you cant even do inner joins and left joins and so on bet…

[deleted]

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

#123
post #100

Hey CosmosDB team in the comments: Building distributed databases at scale is hard af, few people know what it’s like to run hundreds of thousands of databases. Don’t be discouraged by random negative posts, remember you’re doing something most of the world can’t do.

Appreciate it.

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

#125

Based on the feedback here, it's hard to imagine anyone choosing Cosmos DB over Spanner or just CockroachDB. I'm not familiar with the AWS equivalent, but it seems like Azure isn't exactly setting the bar high.

Comments here are rather negative yet service is growing very rapidly so there is a disconnect. I would encourage you to try service and develop own perspective.

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

#126
post #117

Beware of the REST API of Cosmos. We fell into the trap of using it.. 1) it is not covered by the latency SLA. This is buried pretty deep... 2) suddenly you get magical responses that are supposed to trigger the client to do something (e.g. sql qyeries with order by requires some algorithm client side). These things are not docoumented anywhere, you have to read the Node or Python client libs.. Using Cosmos mainly re…

Hi, I am from Cosmos DB engineering team,

Cosmos DB offers Java, Javascript, Python, and .NET drivers. Just like with most databases, it is recommended for applications to use drivers to work with Cosmos DB.

Cosmos DB offers REST API to work with data, documented at [1]. The primary focus of the REST API is SDK developers for platforms where we do not provide drivers yet. Just like most databases, we recommend to use provided drivers where available. This REST API is not intended for broad consumption by the apps. Your point about being more explicit about scenario the REST API is intended for and supported for is well taken. We will improve the documentation.

[1] https://docs.microsoft.com/en-us/rest/api/cosmos-db/

thanks for feedback!

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

#127
post #100

Hey CosmosDB team in the comments: Building distributed databases at scale is hard af, few people know what it’s like to run hundreds of thousands of databases. Don’t be discouraged by random negative posts, remember you’re doing something most of the world can’t do.

Thanks for the kind words.

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

#128

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

Wha? I've built several (Currently about 20) enterprise application integrations across our infrastructure using Logic Apps, Function Apps, Service Bus, Cosmos etc. The cost of running these is less then our budget for office supplies. I'm literally paying pennies.

Proof: https://imgur.com/a/asem3d9

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

#129

Earlier quoted context omitted.

Cmon this is an extremely exaggerated opinion. I have used Azure and AWS and I find Azure to be much easier and user friendly. Maybe at very large scale AWS shines through, but I would choose Azure over AWS any day.

you're literally the mythical unicorn, I don't know a single person that has appreciated using Azure. I'd personally trade my first born with no second thoughts to use AWS instead.

Surely you exaggerate. Azure is great I think AWS is garbage in comparison.

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

#130
post #96

Earlier quoted context omitted.

Hi, I am from Azure Cosmos DB Engineering Team. @llcoolv has responded and the response is correct. For scenarios where you create a lot of collections/tables, we recommend to provision throughput on a database and share the provisioned throughput among all the containers – to save on costs. You can change the throughput at database exactly like how you will change the throughput at container level. It is the same AP…

Hello, I am aware that one can provision per database, but as another poster mentioned, you can't change that once a database is created, and also you need to specify something that's called partition keys and that can't be done using MongoDB driver. If I recall correctly, you don't even have examples available for that in CosmosDB Python API. I mean yeah - it's possible. But it is also a pain in the ass.

Hi, I am from Cosmos DB engineering team.

Yes, for shared throughput database, you will need to create a new database.

- You can create MongoDB API collections with shard keys defined. It is fully supported by MongoDB driver

- Support MongoDB collections without shard key specified is coming in May

Thank you for the feedback on the docs and the missing code samples. We will add those in the docs.

Thanks!

Post reply on HN