为什么要用replica Sets
?
?1、数据冗余
?? replica Sets为你存储多份数据备份提供了一个自动算法
? 允许驱动对write concern的控制，这样可以确保多个节点的数据全部write成功以后才给client发送成功的反馈。
? ? ? writeconcern_safe

2、自动故障转移
?? replica Sets中的每一个节点都是对等的，只有一个primary节点
?? 驱动可以感知到replica Sets中的primary的变化
??
? 3、read Scaling 读刻度
?? 默认情况下，primary节点可以读和写
?? 大部分驱动提供slaveOk函数，声明一些操作可以在secondary节点上进行。当使用slaveOk时，可以将read操作分摊到几个节点上。

?

Sharding

?

MongoDB 提供一个自动分片的体系，通过多节点来进行水平扩展。

?

Chunk:

?????? 每个 collection 都是分 chunk 的，一个 chunk 是一个 range ，按照 key 来实现的 range 。

?????? 例如 ,? sharding-key 是 {time : 1} ，某个 chunk 可能是

{time : “2011-01-01”} …… {time : “2011-10-01”}

?????? 每个 chunk 有固定的 size ，默认是 64M ，如果超过这个阀值，那么就分裂。 migrate

?????? 的时候很耗时间，相当不好，只有当 add 一个新的 shard 的时候会发生。

## 以下假设数据有某一属性 TYPE 包括 video 、 channal 、 text 等 ##

Sharding key 的选择，从以下几个方面考虑：

1、? Cardinality 平均分配，确保颗粒性

2、? Write scaling 写入的尺度，比如说，我们将 time 作为 key 的话，那么所有新写入的数据将都指向最新的那个 chunk ，会对这个 shard 造成很大的压力。如果以 {TYPE : 1, time:1} 作为 key 的话，那么就会避免上面的问题。另外以默认的 ObjectID 作为 key 的时候，因为 objectID 是 time-based 的，那么同样会产生上面的问题。

3、? query isolation 尽量使得 query 的结果可以在同一个 shard 上得到，比如说数据有某一属性 TYPE 包括 video 、 channal 、 text 等，那么我们又知道当查询的时候通常把这一属性加入到 condition 中，那么我们可以将 sharding-key 以 TYPE 为开头，自己组装 key ，这样的话，可以使 query 更加有效率。 ( 例如： TYPE_md5( 可以用 url 的 md5))

4、? sorting

5、? reliability 可靠性，衡量 sharding 的原则就是要看如果一个 shard 出现故障，那么对系统的影响到底会有多大。用一个 twitter-like 的系统做例子：

{_id : ObjectID()