经常对配置服务器做数据备份,应常在执行集群维护操作之前备份配置服务器的数据;
基于片键第二个字段的范围可能会出现在多个块中,如果只根据第二个片键值查询时就必须查看几乎所有的块;
具有相同片键的文档必须保存在相同的块中,因此块只能在片键的值发生变化的点对块进行拆分;
拥有不同的片键值是非常重要的;
“拆分风暴”:mongos不断重复发起拆分请求却因为配置服务器不可用而无法进行拆分的过程;
防止“拆分风暴”的唯一方法就是尽可能保证配置服务器的可用和健康;也可以重启mongos,重置写入计数器,这样就不再处于拆分阈值点了;
如果mongos进程频繁地上线和宕机,那么mongos在再次宕机之前可能永远无法收到足以达到拆分阈值点的写请求,会导致块变得越来越大;实际部署中发现维持不需要的mongos持续运行开销过大,可以使块的大小比实际预期稍小些,这样就更容易达到拆分阈值点;
一旦拥有多个分片,再修改片键几乎是不可能的事情,因此选择合适的片键(或者至少快速注意到可能存在的问题)是非常重要的;
吞吐量:指集群在同一时间能够处理的请求数量;
拆分数据常用的数据分发方式有三种:
1)升序片键 ascending key
所有的写请求都会被路由到一个分片(最大块max chunk所在的分片)中,随着新数据不断插入,该最大块会不断拆分出新的小块;导致数据均衡处理变得更为困难;
2)随机分发片键
写入数据随机分发,各分片增长速度大致相同,减少了需要迁移的次数;
唯一弊端在于,MongoDB在随机访问超出RAM大小的数据时效率不高;如果拥有足够多的RAM或者是并不介意系统性能的话,使用随机分片在集群上分配负载是非常好的;
3)基于位置片键 location-based key
片键策略
散列片键 hashed shard key
大量查询中使用升序键,同时希望写入数据随机分发;弊端:无法使用散列片键做指定目标的范围查询、不能使用unique选项、不能使用数组字段、浮点型的值会先被取整然后才散列;
复合片键 compound shard key
片键的限制:不能是数组;文档一旦插入片键值就无法修改了;大多数特殊类型的索引不能被用作片键;
分片标签技术