有一个30亿量级数据的库，如何全量爬取并分析？
因为量级过大无法一次性爬取至本地再分析，考虑使用limit().skip()混合的方法，一次读取1万条数据进行分析存储，30亿数据分成30万份后再合并分析生成最后的结果。代码如下：
// i为跳跃条数，比如取第一个1万条时i为0，第二个1万条时i为1
db.getCollection("whois").find({}).limit(10000).skip(i*10000)
30个进程并发计算，一个进程负责1万份的量级。简单测试了下读取速度，非常快，几乎一秒读取数据，剩下的就是cpu本地计算的事儿了，预计8个小时完成，锁屏，下班。第二天来一看，发现了很奇怪的现象。
1.一天过去，数据只跑了2亿条左右。
2.大部分进程阻塞或者死掉。
3.前几个进程爬取的数据远远多于后面的进程，比如第一个进程的一万份数据基本上爬取完毕，第二个进程爬取了大半，第三个进程及以后非常的少甚至没有数据。
出现以上现象的原因：
skip不适用于大数据的查询搜索，数据量小的时候还可以，效率高，但是一但数据量达到一个层级（mongoDB本身提供的几十mb的内存限制）后，查询的算法会更改。比如查询limi(10000).skip(0)，即前一万条数据，很快查询并返回，因为经历了很少的分页查询，但是一但你使用limit(10000).skip(1000000000)，那么你会惊喜的发现查几天都出不来结果甚至直接查询失败。反复的查询数据提取到内存，一条条的数，看是否达到你想要条数，如果没有则继续提取剩余数据继续数，直到查询到想要的条数。在这里索引没有起到任何作用。官方有这么一句话：MongoDB会根据查询，来加载文档的索引和元数据到内存里，并且建议文档元数据的大小始终要保持小于机器内存，否则性能会下降。除此之外，基于以上现象，本人也强烈建议skip的数据量也小于分配内存。
如何解决？
那么应该如何爬取这样的全量数据来分析呢？这样的量级首先并不是特别大，只是想在本地简单分析，使用spark、scala来做会显得很大很不合适。所以将上面语句改写一下，既能达到本机跑效果，又能不被服务器的IO速度限制。我们可以利用索引，最好是全局唯一性的（即无相同值的）索引来进行边排序边查找。比如我选用_id这个字段，首先规定排序方式为升序，然后依次读取一万条数据，获得最后一条数据的_id字段值 Q ，那么读取下一个一万条数据时，我就可以利用索引查到 Q 后面的一万条数据。那么如此以来，无论你读取的数据量多靠后，都能利用索引的优势快速定位并返回，而不是从头开始一条一条数过去。
//key为上一次查询的最后一条记录的_id值
col_name.find({"_id": {"$gt": ObjectId(key)}}).sort("_id", 1).limit(10000)
但是你会发现这样的查询完全依赖上一次查询的值，这对多线程多进程并发并不友好。
可以从以下几点进行优化：
1.再开一个线程或者进程，采用倒序的方式进行查找计算，只不过查询条件变为$lt，按照全量数据的一半的量为两个进程分配查询的次数。但这样也仅能将速度提高一倍。
2.如果原始数据是一个集群，那么可以分布式计算，比如数据分为了八个区，那么不同区数据采用正序倒序来分别进行爬取（总共16个线程或进程）。
3.稍微简单：升序或者降序后通过skip或者模拟预爬取，获得全量数据不同位置的_id值，这样就手动将数据进行了分桶，然后再根据分桶情况来进行正序倒序爬取。（但是有可能skip值过大时无法计算）