MongoDB的应用应用

作者：佚名 2015-07-20 16:47:22数据库 其他数据库 MongoDB 最近，因为工作的应用原因，我们正在使用MongoDB做一些大数据量存储的应用尝试。对于MongoDB的应用复制功能部署问题，有一些无奈！应用

 　　最近，应用因为工作的应用原因，我们正在使用MongoDB做一些大数据量存储的应用尝试。对于MongoDB的应用复制功能部署问题，有一些无奈!

　　首先说明一下我们的应用情况，我们需要使用的应用项目情况，对于MongoDB的应用期望，MongoDB的应用无奈和解决方案。

　　我们的应用站点是一个7×24h提供服务的电子商务网站。海量数据存储，应用高并发，实时是我们***的特点，也是我们的需要解决的难点。我们目前的业务量一直在增长，所以从架构角度出发，可伸缩性，可替代性是我们追求目标。

　　目前需要使用到MongoDB的项目有3个：

　　一个是应用信息中心(AIC)，该项目是作用是监控线上项目出现异常的情况，该项目的特点在于瞬间并发无法估计，数据量恐怖，读写遵循“二八原则”，稳定性要求高，实时性一般;

　　另一个是业务日志系统(BLS)，该项目主要用来存放站点业务操作的日志，目前的做法是将日志存放在DB中，我们认为这不是***的解决方案，所以我们准备把该部分日志移植到MongoDB环境中。该项目的特点是数据增量大，每天增量大概有7g左右，数据无法删除，高并发，稳定性，实时性要求高，99%写，1%读取;

　　***一个是搜索用户行为分析系统(UBA)，该项目主要是记录一些我们需要分析的用户使用搜索行为的日志，该项目的特点是数据量大，并发要求高，稳定性，实时性要求一般，但是要求读写尽量分开。三个方案都要考虑成本的问题，否则硬件的投入将是***的软肋。

　　仔细了解MongoDB后，先说一下能满足我们需求的点。

　　***：可以存放海量数据;

　　第二：能承受高并发;

　　第三：可以使用廉价存储;

　　第四：单服务器稳定性可以满足要求;

　　不能满足我们的点：

　　***：net的客户端除了完成了协议外，别的实在够差劲，

　　第二：MongoDB的集群功能实在无语。如果选择pair模式，对于slave只能等待master down机，不能读;选择M-M-S模式，不能保证实时性，只能保证***一致性，并且可能存在数据重叠问题;选择M-S模式，slave倒是可以读了，但是当master down机时无法自动切换到slave。实在很无语!

　　解决办法：

　　***：net客户端比较容易解决，自己开发一个就基本上没问题;

　　第二：对于AIC，我们选择存储使用M-M-S模式，我们保证海量数据的存储和并发性，实时性在这个系统中并不是重点，稳定性要去也一般，所以选择M-M-S应该问题不大;对于BLS，稳定性是我们的***要求，并发，海量，快速是我们的第二需求，所以我们选择了pair模式，宁愿浪费一点硬件设备，也要保证稳定性;UBA系统我们选用M-S模式，原因是保证高并发，海量存储的基础上，我们还要保证读写分离，***的原因就是slave需要对BI提供原始数据源。

　　对于MongoDB的应用，目前我们只使用了那么多，从测试的情况看，应该问题不大。***的问题就是在于复制的功能上，如果pair模式能支持slave可读，那可将无敌了。看过源码后，也没觉得在pair上加入读的功能对于MongoDB会有多大的影响啊!也可能在设计的时候有不得已的苦衷吧?不知道MongoDB的架构师怎么想的?!

　　原文链接：http://www.cnblogs.com/seapeak/archive/2010/06/28/1767091.html

责任编辑：honglu 来源： NOSQL中文网 MongoDB

(责任编辑：百科)