ehwizard说查看了相关的演讲，并没有发觉有所说的问题，但愿可以或许供给更多细节。
ehwizard暗示不晓得他所谓的环节线程是什么，但愿可以或许多供给一些相关细节。
下面绿色部门是原文作者对MongoDB的一些和质疑，红色部门为NoSQLFan的无聊演绎，其余为10genCTOehwizard的回应。
6.MongoDB未经呈现过一次问题，导致所无数据被删除了。这个环境发生在MongoDB1.6版本的replicasets布局中，因为选举策略呈现问题，导致选择了一个空数据节点作为新的primary，如许导致那些无数据的节点都把本人的数据给删除了，我们700G的数据就如许没了。还好在1.8版本中修复了这个问题。
而在我看来，10gen眼中可能就在意第5个，而第一点估量在他们眼中连前三都进不了。
这一点上ehwizard也认可这确实是MongoDB持久被诟病的问题，可是目前在2.0版本中曾经做了相当大的改良。曾经对写操作需要涉及到磁盘IO的环境下进行了优化。而在2.2版本中，这一优化还会进一步推进。（哥们，针对collection的lock啥时候来啊）
1.MongoDB为了在benchmark上都雅一些，不吝将不平安的方案作为其默认设置装备摆设。（就差大叫无良市侩了）
3.MongoDB在进行写操作时利用了一个全局的写锁，如许效率很低
当然，话说回来，MongoDB的实现策略的实现，本身是可控的。好比你能够选择写操作的平安级别，在你利用了replicasets的时候，你完万能够设定一个写操作同步到必然机械数量后才前往成功。（对作者一大嘴巴子，您这是真不懂呢仍是装不懂呢）
2.MongoDB丢数据现象严峻，而且导致的环境良多
感受该当是负载过高了，跟我之前说的一样，同步默认是异步的，若是你但愿确认同步成功，能够通过getLastError号令设置w参数为2。
1.不要丢数据，对数据必然要很是小心2.多做测试，靠得住性3.做到真正的多节点扩展性4.除低延迟5.提高对资本的请求机能
【编纂保举】
ehwizard注释说，若是系统确实曾经达到极限，这时候再去做chunk块的挪动确实不容易。关于这个话题他本人曾经在良多场所说过，他的是尽早监测到集群曾经快到极限了，不要比及系统曾经到了100%负载的时候再去做添加节点的操作。（对本人的营业增加上点心，别跟4sq一样火烧眉毛了才发觉）
8.在负载比力高的机械上，同步工作相当废柴
ehwizard暗示我们并没有什么白金合同，所有的问题都是通过公开的jira系统来反馈的。从问题的提出和点窜，都是在jira上公示的，（比尼玛官员的财富还通明）。若是你不克不及供给更多的消息，这个真的不好再会商。我们凡是的做法是在修复了问题后会尽快的通知到响应的用户。
4.大压力比力大的时候，MongoDB的auto-sharding功能会呈现问题，在大负载下，添加一个sharding结点绝对是场恶梦。由于这时候MongoDB只需去做chunk的挪动，就会影响本身办事，要么就只能不做挪动。
尼玛坑爹ehwizard注释说，这是一般的环境，对于单机利用MongoDB来说，不利用journaling日记本身就是不保举的做法，在2.0版本后，journaling日记曾经是默认了。而若是是在replicasets等多机的环境下，你底子不需要进行数据恢复，只需要从另一个同步节点resync数据就能够了。
ehwizard说这确实有可能发生，可能两头确实犯错了，只是犯错消息并没有前往给客户端而未。由于复制操作本身是异步进行的，若是你但愿数据同步复制完后才前往，你能够通过getLastError号令将w参数设定为2。
看到这个，ehwizard同窗不认同了（这是从层面上质疑啊），他暗示10gen毫不是像作者说的那样，他说你能够看一下我们bug修复的列表，这些都是公开的，我们从来没有说悄悄的改掉某个bug了事，或者说只跟一些特殊用户申明这些bug。若是我们真的那么在意读写机能，我们早就修复了那些华侈CPU的问题了。若是我们真的那么在意benchmark的话，我们早就优化了全局锁的问题了，这工具对多线程的benchmark成果是有很是大的改良的。更况且一般的benchmark都是多线程跑的，我们并不那么在意benchmark的数据。（我的benchmark曾经很牛X的好不好）
MongoDB确实还很新，还有良多问题。若是你想来跟我们会商一些MongoDB相关的问题，我们的的办公室为你敞开，我们会以很是的立场看待你提出的问题，所以若是真的有问题，我们很是等候与你的沟通。
5.mongos很是不靠得住，虽然mongod/configserver/mongos连系的架构看起来很美，可是mongos确实很不给力。当压力稍大一点，mongos就经常解体，少则几天解体一次，多则几小时就解体一次。有时候会呈现抛出断言然后杀掉某个环节线程，可是这时候历程竟然还仍然运转，所以重启办理历程也不是每次都管用。
7.10gen的人发布了一些还不克不及发布的工具。据我们所知，在一些stable版本中竟然会有一些导致数据问题的bug，而凡是我们在逢到这些bug的时候才会发觉。我们采办了10gen的白金级办事，可是获得的成果只是一些被他们称为内部RC版本的热补丁，而我们需要将这些补[载]用仍是不消MongoDB？悲催用户炮轰10gen CTO丁打在我们线上版本上。天哪！
2.4主从复制具有不明缘由的中缀现实，没有任何错误就间接中缀了
在MongoDB正被炒得火热的今天，相信如许一篇文章也实在向一些同窗浇了一头冷水。所以NoSQLFan将二者PK概念都放在这里，大师能够本人看一看，以至做做尝试，在利用NoSQL或者是其它新手艺前，也都多领会一些可能呈现的问题。
最新动静：这篇文章的作者曾经认可文章只是他的一个恶作剧，他称只是想做个尝试，以显示节制一个人的思维是何等容易。可是他提到的案例并非完全没有呈现过，如许一篇恶作剧的文章，虽然实在唬了我们一把，可是可以或许让一些盲目标朋朋更隆重一些。仍是有益处的。
前几天在HackNew上呈现了一篇文章，题目很彪悍，叫《Don’tuseMongoDB》，其内容也是间接表达了对MongoDB的不满，作者列举了MongoDB利用过程中逢到的各种问题。以至上升到对其开辟团队的质疑，暗示他们可能只关怀benchmark的数据，不关怀用户数据的平安性。真是大叫坑爹啊！
2.2在不利用journaling的时候，若是MongoDB解体，数据无法恢复
而的问题可能曾经有一些修复了，可是我想说的是，作为一个公司，仍是该当将办事的靠得住性放在第一位。我认为10gen该当按下面的优先级来进行MongoDB的功能开辟：
ehwizard说，哥们你这个说法有点过份了，MongoDB的默认方案的选择，和benchmark底子就一点关系都没有，并且不只是默认方案，包罗API的设想，以及MongoDB其它的一些功能选择，都和benchmark没有半毛钱关系。当然，默认设置装备摆设的设定仍是需要和用户次要的利用场景相关，MongoDB在利用上确实曾经履历了良多变化，对这些变化做出响应的默认策略调零，确实也有可能。
对此ehwizard的回应是，对于丢数据的问题，我们收到过bug演讲，可是我们对MongoDB很是领会，所有的bug在收到后，几乎都在第一时间进行了修复。若是你可以或许给出你丢数据时的利用场景，我们会尽可能找出缘由。ehwizard暗示，若是你真的发生了丢数据的问题，请顿时联系10gen的工程师进行bug修复。（哥们，有问题，找组织，不丢人）
2.1MongoDB经常诡异的丢掉数据
2.3主从复制有问题，具有丢掉数据的操作，主从之间没有同步校验。而且虽然数据丢了，可是在形态上显示仍是同步一般的
ehwizard暗示这种环境该当不会发生，若是确实发生了，该当是严峻bug。
但很快地，10genCTOehwizard就看到了这篇文章，并顿时对作者提到的各个问题进行了回应。ehwizard暗示，他翻遍了1600个用户案例演讲，并没有发觉呈现了文章作者所说这些问题的案例（现实上也是对的实在性进行了思疑。你是哪个单元的？）。随后ehwizard又敌对的暗示，若是你在利用MongoDB中逢到问题，能够随时到MongoDB的GoogleGroup或者MongoDB响应的IRC中进行演讲。