【问题标题】:Selecting partition key when message does not have right property to diversify documents当消息不具有使文档多样化的正确属性时选择分区键
【发布时间】:2020-04-02 14:17:37
【问题描述】:

我有一个应用程序通过从另一个应用程序数据库读取消息将消息发布到 Cosmos DB。我可以从其他应用程序获得的唯一信息是 documentId,即来自应用程序数据库的主键和消息正文。结构如下:

{
   "id":<documentid>,
   "body":<body picked up from App>,
   "Timestamp":<today's date time>
}

正文包含简单的文本消息,例如“Hello World!今天是星期三”。我有以下要求: 1.需要通过documentId查询文档。 2. 需要查询两个日期/时间戳之间的文档。

  • DocumentId 是唯一的,不允许有重复值。

在这种情况下,我们如何识别容器的分区键,以便通过上面指定的两个标准轻松检索文档?

非常感谢任何意见。

【问题讨论】:

  • 这是一个读取繁重还是写入繁重的应用程序?
  • 嗨,Savran,写入量(约 2000 万条消息/天)和读取量(将被查询并发送到感兴趣的客户队列)

标签: azure-cosmosdb azure-cosmosdb-sqlapi data-partitioning


【解决方案1】:

对于通过 id 进行查询:如果您知道 id,则可以直接读取(相对于查询)。这需要知道 id 和分区键;如果这是您的主要检索方法,您可以将分区键设置为 /id,这将成为最直接的方法(而且成本最低,RU 方面)。

对于时间戳之间的查询:您需要重新考虑分区,因为如果使用 /id 作为分区键,您最终会执行跨分区查询。这部分确实没有“正确”的答案,因为我们对您的应用程序和查询模式(或交易率、大小等方面的数据量)知之甚少。只要知道,如果您对数据进行分区,理想情况下您会希望将查询限制在单个逻辑分区内;否则你需要执行跨分区查询,这将花费更多的 RU。

【讨论】:

  • Makagon,很抱歉没有提供完整的信息。将写入 cosmos db 的数据是某些应用程序生成的指标信息。每条指标消息都有以下字段: - MetricId,将用作文档 ID - 日期时间戳 - 详细消息 - 来源(所有消息的值相同,因为它由单个应用程序生成) 预期量为每天约 2000 万条日志消息.需要通过 MetricId 查询消息的能力,两个日期时间戳之间的消息。我正在为该场景寻找更好的分区键。
【解决方案2】:

如果我是你,我会将时间戳的一部分作为字符串取出,并将其用作分区键。 例如,如果时间戳是“4/15/2020 1:20 PM” 创建一个值为“2020 年 4 月 15 日”的新属性 并使该新属性成为分区键。 这将确保您在每个分区中有 2000 万条消息。 通过 id 选择数据不会有任何问题 如果您需要按日期搜索,您将知道分区键是什么,因为它取决于时间戳。 我能看到的唯一问题是,如果您需要检索日期范围内的数据,您需要点击多个分区。 查看我关于合成分区键的帖子。 https://h-savran.blogspot.com/2019/08/synthetic-partition-keys-in-azure.html 希望对您有所帮助!

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-04-03
    • 1970-01-01
    • 2020-11-03
    • 1970-01-01
    • 2023-02-21
    • 1970-01-01
    相关资源
    最近更新 更多