本稿では、ルールは、分割内容に応じて、アルゴリズムサブライブラリサブテーブルのプログラムを記述しています。いくつかのルールが現在の状況とを比較する工程を経てステップ、私は道の最後の第五をお勧めします。以降の章に起因する問題は、技術選択とサブライブラリーサブテーブルについて説明します。
背景
ビジネスのボリュームの増加、データの増加量としては、テーブルは、大量のデータを保存することができます、テーブル内の数百万行のデータを持っている、SQLの最適化により、マシンのパフォーマンスを向上させる耐えることができます。将来のための長期的な視点は、データベースのパフォーマンスのボトルネックとして、ある程度のサブライブラリサブテーブルであるべきで、発生時間の長い期間の時間がかかる場合は、フィールドを増加させる必要。独立して、フォールトトレランスを提供するために、すべてのデータノード、分散ノードの複数の圧力下で溶液、システムは必ずしもアクセスにリンクされていません。
目的
この記事では、異なるルール、長所と短所のルールを選択し、サブライブラリーサブテーブルを水平分割の場合に基づいてプログラムを記述し、私はより良い計画がV.をお勧めだと思います
- スキーム：キーモジュロ除数が徐々に増加
- オプション2：時分割
- スキーム3：数値範囲を押します
- オプション4：一貫性ハッシュアイデア - 平均分散方式
- プログラムV：一貫性ハッシュコンセプト - ノードの繰り返し加え（私は、より良い計画を考えます）
プログラムを選択
スキーム：キーモジュロ除数が徐々に増加
式：キーMOD X（xは自然数）
キー主キーはまた、注文番号のためにすることができ、またはユーザIDであってもよいし、このシナリオは、クエリ確率マルチユースたとして、決定する必要があります。
利点：
- オンデマンドライブラリテーブルを増やし、徐々に増加
- 配布、各一つの小さな違い
短所：
- 多くの場合、増分2つのライブラリーで2スタートを開始し、その後、3、4、5人になります。MOD 3 MOD 5を変化させた場合のように、モジュロデータのほとんどは、3 = 0 MOD、3 =キー、急激な変化が5 = 3 MODである場合のように、弾性率の後変更される結果、最初からなり表3から0移行テーブルは、それは多くのデータが繰り返し位置以上に移動します。
- ときに、2つの時点のデータ移行は、データ番号0表A、表1号、データテーブル番号0に戻り四点のデータに3点Aが繰り返されます
オプション2：時分割
これは、四半期ごとに、毎日、毎月することができます。
tb_20190101
tb_20190102
tb_20190103
……
复制代码このアルゴリズムは、断片化のポジショニングに日付をもたらすためにはuserId日付やタイムスタンプ、またはクエリインターフェイスを追加し、注文番号が必要です。
利点：
- 時間による連続データ
- より直感的なデータの増加を参照してください。
短所：
- データサブライブラリサブテーブルはサブテーブルサブライブラリー従わなかったときの歴史が始まったことを考えると、注文番号は必ずしもタイムスタンプ付きの過去のデータはありませんが、過去のデータをインクリメントしてもよいし、分散型主キーから派生したカスタムアルゴリズムは、クエリの原因となります上流のシステムは、注文番号、作成時刻の2つのフィールドが通過しなければならないとき。
- システムは、上流の送信時間の作成時間、または上流システムと対応する注文を作成するための現在のシステム時刻が同じ日でない場合はない場合、データベース・テーブル内の現在のデータレコードは、時間フィールドを必要とします。上流のシステムのみ注文番号、作成時刻を取得するために必要な時間を渡すので、現在のシステムは、注文番号と作成の時間、あなたは現在のシステムにメインテーブルのクエリをチェックする必要があるすべての時間の関係を維持するための主要なテーブルがあり、その後、特定のを確認する必要がありますパフォーマンスを消費することになるテーブル、。
- 必ずしも一様分布：毎月の成長データは同じではありませんが、いくつかの数ヶ月は、いくつかのヶ月よりも少しあってもよいです
推奨使用シナリオ：ロギング
スキーム3：数値範囲を押します
表0 [0,10000000)
表1 [10000000,20000000)
表2 [20000000,30000000)
表3 [30000000,40000000)
……
复制代码利点：
- 配布
短所：
- 最大値が不明であるため、各テーブル番号をインクリメントするので、テーブルの自動インクリメントの主キーを使用しないこの方法は、集中管理されていない、キーとしてタイムスタンプを使用することは不可能です。だからFaをFaをする必要性があるか、ローカルシステムが統一されたキーが自動インクリメント維持することです。
彼はフォローアッププログラムが簡単にハッシュの一貫性について話をすることをお勧めしますと言いました
私はハッシュの一貫性についてお話しましょう、いくつかの記事は一貫性がハッシュアルゴリズムであると言う、私はそれが特定の式が、アイデアの集合ではないと思います。
1.ハッシュは、閉ループ、INT、長い、最大値と最小値を形成し、環状空間、固定された最大値及び最小環、端に接続された端部を前提としています。多くの記事は、最大値は2 ^ 32-1の最小値は0であり、即ち、0〜デジタル空間（2 ^ 32）-1、それらは例として常法に従って単にハッシュアルゴリズム、実際のサブライブラリー画分を2 ^ 32の位置をとるであろう表には、この番号の場合ではありませんので、私は一貫性のハッシュアルゴリズムは、実際に概念ではなく、実際の式であると思うだろう。下記に示すように、
一般的な
この理論は、本明細書に詳細に記載されていない、その意味は、主に一定の最大値、最小値〜最大値と変更されていない、後続ノードのノードのみのノードの位置を変更し、チューブの各ノードに増加したデータ削減を達成するために発現され圧力の低減を達成するためです。
备注：
* 不推荐对ip进行hash，因为可能会导致hash(ip)得出的结果很大，例如得出60，若这个节点的前面没有数据，则这个节点需要管大部分的数据了。
* 最好生成key的方式用雪花算法snowFlake来做，至少要是不重复的数字,也不要用自增的形式。
* 推荐阅读铜板街的方案 订单号末尾添加user%64
复制代码オプション4：一貫性ハッシュアイデア - 平均分散方式
ハッシュ一貫理論を用いて、サブライブラリー選択したハッシュ（キー）基準方程式値=キーMOD 64、サブテーブル式の値=キー/ 64 MOD 64、例えばメイン注文番号等のキーフィールドが頻繁に照会されるのuserId等です。我々は、上記の式は、64の銀行、各テーブル64に分割することができると仮定する（この式は変更に従う）、テーブルは、10万行を想定しています。最大64 * 64 *千万のデータは、私はその日があるだろうと考えているので、私たちも、32 * 32を選択することができ、最大合理的としてこれを持っています。
非常に多くのテーブルには、早期のアクセスを持っているので、各テーブルの挿入データのマルチテーブルの構築を開始し、無駄なマシンなので、我々は場合に最大値を知って、私たちは小さな数字で開始し、私たちがするわけではないのでグループ化された計算された値以上です。
分组公式：64 = 每组多少个count * group需要分组的个数
数据所在环的位置（也就是在哪个库中）：value = key mode 64 / count * count
复制代码次の例では、16の集合、すなわち4分の64 * 4は、4分割され、10進整数を傍受するために来る16のプール、基= 16このときライブラリ式の値=キーモード、その後* 4回、これは、データの場所です。
// 按4个为一组，分两个表
count = 4：
Integer dbValue = userId % 64 / count * count ;
复制代码hash(key)在0~3之间在第0号库
hash(key)在4~7之间在第4号库
hash(key)在8~11之间在第8号库
……
复制代码注：64が実際に開始することができますが、ライブラリとして設定され、その後の変更の32は2つのライブラリ、2へのライブラリーからのライブラリ、そして4つのバンク、徐々に漸進的に設定されています。
図書館反復の拡大の先頭から1ポイント：
分割されたグループ16の後、図の例は、32のグループに割り当てられるようになる、各ライブラリーは、64個のグループの部分的な拡大まで、新しいデータに移行されたデータの半分を考え出す必要があります。
あなたはデータの量を2倍に拡大する必要性を見ることができる場合は2 ^ n個の増加に半分を移行する必要があるので、影響力の比較的大きな球となります。
利点：
- グループは、直接比較一旦32を、分割された場合
- 大量のデータであれば、できる一度やり方過度のテーブルをせずに。
- 配布
- データのほとんどは、データ移行中に移行し、移行を複製する必要があることのようなプログラムを必要としないでください、移行は半分だけが必要です
短所：
- これは、拡張が、影響力の大きな球体することができます。
- 大量のデータの移行、データ移行プログラムのほとんどとは異なり、各テーブルまたはライブラリの現在のプログラムがデータの半分を移行する必要がありますようものの。
- 一度、すべてのために、我々は全体のデータ移行をシャットダウンする必要があります
プログラムV：一貫性ハッシュコンセプト - ノードの繰り返し加え
（私は、より良い計画を考えます）
整合性ハッシュプログラムオプションIII及びIVプログラムと組み合わされるプログラム、比較的スコープを組み合わせ。
データは、各時間は1/2分割スコープを移行するときに第四に、最大範囲設定プログラム64は、2 ^ nは指数関数的な増加ライブラリにまたはテーブル番号からよれば、影響がデータの全体量をもたらすために、そのよう比較的大きいので、直接スプリットグループ32、グループ64一度、すべてのために、または移行の1/2です。
私は一貫性のハッシュコンセプトを維持するための方法を考えたときに今、1つのノードが、むしろ2 ^ nnのノードの4つの単位のプログラムよりも、増加します。しかしながら、ハッシュコード値決意データは、新しいノードのために必要。
我々はすでに状況を初めて目には2つのライブラリを分割していたが、後続の反復のデモを行うには2つのライブラリーのケースを割った1回の反復に基づいて発生しました：
データは、ライブラリDB32というライブラリという名前db64番号64と32号を落下します
反復2：ユーザーが1/2の元衝撃からデータを移行する場合、1/4はユーザーのみに影響するようにオプションIVとの違いは、直接、私たちはただのノードを追加し、2つのノードが増します。
// 按32个为一组，分两个库
count = 32；
Integer dbValue = userId % 64 / count * count ;
if(dbValue<16){
// 上一个迭代这些数据落在db32中，现在走新增节点名为db16号的那个库
dbValue = 16;
return dbValue;
} else {
// 按原来规则走
return dbValue;
}
复制代码イテレーションIII：
唯一の人々の四分の一に影響を与えるように移行する前に、コードの行に最初にすることができます
// 在请求接口中增加逻辑
public void doSomeService(Integer userId){
if(迁移是否完成的开关){
// 如果未完成
Integer dbValue = userId % 64 / count * count ;
if(dbValue<16){
//这部分用户暂时不能走下面的逻辑
return ;
}
}
return dbValue;
}
}
复制代码// 在分片时按32个为一组，分两个库
count = 32；
Integer dbValue = userId % 64 / count * count ;
if(dbValue<16){
// 上一个迭代这些数据落在db32中，有一半需要走新增节点名为db16号的那个库
if(迁移是否完成的开关){
// 如果已经完成，就去db16的库
dbValue = 16;
}
return dbValue;
} else {
// 按原来规则走
return dbValue;
}
复制代码類推により、時に8つのノードの次のラウンド合計、のみ1/8を移行する必要が移行します。
最初の反復でもよいし、最初の繰り返しの範囲が比較的小さくなるようDbValueから32未満は、DbValueからは<8を行う選択選択しないでください。
利点：
- 拡張が簡単
- データは、徐々に徐々に増加したノードの間に増加しています
- 少数のユーザーに影響を与えます
- 反復することにより、リスクを軽減
- アジャイル反復的思考など短い移動時間、
短所：
- 凹凸の期間