MapReduce和online实时访问共存的一种架构——MongoDB

     这两天阅读有关MongoDB的技术文章，也一直在思考一个问题。使用MongoDB的MapReduce在做数据的统计运算时，如何不影响MongoDB提供的实时访问服务。结合HBase的使用经验，谈谈自己的体会。

     这段时间，我一直思考并打算使用MongoDB替换MySQL，存储社区的相关数据，提供实时的数据查询服务。除此之外，MongoDB还支持MapReduce计算模型和GridFS分布式文件系统。那么就问自己：除了让MongoDB提供实时的数据查询服务，能不能同时担当数据的统计、分析工作，这是MapReduce的强项。

     在淘宝做产品搜的项目的时候（hbase），由于其他原因，ops当时临时拼凑了45台服务器，搭建产品搜的离线运算集群。这45台机器和淘宝的主搜索（宝贝搜索）在一个机房内，并且分散在不同交换机下，导致在做运算的时候，挤占了大量带宽，致使主搜索丢弃了大量用户请求。MongoDB同时担当两种角色，服务器的网络拓扑结构就更显得重要。

     假设存在MongoDB里的数据可以有3份拷贝，那么我们可以让两份数据放在一个机柜（机柜A）下面，第三份数据放在另一个机柜（机柜B）下，这样机柜B也有一份完整的数据。master优先选择机柜A的两份数据，机柜A提供实时数据访问服务，机柜B提供MapReduce数据统计、分析服务。这样两边的网络流量就互不影响了。

     这样的架构还有一个好处，就是当一个机柜坏掉的时候，还有另一个机柜有完整的数据。

     这是一个基本模型，多个机柜的情况下，可以按此逻辑扩展。