MongoDB分片设计

#### 如何做好分片集群
    * 合理的架构
        * 是否需要分片？
        * 要分多少片？
        * 数据分布规则？
    * 正确的姿势
        * 选择需要分片的表
        * 选择正确的片键
        * 使用合适的均衡策略
    * 足够的资源
        * CPU
        * RAM
        * 存储
1. 合理的架构-分片大小
    * 分片的基本标准：
        * 分片的基本标准：
            * 关于数据：数据量不超过3TB，尽可能保持在2TB一个片；
            * 关于索引：常用索引必须容纳进内存；
            - 按照以上初步确定分片后，还要考虑业务压力，随着压力增大，CPU、RAM、磁盘中的任何一项出现瓶颈时，都可以通过添加更多分片来解决。
2. 合理的架构-需要多少个分片
    [!qr](./images/0203_t_1.png)
3. 合理的架构-其他需求
    *考虑分片的分布：
        * 是否需要跨机房分布分片？
        * 是否需要容灾？
        * 高可用的要求如何？        
#### 正取的姿势
    各种概念由小到大：
    * 片键shard key：文档中的一个字段
    * 文档doc：包含shard key的一行数据
    * 块Chunk：包含n个文档；
    * 分片Shard：包含n个chunk
    * 集群Cluster：包含n个分片
    [!qr](./images/0203_t_2.png)   
5. 正确的姿势-选择合适片键
    影响片键效率的主要因素：
    * 取值基数（Cardinality）
    * 取值分布
    * 分散写，集中读
    * 被尽可能多的业务场景用到
    * 避免单调递增或递减片键
6. 正确的姿势-选择基数大的片键
    对于小基数的片键：
    * 因为备选值有限，那么块的总数量就有限；
    * 随着数据增多，块的大小会越来越大；
    * 太大的块，会导致水平扩展时移动块会非常困难。
    - 例如：存储一个高中的师生数据，以年龄（假设年龄范围为15~65岁）作为片键，那么：
        * 15 <= 年龄 <= 65，且只为整数
        * 最多只会有51个chunk
    - 结论：取值基数要大！
7. 正确的姿势-选择分布均匀的片键
    对于分布不均匀的片键：
    * 造成某些块的数据量急剧增大
    * 这些块压力随之增大
    * 数据均衡以chunk为单位，所以系统无能为力
    - 例如：存储一个高中的师生数据，以年龄（假设年龄范围为15~65岁）作为片键，那么：
        * 15 <= 年龄 <= 65，且只为整数
        * 大部分人的年龄范围为15~18岁（学生）
        * 15、16、17、18四个chunk的数据量、访问压力远大于其他chunk
    - 结论：取值分布尽可能均匀
8. 正确的姿势-定向性好
    考虑：
    * 4个分片的集群，你希望读某条特定的数据
    * 如果你用片键作为条件查询，mongos可以直接定位到具体的分片
    * 如果你不用片键，mongos需要把查询发到4个分片
    * 等到最后的一个分片响应，mongos才能响应应用端。
    - 结论：对主要查询要具有定向能力
    - 一个Email系统的片键例子
    ```
        {
            _id: ObjectId(),
            user: 123,
            time: Date(),
            subject: "...",
            recipients: [],
            body: "...",
            attachments: []
        }
    ```
   [!qr](./images/0203_t_3.png)
   [!qr](./images/0203_t_4.png)   
   [!qr](./images/0203_t_5.png)   
   [!qr](./images/0203_t_6.png)
   
9. 足够的资源
    mongos 与 config 通常消耗很少的资源，可以选择低规格的虚拟机；
    
    资源的重点在于shard服务器：
    * 需要足以容纳热数据索引的内存；
    * 正确创建索引后CPU通常不会成为瓶颈，除非涉及非常多的计算；
    * 磁盘精良选用SSD。
    最后，实际测试是最好的检验，来看你得资源配置是否完备。
    
    即使项目初期已经具备了足够的资源，任然需要考虑在合适的时候扩展。
    
    建议监控各项资源使用情况，无论哪一项达到60%以上，则开始考虑扩展，因为：
    
    * 扩展需要新的资源，申请新资源需要时间；
    * 扩展后数据需要均衡，均衡需要时间。应保证新数据入库速度鳗鱼均衡速度
    * 均衡需要资源，如果资源即将或已经耗尽，均衡也是很低效的。