是否有充分的理由在Cosmos DB文档中序列化null元素，还是最好忽略它们？
使用is_defined函数，我可以查询未定义元素，类似于查询空元素的方式。
是否消耗更少的RU？在我的测试中，它们的表现似乎相似。
答案 0 :(得分：1)
不发送没有值的键将为您节省少量的字节空间（从而节省RU / s），否则在查询中没有任何重要的性能差异。
如果键之间的值非常稀疏，这可能很重要。例如，假设您每个文档可以拥有100万个键中的1个，并且假设每个键〜7个字节。好吧，如果您将所有100万个键都包含为空值（除了一个以外），那将很不走运，因为仅在键中，您将拥有7MB的空间，而您的文档只能是2MB。
它可以按比例添加一个文档。如果在100万个文档中的每个文档中，一个7字节的密钥为空（更常见）而不是未定义，则从理论上讲，读取它们的成本为7000 RU / s。假设您整个月都在执行1M RPS，则每月在空值键上花费的费用约为340美元（但这仅占您费用的0.8％，因此其他优化措施（例如使用正确的索引等）会变得更大差异）。
答案 1 :(得分：1)
如果您的查询确实依赖于基于可选属性的存在或值的过滤，则请准确地执行此操作：检查是否存在（或不存在），或检查可选属性是否为特定值您正在寻找。
存储空属性是文档数据库（例如Cosmos DB）的反模式。这不是必需的，并且如果您决定这样做，则每次添加新属性时，都必须向现有文档中添加新的空属性（这可能会很昂贵，因为您必须在其中执行ReplaceDocument()每一个现有文档，每次添加一个可以为null的新属性）。当您决定删除可选属性并清理所有无关的null时，也是一样。
Cosmos DB并不需要每个文档都相同，并且您将以与关系存储相同的方式处理数据（您必须在其中进行处理）而放弃巨大的利益。表列中为空）。想象一下一个购物网站，其中有数千种产品类型，每种类型都有不同的属性（书籍，CD，割草机，咖啡...）。您最终将在每个文档中拥有数千个null属性（这似乎是非常难以管理的情况，更不用说最终可能会超出的每个文档的大小限制）。
此外，由于每次文档的每个索引都需要更新，因此每次写入都会产生额外的RU。