MongoDB 2.6 发布——Kelly Stirman 访谈

对于 NoSQL 用户而言， MongoDB 无需介绍了。MongoDB 产品营销总监 Kelly Stirman 就最新的 2.6 稳定版回答了有关问题。最后，除其它更新外，我们还获得了关于集合级锁的进一步信息，它是MongoDB jira 跟踪系统中受关注程度最高、得票最多的特性请求。

在 MongoDB中，当更新迫使引擎在BSON存储中移动文档时，存储碎片可以导致意外的延迟。您能给我们解释一下，2.6版本是如何帮助缓解这一问题的吗？

如果有足够的空间，在 MongoDB 中更新文档时，数据会在原地更新。如果更新后的文档大小大于已经分配的空间，那么文档会在一个新位置被重写。MongoDB 最终会重用原来的空间，但这可能需要时间，而且空间可能会过度分配。

在 MongoDB 2.6 中，默认的空间分配策略将是 powerOf2Sizes，这个选项从 MongoDB 2.2 开始就已经提供了。该设置会将 MongoDB 分配的空间大小向上取整为 2 的幂（比如，2、4、6、8、16、32、64 等等）。该设置会降低需要移动文档的几率，并使空间可以更高效地重用，结果是更少的空间过度分配和更可预测的性能。用户仍然可以使用精确匹配的分配策略，如果文档大小不增加，该策略更节省空间。

对于基于SQL和NoSQL的数据库，索引数据都能够提供很大的帮助，但有时候在扩展写性能时又可能是件麻烦事。您能给我们解释一下，2.6版本的“索引交叉（index intersection）”如何减少需要的索引数目吗？

作为例子，考虑一个销售报告应用程序：产品经理想要找出所有定购特定部件号超过给定数量的客户。使用索引交叉，可以组合（交叉）部件号和数量的现有索引来优化查询，而不需要单独的复合索引。这还会使工作集大小开销减少，更新更高效。

目前，索引交叉支持两个索引的交叉，而且在候选结果集大致相等时使用最好，对于那些能够从“覆盖索引（covered indexes）”处理的查询尤其如此。在预先知道多字段谓词的情况下，使用复合索引处理查询更快。

对于某些在单个索引上的操作，索引交叉也能提高它们的性能，可以将此称为“自交叉（self-intersections）”。在使用诸如 in 或 all 这样的操作符时，MongoDB 2.6 可能会多次扫描索引，然后取结果的交集。这能显著减少处理查询时必须返回的完整文档的数目。

“孤立文档（Orphaned documents）”会使某些查询产生不正确的结果。您能详细说明一下2.6版本是如何帮助我们解决这个问题的吗？

在正常情况下，系统中不会有孤立文档。不过，块迁移过程中的一些失败情况可能会留下孤立文档。孤立文档的存在会使某些查询产生不正确的结果。而孤立文档可以安全删除，在 2.6 之前的版本中，没有简单的方法来这样做。在 MongoDB 2.6 中，我们实现了一个新的用于数据库分片集群的管理命令：cleanupOrphaned（）。该命令会在数据的单个范围内从分片中删除孤立文档。关于这个话题，我们的一位支持工程师写了一篇不错的博文。

在企业中，MongoDB用得越来越多。在企业采用方面，MongoDB在NoSQL生态系统中是如何定位的，以及2.6版本改进了哪些关键特性？

MongoDB 在许多组织中广泛使用，包括 30 个财富 100 强的组织。我们看到，组织希望标准化几个数据库系统，而许多组织选择 MongoDB 是因为它可以用于各种各样的应用程序，这归功于它灵活的数据模型、丰富的索引、扩展性以及它大大提升了开发团队的生产力。

MongoDB 2.6 提供了许多安全增强，这对于企业而言非常关键。这些特性包括 LDAP、x.509 和 Kerberos 身份验证、SSL 加密、用户定义角色、审计和字段级安全。IBM Guardium 也提供了与 MongoDB 的集成，这提供了更广泛的审计能力。

跟企业相关的另一个重要的趋势是我们的生态系统规模，它现在已经包含了超过 400 个合作伙伴。在这些合作伙伴中，有许多都提供了与 MongoDB 的集成，包括 Informatica、Microstrategy、QlikTech、Pentaho、Talend 等，其他还有许多。

全文搜索一直是一个有大量请求的**特性，尽管 2.4版本已经有了一个试验性的实现，而且恰恰是由Eliot自己提交的，但在2.6版本中才增加了 $text 操作符。2.6版本的全文搜索有多成熟，以及它是如何面对NoSQL**数据库领域的竞争的？

在过去一年里，我们与社区紧密合作，测试文本搜索，并将其能力集成到其它特性中。告别测试版，MongoDB 2.6 的文本搜索现在可用于生产环境，而且还提供了新特性，包括：

与 MongoDB 的查询引擎集成，所以文本搜索可以与一般查询操作符结合使用，通过限制、跳过、排序和过滤结果的能力提供更丰富的查询。例如，用户可以在一个博文集合中搜索特定的短语，但使用一个额外的条件将搜索限制在过去七天的博文中；支持多语言文档；文本搜索语句可以用在“聚合框架（Aggregation Framework）”中，通过对匹配的文本进行计数和分组提供更深入地分析。

其他 NoSQL 供应商提供与单独的专用搜索引擎的集成，如 SOLR 和 Elastic Search。这种方式增加了部署的复杂性和成本，需要额外的技能，而且这些索引与底层的数据不一致。我们认为，原生的文本搜索更容易部署，成本更低，而且可以充分利用现有技能，同时保持与底层数据的一致性。不过，专用搜索引擎提供的某些特性，MongoDB 并没有提供，但我们也像其他 NoSQL 供应商一样，提供了类似的与这些产品集成的选项。使用 MongoDB，用户可以从这两种方式中选择一种使用。

更细粒度的锁可能是请求最多的特性。与数据库级相比，你们更进一步的路线图是什么？与**集合级锁 **相比，更进一步的主要障碍是什么？

重要的是要记住，MongoDB 中的锁与 RDBMS 中的“闩（latch）”非常接近——它们非常简单，通常持有 10 微秒或者更少。MongoDB 2.2 引入了更高级的锁让步算法，显著减少了我们在社区中看到的与锁争用相关的问题的数量。不过，我们认识到，还有机会改进并发性，其中包括更细粒度的锁。

MongoDB 2.8__ 将具备文档级锁。我们认为，与集合级锁相比，这会更显著地改进更广泛应用程序的并发性。但是，更细粒度的锁只是改进并发性的一部分，我们将改进数据库的其它方面，以便在整体上提供更大的并发。MongoDB 2.6 已经包含了部分改进（参见下文），MongoDB 2.8 将带来更多。

MongoDB 2.6**** 有助于解决其它锁问题吗？

是的，许多增强都有助于改进并发性。例如，索引交叉减少了许多应用程序所需索引的数量，提高了写可扩展性。许多我们过去在锁内做的工作如今在锁外执行，如解析和 _id 生成。我们已经做了大量工作来改进操作日志写并发，既包括使每次写更快，也包括更改锁的工作机制。这项工作改进了 2.6 版本的并发性，在更细粒度的锁可用之前，这是必须的，否则这些东西将很快成为下一个瓶颈。

查看英文原文：**** MongoDB 2.6 Release - An Interview With Kelly Stirman