为什么我们放弃使用MongoDB

【小编碎语】有人会选择，就有人会放弃，它是否是新型数据库的“弄潮儿”呢？我们依旧要继续观望。

公司开始新项目时部分数据服务选择使用MongoDB,而且在同事内部作了MongoDB应用的扫盲介绍，当时貌似Mysql派和MongoDB派相互之间都没有能说服对方，所以MongoDB的使用就一直延续下来。直到几天前，在考虑系统上线发布和运营时，一些问题出现了。

1.MongoDB存储文件会急剧增大，如果使用32位操作系统很容易达到单个文件体积上限。所以对于MongoDB必须使用64位操作系统，而在亚马逊的EC2中只有是large以上类型的instance的CPU才是64位。

2.MongoDB一般都推荐是多点部署，互为镜像，这样保证服务的延续性和数据的安全性。所以如果需要提供稳定的服务，至少需要2台EC2的instance来作MongoDB服务。而实际对于我们大数据量计算操作可能在一天内累计只有大概1小时，其余时间更多只是少量数据查询操作。

综合以上两点，如果继续使用MongoDB,至少需要两台large以上instance，并且是7X24小时运行，感觉是对运算能力的浪费。

再三讨论后我们决定暂时放弃MongoDB, 将这部分的运算改为使用MapReduce 来处理。亚马逊的MapReduce可以充分体现按需使用运算能力的特性，在使用MapReduce完成所有计算需要后，再将需要查询使用的结果数据导入到Mysql数据库中。这样即满足了那1小时内需要的运行能力，又满足了其余时间对计算结果的查询需求。

通过以上的事例，说明在使用云计算平台时，对程序开发技术的选型必须充分考虑到平台能够提供虚拟硬件设备的技术指标。并且需要转变以往的设计思路，更多考虑到云平台方便启动和关闭instance的特性。尽量减少7X24长时间使用相同一台instance作服务的应用，如果这样的服务无法避免时，应该考虑多台冗余，并在程序设计中去除对instance的内网ip地址耦合，当某台instance出现故障而需要更新新的instance时，内网ip 地址变化不会导致程序无法正常运行。

【编辑推荐】

1. Mongodb源码分析--内存文件映射(MMAP)
2. 走进MongoDB的世界 展开MongoDB的学习之旅
3. 浅析Mongodb源码之游标Cursor
4. 野心勃勃的NoSQL新贵 MongoDB应用实战
5. MongoDB与CouchDB全方位对比