Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

muratbuffalo.blogspot.com

Post reply on HN
Print view View original

71–80 of 137 posts

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

#71

Post by dman »

foobarbazetc wrote: post #20
kuzehanka wrote: post #3

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.

The perfected enterprise sales force at Microsoft. They are good, really good. Here is a fun anecdote - There was a lawsuit where it was alleged that Microsoft business practices against Novell were anticompetetive. Microsoft was forced to sell Suse Linux as part of the judgement. For the couple of quarters where this was in play, Microsoft managed to sell more Linux than Novell.

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

#72

Post by manigandham »

equasar wrote: post #39
ResidentSleeper wrote: post #28

Earlier quoted context omitted.

That's sad to hear. I've had a lot of fun playing around with Azure's table/blob storage services. Never deployed a large production app with them, but the performance seemed decent (eg. when using table storage as a json store). I did look at Cosmos DB but decided not to give it a try when I saw the pricing.

I second this, Azure Table Storage is an amazing product, but would be a more powerful one if they enable indexing on all columns and also any automatic backup options, which are only available on CosmosDB Table, which makes me thing that Azure wants to push me to use CosmosDB if I want those features, since they don't have a roadmap for this for the Azure Table Storage.

Azure Table storage is a key/value store similar to Hbase, Cassandra, GCP Bigtable, AWS DynamoDB and others. It's a very stable and scalable design which is why everyone has some version of it.

There's no way to add indexes to this data model, it's all done by just writing your data in another table using the key you want and the value pointing to the original table's row. Perhaps Azure could offer secondary indexes like AWS DynamoDB does but it's probably too complex of a feature to add at this point, which is why it took DynamoDB several years to get to working GSI.

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

#73

Post by m0zg »

dtrailin wrote: post #69
m0zg wrote: post #54

Earlier quoted context omitted.

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…

That's impressive, considering that this CosmosDB development only started in 2014! You are talking about Cosmos which is still around but is now used as the basis of Azure Data lake [0]. However, I think the closest MS has to Dremel is actually Kusto [1] which has a custom query language but works pretty well. [0] https://azure.microsoft.com/en-ca/solutions/data-lake/ [1] https://docs.microsoft.com/en-us/azure/kusto…

You're probably right. However, having worked at MS for nearly a decade in the past, I'd be stunned if Cosmos did not serve, at least in part, as the foundation, and CosmosDB did not inherit a good chunk of the team.

Dremel now uses standard SQL and unlike Kusto it supports multiway joins and a bunch of other things expected of a more "general purpose" analytical DB.

Ultimately MS efforts will be stymied by the fact that their underlying storage story is nowhere near as good as Google's Colossus.

I won't disclose the details, but that's another thing that blew my mind: I could do linear reads (which is what columnar DBs do nearly all of the time) faster than I could process the data, from hundreds, or even thousands of workers at the same time.

The IO throughput there is truly immense, which is especially impressive given that all of the storage is remote.

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

#74

Post by manigandham »

llcoolv wrote: post #43
kuzehanka wrote: post #3

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…

CosmosDB is a JSON-based document store and it uses partitions to scale out your data. No document-store supports joins. The SQL support is only an interface to your data, it doesn't add relational functionality.

The partitionkey is required so that CosmosDB knows which partition to query. You can actually enable broadcast queries which will ask every partition if you don't want to include the partition key, but this will be slower and require more RUs.

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

#75

Post by manigandham »

lkschubert8 wrote: post #16
zzbzq wrote: 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.

Everything is indexed by default, this has always been the case.

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

#76

Post by manigandham »

ZeroCool2u wrote: post #40

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.

Spanner and CockroachDB are distributed relational databases.

CosmosDB is a JSON-based document store. It offers interfaces that emulate the ability to use SQL/Cassandra SQL/Azure Table/Gremlin graphs but this doesn't necessarily add functionality like relational joins.

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

#77

Post by manigandham »

shearnie wrote: 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.

How were you aggregating data? ComosDB is a document-store and not a relational database and wasn't designed for large-scale aggregations.

There are ways to use the Javascript UDFs to aggregate data within a partition but across-partitions is not a good fit for this architecture.

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

#78

Post by ecmascript »

foobarbazetc wrote: post #20
kuzehanka wrote: post #3

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.

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.

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

#79

Post by manigandham »

CosmosDB does have problems but the comments here seem to mostly be about not understanding the data model. It's a JSON-based document-store that distributes data across partitions.

It offers several interfaces (set at the database level) but that doesn't mean all the functionality is supported. It works well with MongoDB, Cassandra, and Table storage but you won't get relational SQL joins or fast graph search queries in Gremlin.

I agree that marketing and documentation is poor which leads to these misunderstandings. Multi-model is never perfect and people forget that emulation has a cost in performance, price and functionality.

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

#80

Post by outside1234 »

manigandham wrote: post #79

CosmosDB does have problems but the comments here seem to mostly be about not understanding the data model. It's a JSON-based document-store that distributes data across partitions. It offers several interfaces (set at the database level) but that doesn't mean all the functionality is supported. It works well with MongoDB, Cassandra, and Table storage but you won't get relational SQL joins or fast graph search querie…

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

Post reply on HN