如果我只想在Azure Cosmos Containers中索引（默认）“id”，如何定义我的索引策略？如果我执行以下操作，id是否会作为索引被删除？或者它是否不会索引除默认id之外的任何内容？我尝试查看文档，但找不到任何明确的信息。
indexing_policy { indexing_mode = "consistent" excluded_path { path = "/*" } }
pgvzfuti1#
是，/id始终被索引如果索引模式设置为一致，则系统属性id和_ts将自动索引。来源所以，是的，你的索引政策应该给予你你正在寻找的。
/id
9lowa7mx2#
你是否也按/id分区，并使用容器作为键值存储？如果是这样，那么你可以完全关闭索引，因为你不需要（或不想）使用查询来执行单个文档操作。使用id和partition key值传递到这些操作的点操作根本不需要用户定义索引。
id
partition key
更新：
关于你的设计的其他注解，使用/id作为分区键，但然后进行范围查询deviceId &一个unix时间戳。在物联网场景中（这听起来像是）使用/id作为分区键，并带有随机GUID（听起来也像是你正在做的）不会扩展。此外，实际上你要在数据中执行查询，这需要你定义一个索引。我的答案只适用于你从不运行查询，只使用点CRUD操作的情况。您可能面临的挑战是，当您的容器最初增长超过10 K RU/s或50 GB存储空间时，您的容器将进行分区拆分并在两者之间重新分配数据。随着这种情况继续下去，更多的物理分区被添加并在它们之间分配数据，您的查询将变得越来越慢，成本也越来越高。这种设计基本上不会扩展，这基本上与使用这种类型的数据库的原因相反（无限扩展和低延迟）物联网解决方案的一个更典型的设计看起来像这样。1.按/deviceId分区的摄取容器。此容器是发生大量摄取的容器。仅追加，并为容器定义TTL，以防止任何逻辑分区增长超过20 GB。注意：你必须保持索引打开才能使用TTL。2所以保持索引打开并使用下面的索引策略。1.接下来是第二个 * 或更多 * 容器，每个容器都是为特定的查询而设计的（物化视图模式）。这些将被分区和索引的最佳优化的查询，他们在服务。我不能说具体分区键将是什么，但你应该设计它，这样查询可以回答作为一个分区内查询，这意味着你的查询应该在where子句中包含一个相等表达式c.deviceId == @deviceIdValue。根据查询的不同，应该在一个或多个属性上定义索引，并使用可选的复合索引，其中你在其他属性上有范围表达式和/或order by。（PS：不能跨分区键进行范围过滤）。1.最后一种是在Azure Function或任何计算中使用Change Feed和host来侦听第一个容器上的插入，然后将每个项目写入为服务查询而创建的一个或多个容器中。鉴于大多数这些解决方案都关闭TTL数据以保持存储效率，通常用户会利用这个机会将其写入blob存储以进行冷存储。需要注意的是，您需要测量以了解是否需要任何辅助容器。如果您的工作负载非常小，那么您不需要这样做。但是随着它的增长，这些模式旨在帮助可扩展性。
c.deviceId == @deviceIdValue
使用TTL的最小索引策略示例
{“indexingMode”：“一致”、“自动”：true，“includedPaths”：[ ]，“排除的路径”：[ {“path”：“/*”} ] }
2条答案
按热度按时间pgvzfuti1#
是，
/id始终被索引如果索引模式设置为一致，则系统属性id和_ts将自动索引。
来源
所以，是的，你的索引政策应该给予你你正在寻找的。
9lowa7mx2#
你是否也按/id分区，并使用容器作为键值存储？
如果是这样，那么你可以完全关闭索引，因为你不需要（或不想）使用查询来执行单个文档操作。使用
id和partition key值传递到这些操作的点操作根本不需要用户定义索引。更新：
关于你的设计的其他注解，使用/id作为分区键，但然后进行范围查询deviceId &一个unix时间戳。
在物联网场景中（这听起来像是）使用/id作为分区键，并带有随机GUID（听起来也像是你正在做的）不会扩展。此外，实际上你要在数据中执行查询，这需要你定义一个索引。我的答案只适用于你从不运行查询，只使用点CRUD操作的情况。
您可能面临的挑战是，当您的容器最初增长超过10 K RU/s或50 GB存储空间时，您的容器将进行分区拆分并在两者之间重新分配数据。随着这种情况继续下去，更多的物理分区被添加并在它们之间分配数据，您的查询将变得越来越慢，成本也越来越高。这种设计基本上不会扩展，这基本上与使用这种类型的数据库的原因相反（无限扩展和低延迟）
物联网解决方案的一个更典型的设计看起来像这样。
1.按/deviceId分区的摄取容器。此容器是发生大量摄取的容器。仅追加，并为容器定义TTL，以防止任何逻辑分区增长超过20 GB。注意：你必须保持索引打开才能使用TTL。2所以保持索引打开并使用下面的索引策略。
1.接下来是第二个 * 或更多 * 容器，每个容器都是为特定的查询而设计的（物化视图模式）。这些将被分区和索引的最佳优化的查询，他们在服务。我不能说具体分区键将是什么，但你应该设计它，这样查询可以回答作为一个分区内查询，这意味着你的查询应该在where子句中包含一个相等表达式
c.deviceId == @deviceIdValue。根据查询的不同，应该在一个或多个属性上定义索引，并使用可选的复合索引，其中你在其他属性上有范围表达式和/或order by。（PS：不能跨分区键进行范围过滤）。1.最后一种是在Azure Function或任何计算中使用Change Feed和host来侦听第一个容器上的插入，然后将每个项目写入为服务查询而创建的一个或多个容器中。鉴于大多数这些解决方案都关闭TTL数据以保持存储效率，通常用户会利用这个机会将其写入blob存储以进行冷存储。
需要注意的是，您需要测量以了解是否需要任何辅助容器。如果您的工作负载非常小，那么您不需要这样做。但是随着它的增长，这些模式旨在帮助可扩展性。
使用TTL的最小索引策略示例
{“indexingMode”：“一致”、“自动”：true，“includedPaths”：[ ]，“排除的路径”：[ {“path”：“/*”} ] }