MongoDB2.6发布—KellyStirman访谈

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

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

　　对于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 interp）”如何减少需要的索引数目吗？

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

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

对于某些在单个索引上的操作，索引交叉也能提高它们的性能，可以将此称为“自交叉（self-interps）”。在使用诸如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供应商一样，提供了类&＃20284;的与这些产品集成的选项。使用MongoDB，用户可以从这两种方式中选择一种使用。

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

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

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

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

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