Shard key
- shard key不能是array field
- shard key一旦设置，不能再修改
- shard key默认非unique
Shard key种类：
1. Ascending shard key:
简单来说就是，不断增加且增长只在尾部maxkey的chunk(max chunk)发生 ，最终造成数据分布不均匀的shard key 。
解决且优化处理ascending shard key：
The Firehose Strategy
利用Location-Based Shard Keys，将存放$maxkey的chunks放到性能更强的机器 。再使用cron job之类的调度工具，每天将不再活跃的数据移动到弱性能不服务器上。
(致命缺点，如果整个高性能replica set 挂了，那么可能会造成没有任何集群能接手/承受住它的负载。)
Multi hotspot
利用compound key, 选择一个低cardinality的field作为compound key的第一个key, ascending key作为第二个key。
这样一个collection会因为第一个key分成N个chunk，同时又因为第二个key是不断增长的。对于某一个chunk来说，它就类在standalone-server上的single chunk一样，永远不断增长。同时它又相对分布平衡。
注意：当新增shard到配置了multi hotspot的集群的时候，将会触发balancer迁移数据到新的shard上来平衡分布。
2. Randomly Distributed Shard Keys：
比较理想的KEY，因为天然的随机特性。
比如：usernames, email addresses, UUIDs, MD5 hashes,Hashed Shard Key
缺点：当获取的数据超过内存容量时，效率将很差。
Hashed Shard Key
当对不存在的collection进行hashed shard key处理的时候，mongodb会在空的chunks分布到集群中。
- hashed shard key 不能使用unique选项。
- 任何shard key为数字类型的都会被先进行round处理，再转换为hash key。即可能出现大量重复。
1.需要创建Hashed index
db.users.createIndex({“username” : “hashed“})
2. 创建shard key
sh.shardCollection(“app.users”, {“username” : “hashed“})
3. Location-Based Shard Keys：
按取值范围对某个field(shard key)设置分组，将特定分组放到特定的shard上，达到分组查询、将频繁查询的数据放到性能更强的shard上的目的。
不在设置规则field取值范围，会按正常规则存放/分布到shard集群上。
将现有shard按Zone分组：
> sh.addShardToZone(“shard0000”, “USPS”)
> sh.addShardToZone(“shard0000”, “Apple”)
> sh.addShardToZone(“shard0002”, “Apple”)
设定每个Zone分组的取值范围：
- sh.updateZoneKeyRange(“test.ips”, {“ip” : “056.000.000.000”}, {“ip” : “057.000.000.000”}, “USPS”)
- sh.updateZoneKeyRange(“test.ips”, {“ip” : “017.000.000.000”}, {“ip” : “018.000.000.000”}, “Apple”)
移除zone分组:
sh.removeShardFromZone(“shard0005”, “whatever”)
Zone分组的技巧：
通过Zone分组，我们还可以让重要的数据只存在于特定的服务器组中。不重要的数据存放在另一组服务器中。
通过一个collection修改对应的分组,我们可以控制chunks在集群中的分布。
Administration：
Config Server各collection存放的信息
1.config.shards : shard member list
2.config.databases：所有 shard或非shard数据库的元数据（不含系统数据库）
config.databases中partitioned字段表示对于该库是否启用了shard。
3.config.collections: 所有shard的collection的元数据（不含非shard collection）
4.config.chunks：存有每个collection上所有chunk的信息
5.config.changelog: 记录split,migration
6.config.settings： chunk size 和balancer信息
网络管理:
1.connPoolStats命令，查看服务器outgoing连接。命令不会产生任何锁
db.adminCommand({“connPoolStats”: 1})
2.限制连接数：
对mongos 使用maxConn参数，限制可以连接mongos的client数量。
官方建议的计算公式：maxConns = 20,000 ? (numMongosProcesses × 3) ? (numMembersPerReplicaSet × 3) ? (other / numMongosProcesses)
