As far as I know, apart from the global distribution, virtually any major database offer the same thing today
Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
111–120 of 137 posts
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#112Earlier quoted context omitted.
Wow, is that really the case? The last “cloud provider” I remember this to be the case was SoftLayer. Is Azure really that bad?
With AKS (at least in early days, not beta or anything mind you) the kubernetes coordinator node was managed by Microsoft, after a some arbitrary amount of days/weeks it would become unresponsive and the recommended action was to open a ticket and wait for them it restart it.
Azure Kubernetes Service provides a free managed Kubernetes control plane. Certainly possibly that prior to general availability a support ticket had to be opened to restart this. The control plane's underlying VMs aren't exposed on purpose. That's similar to what other providers do with managed Kubernetes services.
Hopefully the unresponsiveness issue was addressed quickly after it was reported by you.
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#113The 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…
Google Datastore [1] works the same way. I imagine it's because indexes can be configured per row. So for example if you have a boolean value and only ever query for it to be true then you might set the index on only if it's true. The reason you might want to use indexes scarcely is because they cost money. For Google Datastore they used to cost extra write operations and storage. Now they just cost storage.
--
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#114After 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.
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#115Earlier quoted context omitted.
Woa, wtf. Is that indicative of the general quality level of cosmos?
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…
What documentation though? Cosmos' documentation is appalling... it is not like you can learn these things from it. With Cosmos you are always on your own, trial and error, to figure out how it behaves
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#116Earlier quoted context omitted.
The problem is that their marketing and docs make it sounds like it is the solution for everything. Legacy Cassandra workload? Use CosmosDB Graph Database? Use CosmosDB Legacy MongoDB database? Use CosmosDB SQL Server database? Use CosmosDB When the only really valid use case is: Document Database? Use CosmosDB
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 between different tables, it is NOT anything close to SQL. Joins is sort of the point of SQL.
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#117Beware 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 requires being on .NET and using the official driver that communicates over a closed undocumented binary protocol. (even the Java driver having the full SLAs and using the binary protocol was launched just weeks ago).
IMO it would have been less misleading if MS had just removed the docs for their REST API. Or at least put up a big warning about it being an undocumented afterthought.
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#118Based 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.
Really? You can’t figure out why someone might use a Microsoft hosted db over one at google or one they’d have to run themselves? Azure’s growth rate is amazing. There’s a ton of adoption there that doesn’t have access to spanner, or maybe has a document based data model, where spanner / cockroach doesn’t make any sense
[deleted]
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#119Earlier 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…
What documentation though? Cosmos' documentation is appalling... it is not like you can learn these things from it. With Cosmos you are always on your own, trial and error, to figure out how it behaves
This documentation: https://docs.microsoft.com/en-us/azure/cosmos-db/index-overv...
There are dozens of pages there. It may not be perfectly organized but saying you can't learn anything from it is silly. And regarding indexing, the 2nd sentence on the page says this: "By default, Azure Cosmos DB automatically indexes all items in your container without requiring schema or secondary indexes from developers."
Re: Azure Cosmos DB: Microsoft's Cloud-Born Globally Distributed Database
#120Earlier quoted context omitted.
You also forgot to mention that it is crazy expensive if you have lots of collections
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.