SQLServerCentral Editorial

Is CosmosDB the One?

,

The question asked of Keanu Reeves in the first Matrix by many of the characters is whether he is the one. THe one that can save the world, and make a difference in their war. It's a fun movie, and one I've enjoyed many times. Keanu doesn't really believe he's that special until the end. That's in contrast to the products that most vendors build. Most of the times I think developers, marketers, salespeople, or all three think that whatever they've recently released is the best thing ever.

CosmosDB is mentioned in a piece as the potential one database to rule them all. The article talks about some of the basis and value that come from the platform, which Microsoft continues to push as the database that can store any kind of data and meet the needs of any application. Whether you believe that or not, I find many articles and blogs from developers that are experimenting and building systems on top of CosmosDB.

I do think the consistency models for CosmosDB are interesting, and having a variety of these models across a distributed RDBMS table would be great. I'd love to be able to insert data into a table, have it not available as a live value until committed on other nodes, and avoid locking my table. I realize I'm asking for something that seems like a bit of magic, but I bet Microsoft could add this to the SQL Server relational engine.

CosmosDB is very interesting to me, and it's an item on my list that I want to learn more about. I think there are certainly domains of problems where CosmosDB would fit very well. If any of you are working with CosmosDB, I'd be interested in knowing why and how it fits for your particular environment.

There was a quote in the article that I thought was interesting. A Microsoft Technical Fellow said, “No data is born relational. In the real world, nobody thinks in terms of schemas — they think graphs or maybe JSON document if you’re an IOT device..."

That's interesting. If I produce a JSON document, am I not thinking relational? Do I not expect that most strings, values or arrays will exist in most of the documents? Am I not thinking schema, even ragged schema, from the beginning? I'd think most data relational. It's just not easy to get it into that format when you deal with many instances of data.

Of course, dealing with many instances of data is hard for most humans. That's why we built relational databases.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating