断片のシェアは、データ内の異なるノードで異なっています。もう少し複雑な単純にコピーするよりも設定してください。そのデータ記憶ノードとルーティングノードmongos、中央ノード構成configsvrに加えて、configsvrデータは、メタ情報を格納し、格納されていない、すなわち、そのシート上のデータの情報。最初のクエリデータmongosがconfigsvr見てみると、ノード上のデータを尋ねます。
フラグメントは、4つの要素があります。
（1）N個のノードを有し、N> = 2
（2）configsvrメタ情報を保持しています
（3）mongosは、ルーティングを行う開始するには
（4）良好なデータの断片化のルール（configsvrを保護するように設定ルール）を設定します
アクセスされるデータを以下に示します。
次のように単純なスライスが記録ステップを共有します：
（1）は、4つの確立は、フリーのMongoDBにおけるサービスプロファイル、場所を開始します。
smongodb1.conf
DBPATH = / VAR / smongodb / mdata17 ログパス = / VAR / smongodb / MLOG / mongolog17.log smallfiles = 真 logappend = 真 bind_ip = 0.0。0.0 フォーク = 真 ポート = 27017
smongodb2.conf
ログ・パス= / VAR / smongodb / MLOG / mongolog18.log smallfiles = 真 logappend = 真 bind_ip = 0.0。0.0 フォーク = 真 ポート = 27018
smongodbConfigsvr.conf
DBPATH = / VAR / smongodb / mdata20 ログパス = / VAR / smongodb / MLOG / mongolog20.log smallfiles = 真 logappend = 真 bind_ip = 0.0。0.0 フォーク = 真 configsvr = 真 ポート = 27020
smongodb.conf
ログ・パス= / VAR / smongodb / MLOG / mongolog30.log logappend = 真 bind_ip = 0.0。0.0 フォーク = 真 ポート = 30000 てConfigDB = 192.168。31.151：27020
（2）シーケンスの次の操作を実行
クリア履歴データ
RM -rfは/ var / smongodb /
データログ保存パスを作成します。
ます。mkdir -p / VAR / smongodb / mdata17の/ var / smongodb / mdata18の/ var / smongodb / mdata20の/ var / smongodb / Mlogs
27017,27018サービスポート（2つのインスタンス）を起動します
/ usr / local / mongodb245 / binに/のmongod -f /usr/local/mongodb245/smongodb1.conf
/ usr / local / mongodb245 / binに/のmongod -f /usr/local/mongodb245/smongodb2.conf
configsvrサービスを開始
/ usr / local / mongodb245 / binに/のmongod -f /usr/local/mongodb245/smongodbConfigsvr.conf
ルーティングサービスを開始Mongos
/ usr / local / mongodb245 / binに/ mongos -f /usr/local/mongodb245/smongodb.conf
二枚のノード増加
/ usr / local / mongodb245 / binに/モンゴ--port 30000
sh.addShard（ '192.168.31.151:27017'）
sh.addShard（ '192.168.31.151:27018'）
以上の動作を実行した後、ステップを構築することは、ルートノードにログインステータス断片を表示することができ、完了しました。
30000ルーティングノードクライアント--portは/ usr / local / mongodb245 /ビン/モンゴが記録後の状態、実行sh.status（）表示断片
見ることができるノードに対応する192.168.31.151.27017断片であるshard0000、ノードに対応する192.168.31.151.27018スライスであるshard0001。管理データベースのスライスを設定します。ないフラグメンテーションルール構成は、それが達成され、断片化データできないように次のように、テストは次のとおりです。
mongos> db.goods.insert（{名：' 電動歯ブラシ1 ' }）
mongos > db.goods.insert（{名：' 電動歯ブラシ2 ' }）
mongos > db.goods.insert（{名：「電動歯ブラシ3 ' }）
mongos > db.goods.insert（{名：' 電動歯ブラシ4 ' }）
次のように何sh.statsu（）の実装では、データ、および無ライブラリショップを照会することはできません27018ノードにログインし、データを照会することができ、この時間は27017ノードログイン、ショットは以下のとおりです。
赤い部分に分配におけるボックス：false説明フラグメンテーションがルールデータを設定されていない、一次：shard0000好ましいエリアデータを挿入すると言うことであるshard0000ので、データは192.168.31.151.27017サービスによって書かれました。設定以下の断片化規則：
mongos> db.goods.remove（{}）; 試験のために、すべてのデータを消去します
mongos> sh.enableSharding（「店」）フラグメントライブラリが指定されているお店
mongos> sh.shardCollection（ 'shop.goods'、{goods_id：1}）;店の商品データベーステーブルに割り当てられた断片フィールドgoods_idを断片
次のように完）（再びルール、実行sh.statsuを指定し、ショットは以下のとおりです。
あなたはgoods_idれる真、シャードキーに分割ショップライブラリーを見ることができます。フィールドは,,システムがフィールドに割り当てられたデータの部分がキーピースキー・フィールドと呼ばれるフィールドの値を計算するために使用する、コレクションの重要な部分であるMongoDBの各片に散乱した平均絶対のレベルから文書の単品ではなく、 N一つの文書は、1つのブロックが優先順位が、用紙上に配置され、「チャンク」に形成されている場合（3> =）、フィルム上の別のチャンクがする他のシートよりも大きなチャンク差におけるこのチャンクオンチップ、MongoDBのチャンク単位でシート保持との間のデータのバランスを。単にデータに格納された複数のオンチップチャンク、チャンクが存在することを意味します。デフォルトのチャンクサイズは64Mですが、それを変更することができます。300000は現在、1Mのチャンクの大きさをテストするために、ビュー・データ片を格納されたデータに続いて挿入されます
mongos> db.settings.find（）;
{ "_id"： "チャンク"、 "値"：64}
mongos> db.settings.save({_id:'chunksize',value:'1'});
mongos> db.settings.find();
{ "_id" : "chunksize", "value" : "1" }
mongos> for(var i=1;i<=300000;i++){ db.goods.insert({goods_id:i,goods_name:'aaaaaaaaaaaaa sddddddddddd fsddddddddddd fgggggggggggggggg hhhhhhhhhhhhhhh kkkkkkkkkkkkkk'});}
mongos> db.goods.find().count();
300000
登录27017
> db.goods.find().count();
3891
登录27018
> db.goods.find().count();
296109
两个片上都写入了数据，说明分片成功，再看一下截图 sh.status();
图中可以清楚的看到shard0000片有2个chunk，shard0001片有3个chuck，根据goods_id的范围可以看到数据是怎样在不同片上分布的。
这样配置有个问题，由于数据优先往某个片上插入，不同片上 chunk 的量会不同，导致失衡，为求平衡shard的实例之间有chunk来回移动的现象。这样增加了服务器之间的IO。下一篇解决这个问题。