mongodb的Sharding和replica Sets

为什么要用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()

  User_id : 23

  Time : “2011-12-1 00:12:23”

  ……

}

       如果我们以 _id 作为 sharding-key ，那么是可以保证颗粒性的，但是当一个 shard 出现故障的时候，几乎所有的用户都会受到影响 ( 丢失一部分数据 ) 。

       但是如果我们以 user_id 为开头作为 key 的话，那么出现故障时，有一部分 user 看不到所有的数据，但是其他的 user 是可以正常使用的，这个是我们可以做的最好的选择。

6 、 index optimization 索引优化

 

 

 

使用mongodb插数据，没有抛出异常，却发现有丢失数据的情况发生，可以试一下设置一下的参数：

• WriteConcern.NONE : No exceptions thrown.
• WriteConcern.NORMAL : Exceptions are only thrown when the primary node is unreachable for a read, or the full replica set is unreachable.
• WriteConcern.SAFE : Same as the above, but exceptions thrown when there is a server error on writes or reads.  Calls getLastError() .
• WriteConcern.REPLICAS_SAFE : Tries to write to two separate nodes.  Same as the above, but will throw an exception if two writes are not possible.
• WriteConcern.FSYNC_SAFE : Same as WriteConcern.SAFE , but also waits for write to be written to disk.