Live data from Hacker News

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

muratbuffalo.blogspot.com

131–137 of 137 posts

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

#131
post #47
post #45

Earlier quoted context omitted.

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

Hi, I am from Cosmos DB engineering team.

Thank you for the feedback!

We have published a number of documents on pricing transparency and cost optimization of your Cosmos DB cost that we want to make sure everyone is aware of:

[1] Pricing model - https://docs.microsoft.com/en-us/azure/cosmos-db/how-pricing...

[2] Optimize cost for your dev/test workloads - https://docs.microsoft.com/en-us/azure/cosmos-db/optimize-de...

[3] Total Cost of Ownership (TCO) - https://docs.microsoft.com/en-us/azure/cosmos-db/total-cost-...

[4] Understand your bill - https://docs.microsoft.com/en-us/azure/cosmos-db/understand-...

[5] Optimize provisioned throughput cost - https://docs.microsoft.com/en-us/azure/cosmos-db/optimize-co...

[6] Optimize query cost - https://docs.microsoft.com/en-us/azure/cosmos-db/optimize-co...

[7] Optimize storage cost - https://docs.microsoft.com/en-us/azure/cosmos-db/optimize-co...

[8] Optimize reads and writes cost - https://docs.microsoft.com/en-us/azure/cosmos-db/optimize-co...

[9] Optimize multi-regions cost - https://docs.microsoft.com/en-us/azure/cosmos-db/optimize-co...

[10] Optimize with reserved capacity - https://docs.microsoft.com/en-us/azure/cosmos-db/cosmos-db-r...

If you have any questions regarding pricing, please feel free to reach out to us directly at AskCosmosDB@microsoft.com (direct line to the product team).

We do really appreciate the feedback.

Thank you.

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

#132
post #130

Earlier quoted context omitted.

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!

Thanks. I wasn't aware that a shard key is mapped to a partition key.

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

#133
post #114

Earlier quoted context omitted.

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.

Could you be a bit more specific on the what exactly is untrue?

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

#134

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.

I've found that the "Azure Storage" services (blob, queues, table) are pretty decent (for what they are). If you don't have huge throughput or size needs that is. Different beasts, but definitely useful imho.

If I need really high load/throughput, I'd probably reach for Cassandra on DO for best bang for the buck. YMMV though, and not too big on Cassandra unless you really need it.

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

#135
post #44

Earlier quoted context omitted.

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.

If you only have a few "type" options, that may be a poorly performing index unless it's used as a secondary to a query that narrows results more.

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

#136
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…

In general I have issues with the Azure documentation. I can't put my finger on it as to why, but for some reason the information doesn't seem to be presented in coherent ways, it's often disconnected and gets outdated very quickly. I can't speak as to the performance of the drivers (in general using the database drivers or a gRPC/thrift equivalent should be better than REST), but I agree with the lack of SLAs.

The lack of SLAs in the documentation is one of the major issues we've had when assessing the suitability of Azure managed services (e.g. Postgres, Cosmos DB, Bus, Event Hubs, etc.). To Azure's defence (not sure I should be doing this), a lot of these services are new and they are made available before they are operationally ready. For example, I was looking at the SQL warehouse offering a few months back [0] and if you want to use it you'd have manually maintain the statistics of the DB to keep the query plans optimised. It just seems like more overhead than necessary.

[0] https://docs.microsoft.com/en-us/azure/sql-data-warehouse/sq...

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

#137
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…

Even in this reply, you fail to mention that JavaScript and Python (and the old Java) drivers uses another protocol for which the latency SLA does not hold!

That information is vital. And it looks as though you are correcting me, when you are not.

This kind of attitude (throughout documentation) is my exact issue -- MS is always about selling, always hiding critical info, at the expense of helping engineers take the right choices.

Post reply on HN