【问题标题】:Cosmos DB (Mongo DB API) performance of querying across partitions badCosmos DB (Mongo DB API) 跨分区查询性能不佳
【发布时间】:2020-04-23 11:10:26
【问题描述】:

我需要你的帮助来解决跨分区查询的问题,我有一个集合(mongo db api),它存储分区类型为“applicationType”的记录。当我知道我的应用程序类型基本上满足了我 75% 的用户但很少有战略客户希望我们提供基于制造商的数据时,它工作正常,这不是分区的一部分。当我在没有应用程序类型的情况下进行查询时,查询执行得非常糟糕。

需要您的建议来解决这个问题。供您参考,请在下面找到我们存储的集合样本

{
               "_id" : ObjectId("5ad5d6b7529cd2007ba73bc8"),
               "applicationType" : "Highbay",
               "name" : "X",
               "subSeries" : "X1",
               "fullSeriesName" : "C1X", 
               "manufacturer": "cre"
               ...
               ...
               ...

}
,
{
               "_id" : ObjectId("5ad5d6b7529cd2007ba73bc8"),
               "applicationType" : "AreaLight",
               "name" : "X",
               "subSeries" : "X1", (mongo db 
               "fullSeriesName" : "C1X", 
               "manufacturer": "cre"
               ...
               ...
               ...

【问题讨论】:

  • 请编辑您的问题并提供更多详细信息。例如:您认为什么是“差”性能(以及什么是分区内的“好”性能)?是延迟问题吗?是请求单位成本问题吗?您的查询是什么样的?您正在搜索多少数据?您的任何特定于搜索的属性是否已编入索引?对此可能没有任何“正确”的答案,因为数据建模不是一个精确的东西——它是特定于应用程序的。此外,这取决于您特定的读写模式(这就是我在您的问题中提到所有未知数的原因)。

标签: azure-cosmosdb azure-cosmosdb-mongoapi


【解决方案1】:

这是分区数据存储的常见模式。

Mongo 用户的解决方案是使用Change Streams 并使用不同的分区(分片)键将所有数据写入另一个集合,或者预先计算在分区内回答这些查询所需的任何值。

当您执行 coll.watch 和上面链接中概述的其他一些注意事项时,您需要一些计算来托管该过程。

还有一件事是您需要衡量使用更改流的成本与仅执行跨分区查询的成本。一般来说,这种解决方案对于大容量查询更具成本效益。需要注意的事项。

【讨论】:

    【解决方案2】:

    您可以为按“ApplicationType”划分的普通客户和按“制造商”划分的战略客户创建两个不同的集合。

    【讨论】:

      猜你喜欢
      • 2023-02-21
      • 1970-01-01
      • 1970-01-01
      • 2018-12-17
      • 1970-01-01
      • 2022-11-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多