MongoDB的设计思想很适用于非事务型的Web系统，初始MongoDB的时候，我觉得这就是我想要的数据库系统，它比MySQL要轻量级，提供简单的查询，支持索引，高效的插入数据，更好的支持分布式，更方便的支持Master/Slave，这些都是MySQL没有的优点。但作为一个新兴事物，是否要应用到生产环境中，需要谨慎决策。查询了一些资料，得知MongoDB已有一些在正式环境下的上亿级数据管理的应用，同时看到一篇文章《Do not use mongoDB》，然后作者证实这篇文章是恶作剧，于是我相信MongoDB至少是稳定的产品，于是运用到自己的生产环境中。
于是，问题就来了。
1：MongoDB占用的空间巨大无比。
我用MongoDB Dump整个数据库，输出的bson文件共1.1个G，但这个数据库在MongoDB的Data目录下竟然占用了30G的空间。
2：真的会丢数据
某日，我的服务器在没有任何问题的情况下，MongoDB突然就不能读取和写入了，所有的查询都返回Transport endpoint is not connected. 很莫名。于是，我用正常的方式重启MongoDB（不是kill进程），之前的错误没有了，但明显发现查询失败率提高了，更要命的是，有一部分数据丢失了，数据库好像回到几天前一样。于是我用--repair命令尝试修复数据库，更离奇的事情发生了，30G的物理文件，修复完成以后变成7G了，这下MongoDB的所有数据都查询不出来了。幸好我在repair前留了个心眼，备份了30G的文件，又dump了bson文件，不然真要哭死了。
后来我查了资料，发现MongoDB有Lazy Write的机制。但是我认为即使有这个机制，也不应该在正常操作的情况下丢失数据，而且这个机制是针对意外关闭的情况，但我的服务器又没有突然重启，又没有kill操作，就不应该随便丢数据。之后的--repair为什么会丢数据就不知道了，我也无意去研究，因为我感觉MongoDB太不成熟了，可靠性方面和MySQL没得比。于是我写了程序，将MongoDB的数据导入MySQL，然后将网站的数据库层改成基于MySQL的...MongoDB太坑爹了。
3：查询不够稳定
MongoDB查询的时候，有时会查询莫名出错。这个概率不大，但相对于MySQL，就大多了。
虽然《Do not use mongoDB》的作者证实是恶作剧，但是我觉得作者是真的遇到了类似的问题，才会恼火写这篇文章的。这些问题是客观存在的，至少我遇到了。我也很恼火。
经过实践，我建议目前数据库还是用MySQL。分布式还是用程序实现比较稳当。MySQL也支持Master Slave，另外，MyISAM引擎的插入效率也不低，虽然没法和MongoDB的速度比，但为了这点速度的提升而牺牲了可靠性，就相当不值得了。MongoDB有着很好的设计思想，但是目前稳定性和可靠性都不够，等到MongoDB再成熟一些，再考虑使用吧。
Ferris