MongoDB的应用

***的应用

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

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

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

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

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

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

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

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

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

第二：能承受高并发;

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

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

不能满足我们的点：

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

第二：***的集群功能实在无语。如果选择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提供原始数据源。

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。