azure - 如果数据量非常低(总记录数 < 50k)，如何在 Azure Cosmos 中选择分区键

Question

关闭。这个问题需要多问 focused 。目前不接受答案。

---

想要改进此问题吗？更新问题，使其仅关注一个问题 editing this post .

已关闭 3 年前。

Improve this question

我已阅读了 Microsoft 网站和互联网上提供的所有文档，但其中大多数都谈论大数据，但我的要求很小。

我正在尝试保存客户入职数据。在客户加入之前，我们为其分配公司 ID 和用户 ID 以及管理员角色和默认环境。该公司可以创建多个虚拟环境进行测试。例如。 Dev1、Stage 和 Test123 等，并且 Onboarding 将在环境级别完成。

载入 JSON

{
    "companyId": "Company123",
    "environment": "stg1",
    "userId": "User123",
    "startDate": 1212121212,
    "modifiedDate": 1212121212,
    "uniqueId": "<companyId_UserId>"
}

入职可以在环境级别完成。根据数据，一家公司最多可以拥有 10 到 15 个环境。在上面的文档中，用户 ID 只是元数据，用于检查哪个用户开始在环境 stg1 上加入。

最初我想到使用公司 ID 作为分区键，但在这种情况下每个逻辑分区最多有 15 条记录。

我的 Cosmos 查询将包含公司 ID 和环境 ID 作为过滤器。

这是一个好方法吗？或者我应该使用哈希函数生成合成分区键并将逻辑分区限制为 10 或 20。

哪个更快？

• 大量逻辑分区，但所有分区都包含 10 到 15 个文档
• 逻辑分区数量较少，但分区包含的文档数量较多。

我的完整数据大小约为 < 1 GB，因此请不要假设我们会达到此处的“逻辑分区限制 10 GB”的限制。

我的其他查询是

• 使用 Azure SDK 在插入新文档的情况下，我的 RU 是 7.67，但在更新插入的情况下，它是 10.9。有什么办法可以减少这种情况吗？

Answer 1

如果您的集合永远不会超过 20GB，那么用作分区键的内容并不那么重要，因为您的所有数据(和查询)都将驻留在单个物理分区上。分区键(和分区)都与规模有关(这就是为什么我们总是在大量数据或大量操作的背景下谈论它们)。

在读取繁重的工作负载中，选择在所有查询 where 子句中使用的分区键是一种安全的策略，在您的情况下，environmentId-companyId 的合成键是一个不错的选择。如果这是一个写入繁重的工作负载，那么您还希望分区键值跨分区分布写入。但同样，如果这是一个小集合，那么这在这里就无关紧要了。

您的 id 属性很好，因为它可以具有相同的companyId-userId 值和不同的分区键值，这就是我假设您想要的。如果您拥有全部三个，您还可以使用 environmentId、companyId 和 userId 进行点读取，您应该尽可能多地执行这些操作而不是查询当寻找单个项目时。即使这个集合不会增长，根据你所说的，这里的分区策略应该允许它在你想要的时候扩展。

更新插入总是比插入更昂贵，因为它是两项操作而不是一项操作。降低写入成本的唯一方法是创建自定义索引策略并排除您从不查询的路径。但根据您帖子中的示例文档，自定义索引策略不会给您带来任何改进。

希望这对您有所帮助。