《mongdb应用场景与解决方案》由会员分享，可在线阅读，更多相关《mongdb应用场景与解决方案（2页珍藏版）》请在金锄头文库上搜索。
1、最近，因为工作的原因，我们正在使用MongoDB做一些大数据量存储的尝试。对于MongoDB的复制功能部署问题，有一些无奈！首先说明一下我们的情况，我们需要使用的项目情况，对于MongoDB的期望，MongoDB的无奈和解决方案。我们的站点是一个724h提供服务的电子商务网站。海量数据存储，高并发，实时是我们最大的特点，也是我们的需要解决的难点。我们目前的业务量一直在增长，所以从架构角度出发，可伸缩性，可替代性是我们追求目标。目前需要使用到MongoDB的项目有3个：一个是应用信息中心（AIC），该项目是作用是监控线上项目出现异常的情况，该项目的特点在于瞬间并发无法估计，数据量恐怖，读写遵循“
2、二八原则”，稳定性要求高，实时性一般；另一个是业务日志系统（BLS），该项目主要用来存放站点业务操作的日志，目前的做法是将日志存放在DB中，我们认为这不是最好的解决方案，所以我们准备把该部分日志移植到MongoDB环境中。该项目的特点是数据增量大，每天增量大概有7g左右，数据无法删除，高并发，稳定性，实时性要求高，99%写，1%读取；最后一个是搜索用户行为分析系统（UBA），该项目主要是记录一些我们需要分析的用户使用搜索行为的日志，该项目的特点是数据量大，并发要求高，稳定性，实时性要求一般，但是要求读写尽量分开。三个方案都要考虑成本的问题，否则硬件的投入将是最大的软肋。仔细了解MongoDB后
3、，先说一下能满足我们需求的点。第一：可以存放海量数据；第二：能承受高并发；第三：可以使用廉价存储；第四：单服务器稳定性可以满足要求；不能满足我们的点：第一：net的客户端除了完成了协议外，别的实在够差劲，第二：MongoDB的集群功能实在无语。如果选择pair模式，对于slave只能等待master down机，不能读；选择M-M-S模式，不能保证实时性，只能保证最后一致性，并且可能存在数据重叠问题；选择M-S模式，slave倒是可以读了，但是当master down机时无法自动切换到slave。实在很无语！解决办法：第一：net客户端比较容易解决，自己开发一个就基本上没问题；第二：对于AIC
4、，我们选择存储使用M-M-S模式，我们保证海量数据的存储和并发性，实时性在这个系统中并不是重点，稳定性要去也一般，所以选择M-M-S应该问题不大；对于BLS，稳定性是我们的第一要求，并发，海量，快速是我们的第二需求，所以我们选择了pair模式，宁愿浪费一点硬件设备，也要保证稳定性；UBA系统我们选用M-S模式，原因是保证高并发，海量存储的基础上，我们还要保证读写分离，最大的原因就是slave需要对BI提供原始数据源。对于MongoDB的应用，目前我们只使用了那么多，从测试的情况看，应该问题不大。最大的问题就是在于复制的功能上，如果pair模式能支持slave可读，那可将无敌了。看过源码后，也没觉得在pair上加入读的功能对于MongoDB会有多大的影响啊！也可能在设计的时候有不得已的苦衷吧？不知道MongoDB的架构师怎么想的？！s / 文档可自由编辑打印
