断片（シャーディング）はそう処理し、大きい負荷より多くのデータを格納することができる強力なサーバを必要とせず、サーバによって使用される異なる分散方法に割り当てられたセットMongoDBの大きなデータに使用される。基本的な考え方は、セットカットであります、小ブロックシートを複数に分散させ、各シートは、全データの一部に対してのみ責任があり、最終的に等化（イコライザによって各フラグメントについてのデータマイグレーション。ルーティングプロセスによって操作がmongos呼び出され実行、mongosを知ります（構成サーバにより）、対応データシート。
基本的なアーキテクチャ
- mongos：入口アクセス自体が永続的データではなく、読み取りおよび書き込み操作をコンポーネントによって実行されるクラスタは、一貫した状態mongosにおいてクラスタ内の複数のコンポーネントは、一般的に複数のノードを持っていることを確認することが推奨されます。
- 設定サーバ：メタデータ記憶クラスタ、すなわち、情報（マッピング、実際のデータが保存されていない）を含むデータの各スライスが、小さな空間が必要とされます
- シャード：ユーザデータトラフィックを格納するレプリカセットは、単一のマシンであってもよいとすることができる、チャンク単位で格納されたデータ
とき私は、断片化を使用する必要がありますか？
- 単一マシンのストレージの欠如
- 単一のマシンは、サーバ自身のリソースの断片化を使用して、その上で各スライスにスライスを分散筆圧によって書き込まれたデータのパフォーマンス要件を満たすことができません
何チャンクいますか？
シャーディング機能を使用した後、データに基づいて、shard keyデータのチャンクには、サーバ上の異なる断片に分割されchunk(默认64M)、主に以下の機能を有します
- spliting（スプリット）
のチャンクに書き込まれたデータの量、上にデータが書き込まれるchunk size(64M)時、MongoDBのバックグラウンド・プロセス・トリガチャンク分割、小さなチャンクに分割は、大きすぎる単一のチャンクを防止します - バランス（バランス）
IOリソースを消費分裂および移動の各シャードチャンク偏在に、移行トリガチャンク。チャンク。
chunk在写入数据时会分裂, 在读取时不会. chunksize会影响数据的迁移速度, 如果chunksize很大, 数据分裂少, 但是迁移会很慢, 还可能出现chunk内文档数过多无法迁移(chunk 内文档数不能超过 250000)
jumbo chunk
MongoDB 默认的 chunk size 为64MB，如果 chunk 超过64MB 并且不能分裂（比如所有文档 的 shard key 都相同），则会被标记为jumbo chunk ，balancer 不会迁移这样的 chunk，从而可能导致负载不均衡
数据分布
范围分片(Range based)和hash分片(Hash based)
- 范围分片
优点: 能很好满足范围查询的需求, 因为连续的数据大概率在一个shard上, 也可能在一个chunk上.
缺点: 如果分片键是连续递增的话, 新插入数据会落到一个chunk上, 如果这部分数据特别活跃, 则不能充分利用集群的性能优势. 注意: mongodb的_id高位是时间戳递增的 - hash分片
优点: 可以更好的利用集群性能
缺点: 不能快速进行范围查询
分片键
分片键决定了数据会以怎样的策略进行分布, 主要有
- 递增型
- 随机性
- 混合型
可以结合业务特点来选择合适的分片键, 同时要注意以下
- 分片键一旦设置不能取消
- 分片键必须有索引. 如果集合是非空, 必须先设置该field为索引, 才能指定为分片键
- 分片键用于路由查询
- 分片键大小限制512bytes
# 启用数据库分片:
sh.enableSharding("<database>")
# 使用hash分片键
sh.shardCollection('db.collection', {'field':'hashed'})
# 使用递增分片键
sh.shardCollection('db.collection', { field: 1})
# 查看分片是否成功
db.collection.stats().sharded
# 查看数据分布
db.collection.getShardDistribution()参考资料
