CODEWITHSUNDEEP
azure-cosmosdb
MonkeyBonkey
MonkeyBonkey

Reputation: 47861

Should CosmosDB be modeled like a document database or a graph database?

I see that a CosmosDb can support both graph queries as well as more traditional SQL like queries - however I'm a bit confused about what kind of underlying schema is best at the collections level. If I were to model something in MongoDb or SQL Server, or Neo4j, I would have very different schemas. Also - it seems like I can query using more traditional SQL-like syntax - which makes it confusing about what's right or efficient underneath. Sometimes, making something easy to query does not mean that one should assume that it's an efficient query.

Is CosmosDb at it's heart a document database and I should model it accordingly - or is it a very different beast.

Example use case

Here's an example- let's say I have:

  1. a user profile
  2. multiple post types (photo, blog, question)
  3. users can like photos
  4. users can comment on photos, blogs, questions

With a sql database I would have tables:

and join tables with referential integrity to support the actions:

With a graph database

I would just have the same core tables

and just create graph relationship types for like and comment - relying on the code business logic to enforce the rule that you can't like blogs, etc..

With a document db like MongoDb

Again, I might have the same core tables

Comments would be sub collections under each - and there would be a question of whether we want to keep the likes as an embedded collection under each profile, or under photos.. and we would have to increment and sync a like count to the other collection (depending on the use case we might create a like collection as well). Comments would be tucked under each photo, blog or question as an embedded collection and not have their own top-level collection.

So my question is this:

How do we model this schema in CosmosDB? Should we model it like a traditional Document Database like MongoDb, or does having access to a graph query allow us additional freedoms like not having to denormalize fields for actions such as "like?"

Upvotes: 1

Views: 826

Answers (2)

Fei Han
Fei Han

Reputation: 27793

How do we model this schema in CosmosDB? Should we model it like a traditional Document Database like MongoDb, or does having access to a graph query allow us additional freedoms like not having to denormalize fields for actions such as "like?"

When you start modeling data in Azure Cosmos DB, you need to consider: 1.Is your application read heavy or write heavy? 2.How is your application going to query and update data? etc. Normally denormalized data models can provide better read performance, normalizing can provide better write performance.

This article explained with example how to model document data for NoSQL databases, and shared some scenarios for using embedded data models, normalized data models and Hybrid data models, which should be helpful.

Upvotes: 1

Rimma
Rimma

Reputation: 56

Azure Cosmos DB database engine is designed to be fully schema-agnostic. A container (which can be a graph, a collection of documents, or a table) is a schema-agnostic container of arbitrary user generated content which gets automatically indexed upon ingest. I suggest to read "Schema-Agnostic Indexing with Azure DocumentDB" - http://www.vldb.org/pvldb/vol8/p1668-shukla.pdf, which is the same in Cosmos DB to better understand the details.

Upvotes: 1

Related Questions