Some nosql cosmosdb advice required - azure-cosmosdb

Question

I am looking for some advice in designing an application using NoSQL CosmosDB or relevant technology.
The data structure looks like the following currently:
{
"accounts": [{
"name": "name1",
"type": "type1"
},
{
"name": "name2",
"type": "type2"
}
],
"categories": [{
"master": "mastername",
"child": [
"child1name",
"child2name"
]
},
{
"master": "mastername2",
"child": [
"child3name",
"child4name"
]
}
],
"charts": {
},
"grouping": [{
"2018": [{
"06": {
"property1": "value1",
"property2":"value2"
},
"07": {
"property1": "value2",
"property2":"value2",
"property3":"value3"
}
}]
}],
"ItemsList": [{
"id": "2018051720",
"dateMonth": "201807",
"property1": "value2",
"date": "17/07/2018",
"Description": "description2"
},
{
"id": "2018051720",
"datemonth": "201807",
"property1": "value1",
"date": "17/07/2018",
"Description": "description"
}
],
"id": "7b786960c93cc9a8"
}
Currently I have decided to have the one collection, because of budget concerns and inside that, will have a multiple of the data structure you see above, so like a list of it.
My question is, is this a good design, the reason for asking is that the following elements can grow quite substantially over time.
ItemList and Grouping.
Itemlist will grow every month by users adding to it, and Grouping will be for every year and month, once a month, but updated as ItemList items are added. Categories and accounts could also change but irregularly.
If I have this in one collection, I was thinking maybe I somehow, have the following structure:
// Main Object
{
"accounts": [{
"name": "name1",
"type": "type1"
},
{
"name": "name2",
"type": "type2"
}
],
"categories": [{
"master": "mastername",
"child": [
"child1name",
"child2name"
]
},
{
"master": "mastername2",
"child": [
"child3name",
"child4name"
]
}
],
"charts": {
},
"id": "7b786960c93cc9a8"
}
// Groupings list
{
"grouping": [{
"userid": "7b786960c93cc9a8",
"grouping": {
"2018": [{
"06": {
"property1": "value1",
"property2": "value2"
},
"07": {
"property1": "value2",
"property2": "value2",
"property3": "value3"
}
}]
}
},
{
"userid": "sfkjehffkjwhf34343",
"grouping": {
"2018": [{
"04": {
"property1": "value1",
"property2": "value2"
},
"05": {
"property1": "value2",
"property2": "value2",
"property3": "value3"
},
"06": {
"property1": "value2",
"property2": "value2",
"property3": "value3"
}
}]
}
}
]
}
// Item List List
{
"ItemLists": [{
"userid": "7b786960c93cc9a8",
"itemlist": [{
"id": "2018051720",
"dateMonth": "201807",
"property1": "value2",
"date": "17/07/2018",
"Description": "description2"
},
{
"id": "2018051720",
"datemonth": "201807",
"property1": "value1",
"date": "17/07/2018",
"Description": "description"
}
]
},
{
"userid": "sfkjehffkjwhf34343",
"itemlist": [{
"id": "2018051720",
"dateMonth": "201807",
"property1": "value2",
"date": "17/07/2018",
"Description": "description2"
},
{
"id": "2018051720",
"datemonth": "201807",
"property1": "value1",
"date": "17/07/2018",
"Description": "description"
}
]
}
]
}
As you can see, I will basically have the main object list with it growing like normal, and then the other json objects for itemlist and grouping where it can grow indepentdantly from the main object, but it would require Two Reads then or even three RU's for the website. Working on only having 400 RU's a month basically, its not a lot of user base and objects?
What is the best way to do this while thinking about money, because if money was no problem, I would have prob gone with a collection for each, where the main object just references the other collection by Id or something.
Hope it makes a bit of sense, in my head it does :)

Answer 1

Imho you're making the age-old mistake of worrying about optimization before a problem arises. Also your sentence "Working on only having 400 RU's a month" somehow makes me feel like you should read up more on the topic of RU's
Check here for Information about RU's and tools to estimate your throughput
400 RU's which cap's your collections "throughput" might slow down your end-user's experience (there might be other bottle necks - usually their on-premise internet connection)
You can always watch the usage of your collections in the Azure Portal and upscale within minutes - so you cannot go wrong by starting with 400RUs
Every request not made is the biggest possible boost to performance
Request in CosmosDB are already bloated with headers for security - you will not have notable performance boosts for shaving a few bytes off your objects here and there, but local caching (be it on your webserver or on the user's machine) will, and it's very easy to do if you simply store the whole Json Objects as key-value pairs (basically what CosmosDB does).
What would be wrong in my opinion is considering multiple collections. I think you have misunderstood the concept there a little. One collection per customer/project is usually the way to go, so don't worry. Everything is indexed and uniquely ID'ed internally so separating things is no problem. One collection per "object type" makes the advantage of any NoSQL Database moot.
If you worry about your "internal lists" getting too long, just save them separately and only save their id in the original object. Then you load them on-demand in your application. Generally speaking more small objects are better than few large objects - if you are able to load them cleverly in your application.
So instead of this:
{
"userid": "sfkjehffkjwhf34343",
"grouping": {
"2018": [{
"04": {
"property1": "value1",
"property2": "value2"
},
"05": {
"property1": "value2",
"property2": "value2",
"property3": "value3"
},
"06": {
"property1": "value2",
"property2": "value2",
"property3": "value3"
}
}]
}
}
you could do this instead
{
"userid": "sfkjehffkjwhf34343",
"grouping": {
"2018": ["x1","x2","x3"]
}
}
{
"groupingid": "x1",
"month":"04",
"values": {
"property1": "value1",
"property2": "value2"
}
}
{
"groupingid": "x2",
"month":"05",
"values": {
"property1": "value1",
"property3": "value3",
"property2": "value2"
}
}
{
"groupingid": "x3",
"month":"06",
"values": {
"property1": "value1",
"property2": "value2"
}
}
Load them only if needed, cache them according to their internal id (which changes on every update if you leave it out) and you won't believe how performant this can be.
You should read up on stored procedures also, they are a really powerful and in some cases a true gold mine for performance improvements.
There is a lot of good Information from Microsoft out there, though admittedly it's not easy to find sometimes.
CosmosDB is frankly an incredible powerful tool if used correctly, but I encourage you to read up on it a little more you you can use it effectively, performance- and cost-wise.