MongoDB 2.6 发布——Kelly Stirman 访谈

阅读数:2962 2014 年 4 月 14 日

话题:语言 & 开发架构AI

对于 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 等等)。该设置会降低需要移动文档的几率,并使空间可以更高效地重用,结果是更少的空间过度分配和更可预测的性能。用户仍然可以使用精确匹配的分配策略,如果文档大小不增加,该策略更节省空间。

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

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

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

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

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

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

在企业中,MongoDB用得越来越多。在企业采用方面,MongoDBNoSQL生态系统中是如何定位的,以及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