在使用NoSQL CosmosDB或相关技术设计应用程序时,我正在寻求一些建议。
当前的数据结构如下:
{
"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"
}
由于预算方面的考虑,我目前决定拥有一个集合,并且其中一个将包含您在上面看到的多个数据结构,因此就像一个列表一样。
我的问题是,这是一个好的设计吗,问的原因是以下元素会随着时间的推移而显着增长。
ItemList和分组。
Itemlist会随着用户的添加而每月增加,而分组将每年和每月(每月一次)进行,但是会随着ItemList项目的添加而更新。类别和帐户也可能会更改,但不规则。
如果我将其放在一个收藏夹中,则我想也许我会具有以下结构:
// 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"
}
]
}
]
}
如您所见,我将基本上使主对象列表像正常情况一样增长,然后是用于itemlist和分组的其他json对象,它可以独立于主对象而独立增长,但随后需要进行两次读取或该网站甚至三个RU。基本上每个月只有400 RU的工作量,它的用户基础和对象不是很多吗?
在考虑金钱时这样做的最佳方法是什么,因为如果金钱没问题,我将很可能会选择每个集合,其中主要对象只是通过ID或其他对象引用另一个集合。
希望这有点道理,在我看来确实如此:)
答案 0 :(得分:-1)
Imho,您犯了一个古老的错误,即在问题出现之前担心优化。另外,您的句子“每月只有400 RU的工作量”使我觉得您应该阅读有关RU的主题的更多信息
Check here for Information about RU's and tools to estimate your throughput
400 RU会限制您的集合的“吞吐量”,这可能会减慢最终用户的体验(可能还有其他瓶颈-通常是其内部Internet连接)
您始终可以在Azure门户中观看集合的使用情况并在几分钟之内进行升级-因此,从400RU开始就不会出错
每个未提出的请求都是对性能的最大推动力
CosmosDB中的请求已经充斥着安全性标头-您不会在这里和那里将对象削减几个字节而获得显着的性能提升,但是本地缓存(无论是在您的Web服务器上还是在用户计算机上)如果您只是将整个Json对象存储为键值对(基本上是CosmosDB所做的事情),那将非常容易。
我认为会出错的是正在考虑多个馆藏。我认为您对此有点误解了。通常,每个客户/项目一个收集就可以了,所以不用担心。一切都被编入索引,并在内部进行唯一的ID标识,因此将它们分隔开没有问题。每种“对象类型”都有一个集合,这使NoSQL数据库具有了很多优势。
如果您担心自己的“内部列表”过长,只需将它们单独保存,并将其ID仅保存在原始对象中即可。然后,将它们按需加载到应用程序中。一般来说,如果能够在应用程序中聪明地加载它们,则更多的小对象胜于少数几个大对象。
所以代替这个:
{
"userid": "sfkjehffkjwhf34343",
"grouping": {
"2018": [{
"04": {
"property1": "value1",
"property2": "value2"
},
"05": {
"property1": "value2",
"property2": "value2",
"property3": "value3"
},
"06": {
"property1": "value2",
"property2": "value2",
"property3": "value3"
}
}]
}
}
您可以改为这样做
{
"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"
}
}
仅在需要时加载它们,根据它们的内部ID进行缓存(如果不进行更新,每次更新都会更改它们),并且您不会相信这样做的性能如何。
您还应该阅读存储过程,它们是一个功能强大且在某些情况下是提高性能的金矿。
Microsoft提供了很多很好的信息,尽管有时很难找到。
坦白地说,CosmosDB是一个令人难以置信的强大工具,如果正确使用,但我建议您多读一点,以便您可以在性能,成本和成本方面有效地使用它。