首页 > 解决方案 > 需要一些 nosql cosmosdb 建议

问题描述

我正在寻找一些关于使用 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 会随着用户添加而每月增长,Grouping 将针对每年和每月,每月一次,但随着 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"
                 }
             ]
         }
     ]
 }

正如你所看到的,我基本上会让主对象列表正常增长,然后是其他 json 对象,用于 itemlist 和分组,它可以从主对象独立增长,但它需要两次读取,甚至需要三个 RU为网站。基本上每个月只有 400 RU 的工作,它的用户群和对象不是很多吗?

在考虑金钱时最好的方法是什么,因为如果金钱没有问题,我可能会为每个集合使用一个集合,其中主要对象只是通过 Id 或其他东西引用另一个集合。

希望它有一点意义,在我的脑海里是这样的:)

标签: azure-cosmosdbazure-cosmosdb-sqlapi

解决方案


恕我直言,您犯了一个古老的错误,即在问题出现之前担心优化。此外,您的句子“每月仅工作 400 RU”让我觉得您应该阅读更多有关 RU 的主题

在此处查看有关 RU 和工具的信息以估计您的吞吐量

400 RU 哪个上限是您的收藏“吞吐量”可能会减慢最终用户的体验(可能还有其他瓶颈 - 通常是他们的本地互联网连接)

您始终可以在 Azure 门户中查看您的集合的使用情况,并在几分钟内进行升级 - 所以从 400RU 开始就不会出错

每个未提出的请求都是对性能的最大提升

为了安全起见,CosmosDB 中的请求已经被标头臃肿——你不会因为在这里和那里从对象中删除几个字节而获得显着的性能提升,但是本地缓存(无论是在你的网络服务器上还是在用户的机器上)会,而且非常如果您只是将整个 Json 对象存储为键值对(基本上是 CosmosDB 所做的),那么这很容易做到。

我认为有什么问题是考虑多个集合。我认为你误解了那里的概念。每个客户/项目一个集合通常是要走的路,所以不用担心。一切都在内部进行了索引和唯一标识,因此分离事物没有问题。每个“对象类型”一个集合使得任何 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 缓存它们(如果你忽略它,它会在每次更新时更改),你不会相信它的性能如何。

您还应该阅读存储过程,它们非常强大,在某些情况下是提高性能的真正金矿。

那里有很多来自微软的好信息,尽管有时很难找到。

坦率地说,如果使用得当,CosmosDB 是一个令人难以置信的强大工具,但我鼓励您多阅读一下它,您可以有效地使用它,无论是性能还是成本。


推荐阅读