mongodb中的一些坑

mongodb中的一些坑

当你的代码写得多了，你总会出现这样或者那样的错误，有时候代码突然可以用，有时候代码又突然懵逼，有时你只是离开一会，它自动好了……就像女孩是能的心思，总是让人捉摸不透，总是那么魔幻。

今天来跟你说说，最近在mongodb数据处理过程中踩到的一些坑.

1. 对单个document大小的限制

• 当单个文档内容超过16MB时，数据库写入TM会报错。(话说小于16MB的搜索得快，具体没试过~)

• 单个文档超过16MB的，官方建议使用gridFs以文件的形式存储。

2. mongo shell cursor 超时

   最近在使用mongo shell 执行数据处理时，发现在db.collection.find().forEach()时，出现getMore command failed: {"ok" : 0,"errmsg" : "Cursor not found ... 的骚错误。原本每天执行跑批处理的数据，每天执行到一半就异常终止了，导致一个多月的数据缺失。寻思半天后，去查看了官方文档，发现了这样的一句话(If a session is idle for longer than 30 minutes, the MongoDB server marks that session as expired and may close it at any time)，大概意思就是如果会话时间超过30分钟，mongo 服务会自动过期并关闭连接。看了这，似乎知道了问题出在哪了。以前系统数据量少，在30分钟之内一般都能执行完成，执行起来不会出错，由于现在业务增长，数据量不断累积大的问题，才会出现超时问题。
   快刀斩乱麻…… 两种解决的方式，
   一、分步处理，每一步db.collection.find().forEach()中，对于多次大量计算的，将其拆分出来，多次处理，多次执行db.collection.find().forEach()，每次只处理一种业务，也可以调用mapReduce计算出来的结果。
   二、设置 db.collection.find().noCursorTimeout() 不超时或者 maxTimeMS,但需要在处理完成后，需要关闭长链接！！(暂时还没研究怎么使用...).实际中操作中也不可能无限等待……
   两种缺点比较：第一种随着长时间的业务数据量不断增多，还是会出现同样的问题，并且数据链路拉长，会有一部分数据延迟。第二种连接时间太长，数据处理时间长，导致数据不完整、缺失。当忘记关闭连接时，服务器资源消耗大。

3. 

4. mapReduce计算的坑

   示例：计算企业绑定代发账户数
   var map = function () {
       emit(this.entId, 1);
   };
   
   var reduce = function (key, values) {
       return Array.sum(values);
   };
   
   db.scEntAccountInfo.mapReduce(map, reduce, {
       out: 'entAccountCount_reduce',
       query: {'accountStatus': 1}
   });
   
   坑：
   1.当values是一个片段时,会直接返回，不进入reduce!!!
   2.只计算满足query条件的结果，将结果输出到out所在的collection中,不满足query条件的，out所在的collection中不会存在该id对应的任何信息。