1.データセグメンテーションモード
垂直（垂直）セグメンテーション：1つのテーブルを複数のテーブルに分割し、それらを異なるデータベース（ホスト）に配布します。
水平（水平）セグメンテーション：テーブル内のデータの論理関係に従って、同じテーブル内のデータは、特定の条件に従って複数のデータベース（ホスト）に分割されます。
①、垂直分割
データベースは複数のテーブルで構成されており、各テーブルは異なるビジネスに対応しています。垂直セグメンテーションとは、ビジネスに応じてテーブルを分類し、異なるデータベースに分散して、データを異なるデータベース（特別なデータベース）間で共有することです。 ）。
利点は次のとおりです。
1）分割後、事業は明確になり、分割ルールも明確になります。
2）システム間の統合または拡張は簡単です。
3）コスト、アプリケーションレベル、アプリケーションタイプなどに応じて、メーターをさまざまなマシンに配置して、管理を容易にします。
4）、動的および静的分離、コールドおよびホット分離の実現を容易にするデータベーステーブルの設計モード。
5）簡単なデータメンテナンス。
欠点は次のとおりです。
1）一部のビジネステーブルは関連付けることができず（結合）、インターフェイスを介してのみ解決できるため、システムが複雑になります。
2）各ビジネスの制限が異なるため、ライブラリのパフォーマンスのボトルネックは1つであり、データの拡張とパフォーマンスの向上は容易ではありません。
3）複雑なトランザクション処理。
②、水平セグメンテーション
垂直セグメンテーションと比較して、水平セグメンテーションはテーブルを分類しませんが、フィールドの特定のルールに従って複数のデータベースに分散します。各テーブルにはデータの一部が含まれ、すべてのテーブルが合計されて全量のデータになります。
簡単に言えば、データの水平セグメンテーションは、データ行によるセグメンテーション、つまり、テーブル内の特定の行を1つのデータベーステーブルにセグメンテーションし、他の行を他のデータベーステーブルにセグメンテーションすることとして理解できます。
このセグメンテーション方法は、単一テーブルのデータボリュームのサイズに基づいており、単一テーブルの容量が大きくなりすぎないようにします。これにより、ユーザー情報テーブルの分割など、単一テーブルクエリの処理機能が保証されます。 User1、User2待機に、テーブル構造はまったく同じです。通常、ユーザーIDによるモジュラー除算など、特定のルールに従ってテーブルを除算します。
利点は次のとおりです。
1）単一のデータベースと単一のテーブルのデータが一定のレベルに保持されるため、パフォーマンスの向上に役立ちます。
2）分割テーブルの構造は同じであり、アプリケーション層の変更は少なく、ルーティングルールのみを追加する必要があります。
3）システムの安定性と負荷容量を改善します。
欠点は次のとおりです。
1）セグメンテーション後、データが分散し、データベースの結合操作を使用することが困難になり、データベース間の結合のパフォーマンスが低下します。
2）分割ルールを抽象化するのは困難です。
3）断片化されたトランザクションの一貫性を解決するのは困難です。
4）データ拡張の難しさとメンテナンスの量が非常に大きい。
③、水平セグメンテーションのシャーディング次元
データスライスにはさまざまなスライス寸法があります。Mycatが提供するスライス方法を参照できます（本書のセクション3.4を参照）。ここでは、最も一般的に使用される2つのスライス寸法のみを紹介します。
1）ハッシュスライスによると
データの特定のフィールドをハッシュし、それをシャードの総数で割って、モジュラスを取得します。モジュラスを取得した後、同じデータが1つのシャードになります。データを複数のシャードに分割するこの方法は、ハッシュシャーディングと呼ばれます。
2）時間に応じてスライスする
この方法は、ハッシュによるスライスとは異なり、時間の範囲に応じて異なるシャードにデータを分散します。たとえば、トランザクションデータの量に応じて、月ごとまたは四半期ごとにトランザクションデータをスライスできます。データがスライスされる期間に応じて、 。
④。垂直および水平セグメンテーションの共通点：
分散トランザクションに問題があります。
ノード間での結合に問題があります。
クロスノードマージソートとページングの問題があります。
マルチデータソース管理の問題があります。
2.サブデータベースとサブテーブルによってもたらされる分散型ジレンマと対策
データの移行と拡張の問題
前に紹介したレベルスコアリング戦略は、ランダムスコアリングと連続スコアリングとして要約できます。連続サブテーブルには、データホットスポットの問題がある可能性があります。一部のテーブルは頻繁にクエリされ、大きなプレッシャーを引き起こす可能性があります。ホットデータテーブルはライブラリ全体のボトルネックになり、一部のテーブルには履歴データが格納されることがありますが、これはほとんど必要ありません。照会されました。連続サブテーブルのもう1つの利点は、簡単なことです。古いデータの移行を検討する必要はありません。自動的に展開するには、サブテーブルを追加するだけで済みます。ランダムサブテーブルのデータは比較的均一であり、ホットスポットや同時アクセスのボトルネックが発生しにくいです。ただし、サブテーブルの拡張には、古いデータの移行が必要です。
水平サブテーブルの設計は非常に重要です。短期および中期的なビジネスの成長率を評価し、現在のデータ量を計画し、コスト要因を統合し、必要なシャードの数を計算する必要があります。データ移行の問題の場合、一般的なアプローチは、最初にプログラムを介してデータを読み取り、次に指定されたテーブル分割戦略に従って各サブテーブルにデータを書き込むことです。
テーブルの関連付けの問題
単一のデータベースと単一のテーブルの場合、共同クエリは非常に簡単です。ただし、サブデータベースとサブテーブルの進化に伴い、共同クエリではデータベース間の関連付けとテーブル間の関係の問題が発生します。設計の開始時に、共同クエリは可能な限り回避する必要があります。プログラムでアセンブルするか、非正規化された設計によって回避することができます。
ページングと並べ替えの問題
一般に、リストをページングするときは、指定したフィールドに従ってリストを並べ替える必要があります。単一のデータベースと単一のテーブルの場合、ページングと並べ替えも非常に簡単です。ただし、サブデータベースとサブテーブルの進化に伴い、データベース間ソートとテーブル間ソートの問題も発生します。最終結果を正確にするには、データを別のサブテーブルに配置して並べ替えて返す必要があります。テーブルは、集計と並べ替えのさまざまなポイントで結果セットを返し、最終的にユーザーに返します。
方法1：グローバルビュー方法
（1 ）時間オフセットX制限Yによる言い換え順序、時間オフセット0制限X + Yによる言い換え成順序
（2 ）サービス層は、取得したN *（X + Y）個のデータに対してメモリソートを実行し、メモリソート後のオフセットXの後にYレコードを取得します。
ページめくりの進行に伴い、このメソッドのパフォーマンスはますます低下しています。
方法2：ビジネスの妥協方法-ジャンプページクエリなし
（1 ）通常の方法を使用して最初のページのデータを取得し、最初のページに記録されたtime_maxを取得します
（2 ）ページをめくるたびに、時間オフセットX制限Yによる順序を時間による順序として書き換えます。ここで、time> $ time_max limit Y
一度に1ページのデータのみが返されるようにするために、パフォーマンスは一定です。
方法3：2番目のクエリ方法
（1 ）時間オフセットX制限Yによる言い換え順序、時間オフセットX / N制限Yによる言い換え成順序
（2 ）最小値time_minを見つけます
（3 ）の間二次查询、$ time_minと$ time_i_maxの間の時間によって順
（4 ）設定した仮想time_minは、見つけるのオフセットtime_min各サブライブラリーでは、と取得グローバルオフセットtime_minを
（5 ）time_minのグローバルオフセットを取得し、自然にグローバルオフセットX制限Yを取得します
分散トランザクションの問題
サブデータベースとサブテーブルの進化に伴い、分散トランザクションの問題が確実に発生するため、データの整合性を確保する方法が直面しなければならない問題になっています。現在、分散トランザクションには適切なソリューションがなく、強力なデータ整合性を満たすことは困難です。一般に、保存されたデータは、システムが短期間で回復および変更されるように、ユーザーと可能な限り整合性を保つ必要があります。時間、そしてデータは最終的に全会一致に到達します。
グローバルに一意のIDを配布
単一のデータベースと単一のテーブルの場合、データベースの自動インクリメント機能を使用して主キーIDを生成するのは非常に簡単です。サブデータベースとサブテーブルの環境では、データは異なるサブテーブルに分散され、データベースの自己成長機能は使用できなくなります。UUID、GUIDなどのグローバルに一意のIDを使用する必要があります。適切なグローバル一意IDの選択方法については、後の章で紹介します。
業界ソリューション：
UUID：16バイトと128ビットの一意の識別コードを持つ長い番号。
コンポーネント：現在の日付と時系列+グローバルな一意のネットワークカードのMACアドレス
利点：コードの実装が簡単で、帯域幅を使用せず、データ移行に影響を与えません
短所：無秩序、増加傾向を保証できない（要件3）文字の保存、送信、クエリが遅く、読めない
スノーフレークアルゴリズム
外国での分散TwitterID生成アルゴリズム
1ビット+41ビット+10ビット+10+ビット= 62ビット
高ランダム+ミリ秒+マシンコード（データセンター+マシンID）+10良好なフロー
国内の：
データIDCコンピュータルームの一意性を確認するだけです
利点：単純なコード実装、帯域幅の占有なし、影響を受けないデータ移行、および低レベルの傾向の増加
短所：強力なクロック（複数のサーバーが同時に必要）、無秩序はトレンドの増加を保証できないRedis：
バージョンの削減、関連するビジネスコードが含まれていない、Redisプログラムの
長所：データに依存しない、柔軟性があり便利、パフォーマンスはデータベースよりも優れている、いいえ単一障害点（高可用性）
短所：ネットワークリソースを占有する必要がある、パフォーマンスがローカル生成よりも遅い、プラグインを追加する必要がある
3、まとめ
サブデータベースとサブテーブルは、主にインターネット上の2つの一般的なシナリオ（大量のデータと高い同時実行性）を処理するために使用されます。ただし、サブデータベースとサブテーブルは両刃の剣であり、大量のデータの影響とプレッシャー、およびデータベースへの高い同時実行性にうまく対処できますが、システムの複雑さと保守コストが増加します。
したがって、私の提案：実際のニーズと組み合わせて、過剰に設計しないでください。プロジェクトの開始時には、サブライブラリとサブテーブルの設計を採用するべきではありませんが、ビジネスが成長するにつれて、最適化を行う必要があります。続行できない場合は、サブライブラリとサブディビジョンを検討してください。テーブルにより、システムのパフォーマンスが向上します。