当前位置:首页 > 开发 > 数据库 > 正文

如何对10亿数据量级的mongoDB作高效的全表扫描

发表于: 2014-10-29   作者:quentinXXZ   来源:转载   浏览:
摘要:   本文链接:  http://quentinXXZ.iteye.com/blog/2149440 一、正常情况下,不应该有这种需求 首先,大家应该有个概念,标题中的这个问题,在大多情况下是一个伪命题,不应该被提出来。要知道,对于一般较大数据量的数据库,全表查询,这种操作一般情况下是不应该出现的,在做正常查询的时候,如果是范围查询,你至少应该要加上limit。 说一下,

 

本文链接: http://quentinXXZ.iteye.com/blog/2149440

一、正常情况下,不应该有这种需求

首先,大家应该有个概念,标题中的这个问题,在大多情况下是一个伪命题,不应该被提出来。要知道,对于一般较大数据量的数据库,全表查询,这种操作一般情况下是不应该出现的,在做正常查询的时候,如果是范围查询,你至少应该要加上limit

说一下,我的应用场景:用于全量建立搜索引擎的索引。这就是一种需要用到全表扫描的非一般情况。对于全表扫描的结果,我们没有排序要求。

 

二、情况说明

既然有如此大的数据量,那存储所占空间基本都是上T的了。所以肯定是使用了mongodb集群,而且配置了分片的分布式环境。

公司的服务器,性能比较好,应该是24核,96g内存的。所以读者们使用不同机器,测出来的用时,跟我这的结果可能不一定相符。

 

三、第一种方法,利用chunk信息作划分。

    原理:我们知道,在分片环境下,mongodb使用chunk块来组织数据。同一个chunk块的数据肯定存在于同一个分片上。假设,我们以 _id”作分片时所用的片键。Mongodb为了保证范围查找的效率,一定会将一定范围内的_id值的document方在同一个chunk中。而且通过mongodb自身提供的方法,我们可以很方便的获取,每一个chunk的中maxKeyminKey[minKey,maxKey) 这个范围内的数据肯定在同一个chunk内,也并定在同一个分片中。

做法:1、先获取所有chunk信息,得到他们的maxKeyminKey

2、多线程执行,将这些chunk信息,分发给这些执行线程。

3、各线程,根据当前的chunk maxKeyminKey信息,做范围查找。

4、最后将结果汇总。

     这样做的好处在于:

1、每次对一个chunk做的范围查找,肯定是只在一个分片(意味着同一块硬盘)中进行的,不会分散到多个分片。这样很高效。

2、可以方便的利用多线程,提高效率。

     这种方法我没试过,公司的前辈尝试过,据说,最终用时3小时以内。是最为理想的效果。

 

四、改用散列片键后的全表扫描方法

用上面的方法,有一个前题,就是分片策略采用的是mongodb默认的升序片键的方法。这样才保证,升序的_id,会按排序范围分布在chunk块中。这样这策略,存在一个明显的问题,就是会造成所以新增的doucument的写入肯定都会命中到具有当前最大_idchunk上。造成写入的分发的不平衡。

前文中,说过,全表扫描,应该是一个正常情况下不被允许的情况。所以数据库策略的制定也不应该以考虑全表扫描的效率为优先,当前情况下,就应以写入效为优先考虑。公司正在使用的片键策略,是片键策略散列片键(hashed shard key,这样的话,写入请况会被很好地分发到多个分片上,但是不利用进行范围查找。上面用的全表扫描方法就没法再用了。

做法:1、获得全局的最大id maxID与全局的最小id minID

      2、设置一个stepSize ,比如5000。将[minID,maxID]5000为一个chunk(我们定义的一个逻辑chunk)作切分,那么第一个块范围[minID,minID+5000,

 3、各线程,根据分配到的chunk块的maxIDminID信息,做范围查找。

4、最后将结果汇总。

这样做法的问题:

               1、对一个chunk进行查询,会命中多个分片进行查询,查询效率大幅降低。

               2、 如果_id分布稀疏,查询变得更快。因为以5000stepSize, 其中可能有不少_id是不存在的。测试同学帮我搭线下测试数据时,2000w条数据,由于计算错误,_id的范围分布剧然从10亿起,到130亿止。导致的线程几乎一起在空跑chunk。所以_id分布稀疏的情况下,这种查询方式完全不适用。

               3、 _id分布不均。可能某个chunk中几乎5000个满载,有些chunk只有很少几个_id有效。那么就会导致计算资源分布不均。

     最后的结果不理想,我一开始,由于涉及一些联表join操作,用时16多个小时。后来各种调整,加线程,去掉一些操作,差不多仍需10小时。

 

五、改用散列片键后的较高效全表扫描方法

上面的那种方法,当然是不理想的。光查数据就需要16个小时,加上后续处理,肯定更久,这样我们的搜索引擎索引建立,就不可能当前完成了。但一直苦于没有更好的方法。

最终这个问题,还是被我的头解决了。 先说一下,最终效果吧。20w/秒,约3小时完成。

其实,最终的方法很简单,但必须放弃多线程(多cursor),至多一个分片一个线程。

做法:使用单线程扫描,不加适合可能影响排序的条件。

 

这样做的目的是使用mongodb中的自然排序。扫描时,必然是依次命中某一个分片读取,不会带来磁盘震荡问题。

如何对10亿数据量级的mongoDB作高效的全表扫描

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
何谓全表扫? 不合理地消耗大量资源的数据访问方式 为啥会有全表扫? 原因大致如下: ① 缺乏索引
1、MYSQL中LIMIT用法_百度知道 limit是mysql的语法select * from table limit m,n 其中m是指记录开
我们知道现在Facebook的用户数量,已经突破了10亿大关。因此Facebook在发展期间,所实现的技术成就
转自:http://sd.csdn.net/a/20111205/308512.html 导读:天下武功,唯快不破。对日益激烈的互联网
导读:天下武功,唯快不破。对日益激烈的互联网竞争你所拥有的利器就是快!本文来自百度贴吧的LAMP
导读:天下武功,唯快不破。对日益激烈的互联网竞争你所拥有的利器就是快!本文来自百度贴吧的LAMP
在某些情况下,如果明知道查询结果只有一个,SQL语句中使用LIMIT 1会提高查询效率。 例如下面的用户
SESSION 1执行 SQL> update test1 set id=1000; SESSION 2 : select * from test1 如果表上面有
在某些情况下,如果明知道查询结果只有一个,SQL语句中使用LIMIT 1会提高查询效率。 例如下面的用户
转载自:http://blog.sae.sina.com.cn/archives/1131 在MySQL Connect 2013大会上,我描述了在 Faceb
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号