《MongoDB扩展技术》读书笔记之一

这本书是第二次从图书馆借阅了，第一次没时间看。

上周没借到自己想要的书，又看到这货，于是第二次借回来……也许是因为对O'Reilly的“动物书”有着特殊的爱好

现在工作中负责的业务有用到MongoDB，但基本我没插手，都是开发在倒腾。

《深入学习MongoDB》分2个部分，分别是《MongoDB扩展技术》和《MongoDB开发技巧50例》。

今天看了《MongoDB扩展技术》前3章，小记如下：

第1章：欢迎

《终结者》系列电影中，长时间运行而无需人工干预的分布式系统：“天网”，简直就是运维人员的梦想

单台DB的状态：非启即停。如果加一台，他俩会产生什么依赖？任意某台宕机（或响应缓慢），你的业务会有什么影响？如果更多的节点被加入集群，这类问题会变得越来越复杂。

MongoDB的分片主要为了3个简单的目的：

1、让集群不可见，也就是对于应用层，DB是抽象的

2、保证集群总是可读写

3、使集群易于扩展

第2章：理解分片

2.1  分割数据

分片（shard）是集群中负责数据某一子集的一台或多台（副本集replica set）服务器。

MongoDB根据key决定如何在不同分片之间移动数据子集，并按照区间的方法将数据分割成不同块。

MongoDB中分片多用[a, b)表示区间范围。“[”是闭区间，也就是“小于等于”；“）”是开区间，是“大于但不等于”。

一份片一区间：体系简单，但要保持负载均衡，就会“牵一发而动全身”，带来巨大的数据移动开销。而且随着分片数量和数据量的增长，这种级联效应只会持续恶化。

一份片多区间：一个区间的数据称为一个数据块（chunk）。当一个块变得越来越大时，MongoDB会自动分割成两个较小的块。如果分片间比例失调，则MongoDB会通过迁移块来确保均衡。

对一个集合分片时，无论集合里有什么数据MongoDB都只会创建一个块，区间是（-∞，∞）。如果被分片的集合数据很大，MongoDB会立刻把初始块分割为多个较小的块。块的默认大小是200MB，第一次启动mongos时，可声明 --chunkSize N，单位是MB，或修改config.setting。

必须为块区间选择一个片键（shard key），片键可以是任意字段或字段的组合。

MongoDB不允许插入无片键的文档（虽然可以用null作为片键），也不能修改文档的片键值（只能先删除文档，在客户端修改片键值后重新插入）

MongoDB中类型的先后次序：null<数据<字符串<对象<数组<二进制数据<ObjectId<布尔值<日期<正则表达式

2.2  平衡

如果存在多个可用的分片，只要块的数量足够多，MongoDB就会把数据迁移到其他分片，这个迁移过程叫做平衡（balancing），由叫做平衡器（balancer）的进程负责执行。它会每天基于分片整体大小来移动块。优点是自动化，缺点也是。平衡器的目标不仅是保持数据均匀分布，还要最小化被移动的数据量。通常平衡器并不非常激进，以避免颠簸。否则，太过强调绝对平衡，会带来过多不必要的数据移动。做实验时，可设置--chunkSize 1来观察迁移。

除非是为了好玩试试1MB的块大小，请勿随意改动块大小。我可以保证，无论你在尝试解决什么问题，摆弄块大小绝对不是根本的解决之道。

mongos是用户和集群之间的交互点，会将请求转发到适当的分片，隐藏分片内部的复杂性，并向用户提供一个简介的单服务器接口。虽然可以绕过mongos直接访问分片，但是不应该这样。

要保证数据块迁移成功，所有配置服务器都必须同时在线，任意一台停机都会导致当前正在执行的迁移回退并终止，集群配置也无法修改，直到整套配置服务器再一次运行起来。

第3章：建立集群

3.1  选择片键

选择一个好的片键非常关键。几个反面教材：

1、小基数片键（low-cardinality shard key），最终会得到一堆既巨大又无法移动，还不能分割的块。例：每个大洲一个分片

2、升序片键（ascending key）：所有数据总是被添加到“最后”一个数据块上，创造了一个单一且不可分散的热点。例：微博按照发送时间字段来分片

3、随机片键：平衡时，会把不必要的冷数据重新加载到RAM，还会引发大量磁盘IO。例：按MD5散列值分片

好的片键应具备靓号的数据局部性（data locality），但有不会因为太局部而导致热点出现。例：准升序键加搜索键，多数应用访问新数据比老数据频繁，所以希望数据大致上按照时间排序，同时也要均匀分布。

片键公式：｛coarseLocality：1，search：1｝，其中coarseLocality字段控制数据局部化。search字段则是数据上常用到的一个检索字段。