Azure cosmosdb 优化搜索的Cosmos DB数据建模

我在Cosmos DB中观看了数据建模

在视频中，有人解释说，如果可以对数据进行建模，使最常见的查询位于分区查询中，则可以最小化RU，从而使成本最小化，性能最大化

视频中使用的示例是一个博客系统。他们表明，通过移动内容，使博客帖子和评论作为单独的实体存储在同一个集合中，所有内容都由

blogId

分区，他们可以实现公共查询的低RU

然后他们发现，由特定用户搜索所有博客文章，作为一种跨分区查询，成本非常高。因此，他们随后复制所有博客文章数据，并将每个博客文章作为单独的实体添加到用户集合中，该集合已由

userId

分区。用户搜索帖子现在很便宜。理由是存储比CPU时间便宜得多，所以这是一件很好的事情

我的问题是：当我想让更多的东西更高效地搜索时，我是否继续遵循这种模式？例如，我希望能够搜索博客主题（每个博客帖子可能有许多主题）、离散的博客评级，等等

---

我觉得为每个搜索词扩展这种模式是不可持续的。在这些情况下，我是必须接受高RU搜索，还是有一些聪明的方法可以提高效率？

基本上可以归结为知道使用更改提要将数据从一个容器复制到另一个容器的成本是否低于跨分区查询的成本。这需要了解应用程序的访问模式，还需要测量这些查询的平均成本与使用change feed制作另一个副本的成本。Change feed在轮询容器时消耗2 RU/s，然后根据您的索引策略，从源容器中读取的每1Kb或更少的数据消耗1 RU，在目标容器上插入的每1Kb或更少数据消耗~8 RU。乘以插入或更新数据的速率。然后每天或每月计算，以比较成本

---

如果您正在寻找的是对您的数据进行免费文本搜索，那么您可能希望使用Azure搜索。这比使用change feed的方法更简单，但Azure Search也可能非常昂贵。

我感到惊讶的是，启用多属性高效搜索的唯一方法（保持在cosmos db内）是将数据复制到多个集合，每个集合由不同的感兴趣的属性分区。也许我只需要放下我的RDBMS思维，但这是一颗难以下咽的药丸。@ChechyLevas-你不会复制所有数据-只是你查询所需的最小数据。RDBMS并不会使这个问题消失，因为您仍然需要设计表和外键来优化查询（以及连接；通常您会发现基于RDBMS的建模具有类似的非规范化功能来优化特定的查询模式，在进入仓库建模时更是如此）。您将在Azure表存储中发现相同的建模技术。