当前位置:Gxlcms > mysql > MongoDB2.6发布—KellyStirman访谈

MongoDB2.6发布—KellyStirman访谈

时间:2021-07-01 10:21:17 帮助过:56人阅读

摘要 : 对于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 interdiv)”如何减少需要的索引数目吗?

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

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

对于某些在单个索引上的操作,索引交叉也能提高它们的性能,可以将此称为“自交叉(self-interdivs)”。在使用诸如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版本的并发性,在更细粒度的锁可用之前,这是必须的,否则这些东西将很快成为下一个瓶颈。

人气教程排行