嵌套结构如何影响 DocumentDB 查询性能？

Question

这个问题可能会被表述为“扁平化还是不扁平化？”

如果我将嵌套的 JSON 文档存储在 DocumentDB 集合中，那么查询这些嵌套结构的性能是否与将这些嵌套结构作为平面文档单独存储在单独的集合中一样？

有问题的数据将被写入一次并且（很可能）永远不会更新。报告性能位于要求列表的顶部。

一方面，将数据存储在嵌套结构中似乎是利用无模式/无 SQL 技术的“正确”方式。也就是说，我们自然希望在一个地方和上下文中将标题数据与详细数据相关联。但是，一旦我们每分钟写入数千行，同时从 Web 应用程序运行关于该集合的报告，它是否可以扩展并继续执行？

或者，将详细数据展平，将标题数据的相关部分冗余存储在详细信息集合的每一行中会更好吗？作为一名长期的 RDBMS 开发人员/用户，我倾向于不希望冗余存储数据，但我应该放弃这个想法以支持高性能吗？

平面数据结构在 DocumentDB 中的查询效率更高吗？差距有多大？也就是说，我这样做会放弃什么，如果性能是最重要的（但不是唯一的）优先事项，是否值得？

Answer 1

对此没有一个“正确”的答案。

选择是将关系表示为单个嵌入文档（也称为反规范化）还是像在 RDBMS 中那样表示为引用（又称为规范化），很大程度上取决于您的用例/场景。

通常，您需要针对读取繁重的场景进行反规范化，并针对写入繁重的场景进行规范化。

DocumentDB 团队刚刚发布了一份参考文档；我建议阅读一下：http://azure.microsoft.com/en-us/documentation/articles/documentdb-modeling-data/