MongoDb Architecture

jieforest

译者另附一图加深理解：

jieforest

1. #创建一个partition key
   
2. db.runcommand({shardcollection: "testdb.person",
   
3.     key: {firstname:1, lastname:1}
   
4. })

复制代码

jieforest

在分片的设计中，客户端lib连接一个无状态的路由server（mongos）， mongos的行为跟mongod类似。mongos作为一个路由server，在根据客户端请求的特征重定向到相应的分片server时起到异常重要的作用。

jieforest

对于包含partition key的插入、删除、更新请求，根据partition key找到包含这个key的chunk，根据chunk和shard的对应关系，mongos（也就是路由server，下面统一称mongos）将此请求路由到相应shard的主库上。其中shard和chunk的对应关系维护在一个config server上，当然每个server本地也会保留一个备份（并且当config发生变化，本地备份会去config server上拉取最新的配置）。partition key和chunk是m:1的关系，也就是说partition key对应唯一的一个chunk，一个chunk包含很多partition key。chunk和库也是m：1的关系。从而可以唯一确定这个chunk所在的库。

对于查询请求来说，mongos会先考察partition key是selection criteria（译者注：实在不知道该怎么翻译这个东西）的一部分，mongos会把这种请求只定向到相应的shard上，由该shard上的主库或者从库服务。否则，mongos会先分发请求到各个shard上，在各个shard上分别完成查询，各个shard的计算结果将会汇总到mognos，最后返回给client。当请求需要对结果排序，并且排序的字段是partition key， mongos将会顺序的请求各个shard，client分别拿到结果就行了。如果排序的字段不是partition key，mongos将会把请求分发到各个shard上执行局部排序，然后mongos在局部排序结果的基础上进行再次合并排序。

当数据插入到chunk时，如果chunk负载已经接近满负荷，我们需要分割chunk。mongs根据请求这个chunk的请求数量，对比其他shard上chunk的请求数量统计，来发现这种需要分割chunk的情况。接下来mongos会向存储这个chunk的shard主库发送分割chunk命令。这个shard的主机将会执行分割chunk，同时将这个分割点汇报给配置服务器。这里可以看到，到目前为止，chunk分割并没有发生shard之间的数据移动，所有的数据还都在原来的shard上。

jieforest

另外，还有一种均衡机制（运行在某个mongos上），这种机制的作用是保证每个shard上有差不多相同数量的chunk。当不均衡状态被监控到时，均衡器会向繁忙的shard发送移动chunk的命令。chunk转移将会在online进行。原始shard会联系目的方shard来初始化数据传输，接着就会进行从原始shard到目的shard数据复制。这个过程可能会持续一段时间，时间取决于数据量的大小。数据复制的时候可能会出现数据还在更新的情况，这些更新的数据会存在原始shard上，并且会被原始shard跟踪记录下来，当复制结束时，这些更新会同步到目的shard。经过多轮迭代，chunk迁移将进入最后阶段:原始shard停止对该chunk 的请求的服务。经过最后一轮更新同步，目的shard将会更新配置服务器，同时通知原始shard返回StaleConfigException给mongos，mongos从配置服务器上读取最新的配置信息，重新发送原来发给原始shard的请求。在未来的某个时间点，原始shard上的这些已经成功迁移的chunk将会物理性的永久删掉。

这里也存在高频度更新的情况。chunk数据从原始shard到目的shard 复制的时候发生了大量更新操作到原始shard，并且数据更新的速度快于数据复制的速度。这种情况下，对于这个chunk的迁移将会退出。然后， mongos会接着处理其它需要迁移的chunk。

jieforest

Map/Reduce 的执行

mongodb提供了一套map/reduce框架来提供并行数据处理。mongodb map/reduce的概念跟hadoop类似。只有下面一些略微的区别：

1. mongodb 输入数据来自collection而不是hdfs目录

2. mongodb 输出可以追加到一个已经存在的collection中，而不是hdfs目录

jieforest

mongodb的map/reduce工作流程大概如下：

1. 客户端定义map函数，reduce函数，输入数据的查询条件，输出数据的目的collection

2. 客户端向mongos发送请求

3. mongos定向这个请求到相应的shard（发送到单个shard还是多个shard根据查询条件中是否包括partition key）。这里要注意的是mongos会从从各个shard中选取一个server来服务，现在的版本基本都是选择主库。

4. 每个shard的主库会执行查询命令，然后将结果通过管道的形式发送给客户端定义的map函数，map函数会返回一串串键值对放到内存buffer中。当buffer满后，客户端定义的reduce函数将会执行，它会将buffer中的键值对进行归类，最后把结果存到本地collection中。注意这里reduce的只是buffer中的数据并不是最终结果。

jieforest

5. 当第4步结束后，reduce函数将会在上次reduce的结果上再次reduce，合并出这个shard最终结果。

6. 当第5步执行结束后，mongos会通知相关用来存储结果collection 的shard servers（如果输出collection不是存储在多个shard上，就只通知一个就好了，如果是多个就通知多个）。

7. 存储结果collection
shard的主库将会分别请求各个shard的前面步骤reduce的结果。当然，它只会请求它要保存的key区间。

8. 主库用从各个shard上请求的初步reduce结果再次运行reduce函数。接着本地存储这些最终结果。如果用户还定义了finalize函数，接下来就会运行。

jieforest

下面有一个简单的示例。该示例用来根据文档话题进行倒排。

1. db.book.insert({title:"NOSQL",
   
2.              about:["software", "db"]})
   
3. db.book.insert({title:"Java programming",
   
4.              about:["software", "program"]})
   
5. db.book.insert({title:"Mongo",
   
6.              about:["db", "technology"]})
   
7. db.book.insert({title:"Oracle",
   
8.              about:["db", "software"]})
   
9. db.book.find()
   
10. m = function() {
    
11. for (var i in this.about) {
    
12.      emit(this.about[i], this.title)
    
13. }
    
14. }
    
15. r = function(k, vals) {
    
16. return({topic:k, title:vals})
    
17. }
    
18. db.book.mapReduce(m, r, {query:{},
    
19.                out:{replace:"mroutput"}})
    
20. db.mroutput.find()

复制代码

jieforest

总得来说，我发现mongodb是一个非常强大，同事非常易用的数据库。我非常期待运用mongobd+node。js。将会我会继续分享这方面的经验。

最后，非常感谢jared rosoff想我提供这么多mongodb实现细节。

原文地址：http://horicky.blogspot.com/2012/04/mongodb-architecture.html