MongoDB Sharding、库、collection设计学习汇总

• sharding设计须考虑的几个因素

• Sharding Key的选择

          在片键的选择上，最好是能够在字段中选择混合型的片键，大范围的递增健、和随机分布的健组合，如按月份递增、按用户名随机。

• 递增的sharding key

                优点：数据文件移动相对较少；

                缺点：对于不断写入的业务，会造成最后一个分片变成写热点，导致最后的一块分片chunk数量比其他的多，最终chunk不断移动；

• 随机的sharding key

                优点：数据分布相对均匀、写入的数据基本上能够分布在多个分片上；

                缺点：随机的片键本身就会给磁盘带来巨大的IO读写；

 

 

• ChunkSize的大小问题

          ChunkSize的默认大小为64M，但是需要根据业务情况、不同硬盘型号、不同文件系统指定合适的chunksize，单个chunkSize一般为100M-200M之间，ChunkSize的大小应该在设计阶段、业务上线之前就要确定。

• 较大的ChunkSize

               优点：chunk分裂少；

               缺点：存在数据分布不太均衡；以及chunk移动时，会消耗大量的IO写资源；

• 较小的ChunkSize

                优点：迁移速度快、数据分布更均衡；

                缺点：chunk分裂更频繁，同样也会消耗大量的IO写资源；

 

• Balancer的时间选择

          需要在业务当天的低谷时段进行数据的自动均衡，如在业务高峰时段设置数据均衡，业务和均衡都在抢占磁盘IO，系统的吞吐量会一下子下降，一般的业务凌晨的业务量会稍微小一些。

• count值不准确

                由于sharding环境下，写入时，chunk都在不断迁移，所以查询出来的数量往往会大于实际写入的数量，用db.collection.aggregate([{$group: {_id: null,count: {$sum: 1}}}])，可以看到实际的写入值。

 

• 库设计

1. 生产环境中，库尽量不要开启auto-sharding功能；

2. 在业务量不是很大的情况下，可以将库手动指定在某个分片上；

3. 集群内存的大小总和应该要大于索引+oplog+数据热点；

4. 将更新频繁的collection放在同一个库中，将更新不是很平凡的表也归类到一个库中；

 

• collection设计

1. 虽然MongoDB为文档型数据库，无须制定schema，但是也意味着每个文档都有重复的字段，会带来空间的浪费，可以通过以下两种办法解决：

1.1  减小字段名，如将address用a来替代，可读性问题在应用层用字段名映射进行解决；

1.2  利用现有wiredtiger引擎中的zlib压缩，可以减小存储空间，也可以减小IO压力；

2. MongoDB自带的_id值默认就是12个字节，可以考虑用其他主键替代，如用户的UID等，可以减小MongoDB的计算压力和存储空间；

3. 对于大表必须要考虑分配的，可以根据主键进行分类，按每个分片的子表不要超过1000条记录计算。