Azure Cosmos DB Update Pattern

Question

I have recently started using Cosmos DB for a project and I am running into a few design issues. Coming from a SQL background, I understand that related data should be nested within documents on a NoSQL DB. This does mean that documents can become quite large though.

Since partial updates are not supported, what is the best design pattern to implement when you want to update a single property on a document?

Should I be reading the entire document server side, updating the value and writing the document back immeadiately in order to perform an update? This seems problematic if the documents are large which they inevitably would be if all your data is nested.

If I take the approach of making many smaller documents and infer relationships based on IDs I think this would solve the read/write immeadiately for updates concern but it feels like I am going against the concept of a NoSQL and in essence I am building a relational DB.

Thanks

Answer 1

Locking and latching. That's what needs to happen if partial updates become possible. It's a difficult engineering problem to keep a <15ms write latency SLA with locking.

This seems problematic if the documents are large which they inevitably would be if all your data is nested.

Define your fear — burnt Request Units, app host memory, ingress/egress network traffic? You believe this is a problem but you're not stating concrete results. I'm not saying you're wrong or doubting the efficiency of the partial update approach, i'm just saying the argument is thin.

Usually you want to JOIN nothing in NoSQL, so i'm totally with you on the last paragraph.

Answer 2

Whenever you are trying to create a document try to consider this:

• Does the part of document need separate access . If yes then create a referenced document and if no then create a embedded document.

  And if you want to know what to choose, i think you should need to take a look at this question its for MongoDb but will help you Embedded vs Referenced Document