MongoDB shard 开启

为啥要 shard：个别 collection 数据量越来越大，又没法 archive，索引大，读取和写入性能极差。shard 可以分割数据和读写

MongoDB 的 shard，可以指定需要 shard 的 collection，这样不用所有 collection 都折腾；已经 shard 的 collection 可以取消 shard，数据会从别的 shard 传回 primary shard；可以从 replica 平滑升级到 shard。这些可以保证平滑开启。

相对于 repica，shard 多了 2 种服务：config，用于管理 shard 信息，也就是数据如何映射，非常重要，生产环境中，必须布置 3 个，有一个坏了，数据还可以正常读写，但是数据的合并和迁移就不会发生，如果所有 config 都坏了，或者 config 数据坏了，数据的读写就挂了；mongos，用于读写 shard 数据的接口服务，可以有多个，本身不保留任何状态信息，实际只有 log。

shard keys 是做 shard 前必须要决定的事情，它影响几个方面：查询，如果查询条件包含了 shard keys(必须排在前列，例如查询包含了 userId，(userId, _id) 这个 shardKey 有用, (_id, userId) 这个就没用了)，则查询可以只涉及相关的 replica，否则所有 replica 都要查询；数据分割，好的 shard key 可以让数据分割的均匀，典型的例如 _id，因为每个 document 的 _id 都不一样，所以数据可以分割的非常均匀，而用户表里的性别就是一个非常差的 shard key，因为所有的数据只能分成三块(男，女，未知)；存储压力分配，好的 shard key 可以将存储压力平均的分配到所有 replica 上，刚才那个 _id 在这里就是一个很差的 shard key，因为所有新数据都集中在某个分片，也就是某台机器上，这台机器压力会很大。shard key 的选择和存储的数据用法很有关系，没有一个万能的选择方案，不过任何一个介绍 shard 的书或正式文档都会讲到 shard key 的选择，可以参考。

shard 过程比较简单，首先搭起新的 mongos, config, replica 机器，连接 mongos，指定 config，首先添加原来的 replica，这样它就成为 primary shard，然后添加其他 replica 作为 shard。之后指明某个 db 可以 shard，指明某个 collection 可以 shard，指明 shard key，之后 mongo 会自动开始挪动数据，挪动过程中数据可以正常读写。