Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: What is the reason behind the compositite ID key #16

Closed
paulvanbladel opened this issue Nov 28, 2020 · 5 comments
Closed

Question: What is the reason behind the compositite ID key #16

paulvanbladel opened this issue Nov 28, 2020 · 5 comments

Comments

@paulvanbladel
Copy link

Congratulations with this repo. Very useful and insightful. Thanks a lot.
Just one question for my understanding and learning, if you don't mind.
I Noticed that the ID field is a composition of the partition key and a Guid.
I would think the Guid with be sufficient?
Just trying to understand.
Thanks in advance
paul.

@ShawnShiSS
Copy link
Owner

ShawnShiSS commented Nov 28, 2020

Hi Paul,

Thank you for you kind note!

In SQL world, you read a record by its id in most cases when the id is the primary key. In Cosmos DB, you read an item by its id and also its partition key value. If you look at the .NET SDK documentation, two params are required in the container method signature:

ToDoActivity toDoActivity = await this.container.ReadItemAsync<ToDoActivity>("id", new PartitionKey("partitionKey"));

In our application, the ID field is a composition in order to make a get item by ID request a point-read request, which is faster and cheaper. Particularly, in the IRepository.cs class:
Task<T> GetItemAsync(string id);

Instead of having two params in the signature, id and partition key, we use a composition so that it can be resolved into two params. The first part is the partition key value, and the second part (guid) is a unique identifier.

Another interesting relevant topic is data modelling and partition key design. In this demo case, Category is used as the partition key so that items within the same category is stored in the same container, allowing you to quickly retrieve all todo items in a category, e.g., grocery, as a single-partition read. You can certainly just use id as the partition key as well, which gives you a higher cardinality, but the trade off is that you when you need to list all todo items under grocery category, it becomes a cross-partition read.

Your question does motivate me to write a quick article to explain this sector in more details. I hope update the project readme.md file with an article link soon.

Hope you find this helpful!

Many thanks,
Shawn

@paulvanbladel
Copy link
Author

hi Shawn,
Thanks a lot for your prompt reply and detailed explanation.
warm regards
paul

@ShawnShiSS
Copy link
Owner

@paulvanbladel you are very welcome! Take care!

@ShawnShiSS
Copy link
Owner

For anyone who has similar questions or are just curious in partition key design best practices when working with Cosmos DB, I am in the process of writing a short article discussing my personal thoughts. Will post in the project page soon.

Cheers!

@ShawnShiSS ShawnShiSS pinned this issue Nov 29, 2020
@ShawnShiSS
Copy link
Owner

For anyone who is interested, I have written a short article sharing my personal thoughts on this topic. Please feel free to provide any feedback. Thanks!

Partitioning Best Practice in Partitioned Repository Pattern with Cosmos DB

Promise delivered, @paulvanbladel!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants