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

Burgomaster

An excellent question. It looks as though the community are also asking it: feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/… The implication here is that the 'small document / infer relationships' pattern is the way to go, for now. Would be lovely to see a white paper or similar on how small a 'small document' is. – Perni

Note that the limit in Cosmos DB for documents is 2 MB, so you are forced to use relatively small files. – Lananna

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.

Two

Thanks for the response. It's not really an argument, more of a concern. I guess all the fears you have defined are valid, I was just looking for advice from someone experienced with Cosmos DB at scale. Someone who can say "yes, you have to read the entire document, iterate through the list in the nested property, update a single flag on an item within that list and write the entire document back". If that is the "correct" way or the recommended way to handle updates with Cosmos DB then I'm happy with that. – Burgomaster

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

Extensity

Answer 3

Embed or Reference is the most common problem I face while designing document structure in NoSQL world.

In embedded relationship, child entities has been embedded into the parent document. In Reference relationship, child entities in separate documents and their parent in another document, basically having two (or more) types of documents.

There is no one relationship pattern fits all. The approach you should take depends on the Retrieve and Update to be done on the data is being designed.

1.Do you need to retrieve all the child entities along with the parent entities? If Yes, use embedded relationships.

2.Do your use case allow entities being retrieved individually? This case use relationship pattern.

Majority of the use cases I have worked, I used relationship pattern. For example: Social Graph (Profiles with Relationship Tree), Proximity Points (GeoJSON based proximity search), Classified Listing etc.

Relationship Pattern is also easier to update and maintain, as the entities are stored in individual documents.

Carreno

Answer 4

Partial Updates are now supported by Cosmos DB:

Azure Cosmos DB Partial Document Update feature (also known as Patch API) provides a convenient way to modify a document in a container. Currently, to update a document the client needs to read it, execute Optimistic Concurrency Control checks (if necessary), update the document locally and then send it over the wire as a whole document Replace API call.

Partial document update feature improves this experience significantly. The client can only send the modified properties/fields in a document without doing a full document replace operation

Read more here: https://learn.microsoft.com/en-us/azure/cosmos-db/partial-document-update

Lewanna