#### 如何做好分片集群
* 合理的架构
* 是否需要分片？
* 要分多少片？
* 数据分布规则？
* 正确的姿势
* 选择需要分片的表
* 选择正确的片键
* 使用合适的均衡策略
* 足够的资源
* 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%以上，则开始考虑扩展，因为：
* 扩展需要新的资源，申请新资源需要时间；
* 扩展后数据需要均衡，均衡需要时间。应保证新数据入库速度鳗鱼均衡速度
* 均衡需要资源，如果资源即将或已经耗尽，均衡也是很低效的。