空元素应该存储在 Cosmos DB 中还是应该被忽略？

Question

是否有充分的理由序列化 Cosmos DB 文档中的 null 元素，还是忽略它们更好？

使用 is_defined 函数，我可以像查询空元素一样查询未定义的元素。

是否消耗更少的 RU？在我的测试中，它们的表现似乎相似。

Answer 1

如果您的查询确实依赖于基于可选属性的存在或值进行过滤，那么请严格执行以下操作：检查是否存在（或不存在），或者检查可选属性是否为特定值你正在寻找。

存储空属性是 Cosmos DB 等文档数据库的反模式。这不是必需的，如果您决定这样做，则每次添加新属性时都必须向现有文档添加新的 null 属性（可能成本很高，因为您必须在每个文件上执行 ReplaceDocument()现有文档，每次添加可以为空的新属性时）。当您决定删除可选属性并清除所有无关的空值时也是如此。

Cosmos DB 并不要求每个文档都相同，并且通过以与关系存储相同的方式处理数据（您确实必须处理表列中有空值）。试想一个购物网站，有数千种产品类型，每种类型都有不同的属性（书籍、CD、割草机、咖啡......）。您最终会得到每个文档的数千个空属性（这似乎是一个非常难以管理的场景，更不用说您最终可能会超过每个文档的大小限制）。

此外，每次写入都会产生额外的 RU，因为每个文档都需要更新每个索引。

Answer 2

不发送没有值的键将为您节省一些字节（因此 RU/s）的空间，否则查询中没有任何重要的性能差异。

如果您的键中有非常稀疏的值，这可能很重要。例如，假设每个文档可能有 100 万个密钥中的 1 个，假设每个密钥约为 7 个字节。好吧，如果您将所有 100 万个键都包含在内，但只有一个键为空值，那么您将不走运，因为仅在键中您就有 7MB，而您的文档只能是 2MB。

它可以大规模添加单个文档。如果每 100 万个文档读取中的一个 7 字节键为空（更常见）而不是未定义，则理论上读取它们将花费 7000 RU/s。假设您整个月都在执行 100 万个 RPS（但这只会是您成本的 0.8%，因此其他优化（例如使用正确的索引/等）会变得更大差异）。