速度、CouchDB 视图和替代方案答案

【问题标题】：Speed, CouchDB views and alternatives速度、CouchDB 视图和替代方案
【发布时间】：2010-08-12 21:59:12
【问题描述】：

我有大型数据集，我想查询。查询不会更改，但基础数据会更改。根据我阅读的内容，我可以构建一个“视图”并对其进行查询。另外，我读到 Couch DB 知道如何在数据更改时更新视图，所以我认为再次查询视图仍然很快。

我的问题是，我是否正确理解 CounchDB 的观点？我不需要 CouchDB 的任何其他功能，我什至不需要 SQL，我想要的只是对更改数据进行快速相同的查询。我可以用别的东西吗？如果我会使用，比如说，好的旧 MySQL，它真的会比 CouchDB 慢（阅读：在上述场景中，各种 DB 将如何大致执行？）。

【问题讨论】：

标签： database performance couchdb

【解决方案1】：

您的评估完全正确。尽情享受吧！

唯一值得一提的性能技巧是，如果您 emit() 从视图中获取所需的所有数据并且从不使用 ?include_docs 功能，您可能会看到性能提升，因为 include_docs 会导致 CouchDB 返回到主数据库并检索导致该视图行的原始文档。换句话说，您可以将所需的一切emit() 放入视图索引中（更多空间但更快），或者您可以使用对原始文档的引用（更少空间但更慢）。

【讨论】：

【解决方案2】：

鉴于您提供的信息，我认为没有人可以回答您的问题。

关系数据库中的索引类似于 CouchDB 视图。在这两种情况下，它们都存储一个预先排序的数据实例，并且数据库使该实例与规范数据保持同步。两种类型的数据库都透明地使用索引/视图来加速索引/视图设计的表单的后续查询。

如果没有索引/视图，查询必须扫描整个n 数据记录集合，并在O(n) 时间执行。当查询受益于索引/视图时，它会在O(log n) 时间执行。

但这是非常广泛的关于数据量的性能曲线。在某些情况下，给定的数据库可能具有如此快速的性能，以至于无论如何它都胜过另一个产品。很难一概而论，品牌 X 总是比品牌 Y 快。确定特定案例的唯一方法是在两个数据库中尝试该案例并衡量性能。

【讨论】：

我知道索引是预先排序的（即 O(log N)），但我认为视图会自动填充新更新的数据，因此根本不会搜索。换句话说，我认为视图与索引有很大不同，性能如何......顺便说一句，你说我提供的信息不足，你能更具体一点吗？比如数据量？我还认为查询保持不变和数据更改比其他任何事情都更重要......
哪个产品的性能最好取决于您的特定查询，以及您定义的索引/视图。这就是我说的信息不足的意思。每个产品都有其优点和缺点，因此只有在了解需要优化哪些查询后才能进行优化。
另外：如果索引包含您在结果中需要的所有列，您可以使用索引来避免搜索。这称为覆盖索引。当然，在许多 RDBMS 品牌中，您一次只能为一个表中的列定义索引，因此它可能不如 CouchDB 视图通用。