MySQL テーブルとデータベースでデータを分割する方法

ストレージ容量、接続数、および単一マシンの処理能力はすべて制限されているため、リレーショナルデータベース自体がシステムのボトルネックになりやすくなります。単一テーブルのデータ量が 1,000 万または 100 GB に達すると、クエリのディメンション数が多いため、スレーブライブラリを追加してインデックスを最適化しても、多数の操作を実行するとパフォーマンスが大幅に低下します。このとき、分割することを検討する必要があります。分割の目的は、データベースへの負担を軽減し、クエリ時間を短縮することです。

データベース分散の核となる内容は、データの分割（シャーディング）と分割後のデータの配置と統合に他なりません。データ分割とは、複数のデータベースにデータを分散して格納することで、単一データベースのデータ量が少なくなり、ホスト数の拡張によって単一データベースのパフォーマンス問題が緩和され、データベース操作のパフォーマンスを向上させるという目的を達成します。

データのセグメンテーションは、セグメンテーションの種類によって、垂直（縦方向）セグメンテーションと水平（横方向）セグメンテーションの 2 種類に分けられます。

1. 縦方向のスライス

垂直セグメンテーションには、垂直データベースセグメンテーションと垂直テーブルセグメンテーションという 2 つの一般的なタイプがあります。

1.1 垂直データベース

つまり、ビジネス結合に基づいて、相関性の低い異なるテーブルが異なるデータベースに格納されます。このアプローチは、ビジネスに基づいて大規模なシステムを複数の小規模なシステムに分割するのと似ています。

カテゴリは独立して分割されます。「マイクロサービスガバナンス」アプローチと同様に、各マイクロサービスは個別のデータベースを使用します。図に示すように:

異なるモジュールのデータテーブルは、個別のライブラリに保存されます。モジュールは互いに関連していません。

もしそうなら、データの冗長化や二次処理によって解決する必要があります。このビジネス手法とデータ構造は最も明確です。ただし、データベース間関連のクエリを防止できない場合は、このパスを別のものとして宣言します。

1.2 垂直テーブル分割

これは、データベース内の「列」に基づいています。テーブルに多くのフィールドがある場合は、新しい拡張テーブルを作成し、頻繁に使用されないフィールドやフィールド長が長いフィールドを拡張テーブルに分割することができます。フィールドが多数ある場合 (たとえば、大きなテーブルに 100 を超えるフィールドがある場合)、「大きなテーブルを小さなテーブルに分割する」と、開発と保守が容易になり、ページ間の問題を回避できます。MySQL は、最下層のデータページを通じてデータを格納します。レコードが占めるスペースが大きすぎると、ページ間をまたがってしまい、パフォーマンスのオーバーヘッドがさらに増大します。さらに、データベースは行単位でデータをメモリにロードするため、テーブル内のフィールドが短くなり、アクセス頻度が高くなります。メモリはより多くのデータをロードでき、ヒット率も高くなるため、ディスク IO が削減され、データベースのパフォーマンスが向上します。

垂直セグメンテーションの利点:

業務システムレベルでの結合を解決し、業務を明確にする
マイクロサービスのガバナンスと同様に、さまざまなビジネスのデータを階層的に管理、維持、監視、拡張することもできます。
同時実行性の高いシナリオでは、垂直セグメンテーションにより、IO、データベース接続数、および単一マシンのハードウェアリソースのボトルネックをある程度改善できます。

欠点:

一部のテーブルは結合できず、インターフェース集約を通じてのみ解決できるため、開発の複雑さが増します。
分散トランザクション処理は複雑である
1つのテーブルにデータが多すぎるという問題がまだ残っています（水平方向のセグメンテーションが必要です）

2. 水平（横断）セグメンテーション

アプリケーションをより細かい粒度で垂直に分割することが難しい場合、または分割後のデータ行の量が膨大で、単一データベースの読み取り、書き込み、およびストレージのパフォーマンスにボトルネックがある場合は、水平分割が必要になります。

水平シャーディングは、データベース内シャーディングとサブデータベースシャーディングに分けられます。テーブル内のデータの固有の論理関係に基づいて、異なる条件に従って同じテーブルを複数のデータベースまたは複数のテーブルに分散します。各テーブルにはデータの一部のみが含まれるため、単一のテーブル内のデータ量が削減され、分散効果が得られます。図に示すように:

テーブルを分類する垂直分割と比較すると、この方法は、テーブル内のフィールドごとに一定のルールに従って異なるデータベース（または異なるテーブル）にデータを格納する、つまり行数に応じてデータを分割する方法です。

データベース内のテーブルを分割すると、1 つのテーブルにデータが多すぎるという問題は解決されますが、テーブルを異なるマシン上のデータベースに分散させることはできません。したがって、MySQL データベースへの負荷を軽減するのにはあまり役立ちません。誰もが同じ物理マシンの CPU、メモリ、ネットワーク IO を奪い合っています。データベースとテーブルを分割してこの問題を解決するのが最適です。

水平シャーディングの利点:

単一データベースの過剰なデータ量と高い同時実行性によるパフォーマンスのボトルネックがないため、システムの安定性と負荷容量が向上します。
アプリケーション側の変換は比較的小さく、ビジネスモジュールを分割する必要がない。

欠点:

シャード間のトランザクションの一貫性を確保することは困難である
データベース間の結合クエリのパフォーマンスが低い
複数のデータ拡張の難しさとメンテナンスは非常に大きい

水平シャーディング後、同じテーブルが複数のデータベース/テーブルに表示され、各データベース/テーブルの内容は異なります。一般的なデータシャーディングルールは次のとおりです。

2.1 数値範囲に応じて

時間間隔または ID 間隔で除算します。たとえば、異なる月や日のデータを日付ごとに異なるデータベースに分散します。userId が 1 ～ 9999 のレコードを最初のデータベースに分散し、userId が 10000 ～ 20000 のレコードを 2 番目のデータベースに分散します。ある意味では、一部のシステムで使用されている「コールドデータとホットデータの分離」も同様の手法です。これは、あまり使用されていない履歴データを他のデータベースに移行し、ビジネス機能ではホットデータに対してのみクエリを実行するものです。

これには次のような利点があります。

単一のテーブルサイズは制御可能
当然、水平方向に拡張するのは簡単です。後からシャードクラスター全体を拡張したい場合、他のシャードからデータを移行せずにノードを追加するだけで済みます。
範囲検索にシャードフィールドを使用すると、連続シャードは高速クエリのためにシャードをすばやく見つけることができるため、シャード間のクエリの問題を効果的に回避できます。

欠点:

ホットデータはパフォーマンスのボトルネックになります。継続的なシャーディングでは、データのホットスポットが発生する可能性があります。たとえば、時間フィールドでシャーディングする場合、一部のシャードには、頻繁に読み書きされる可能性のある最新の期間のデータが保存されますが、一部のシャードには、ほとんどクエリされない履歴データが格納されます。

2.2 値による剰余

一般的には、ハッシュ係数分割法が使用されます。たとえば、Customer テーブルは、cusno フィールドに従って 4 つのデータベースに分割されます。余りが 0 のデータは最初のデータベースに配置され、余りが 1 のデータは 2 番目のデータベースに配置されます。この方法では、同じユーザーのデータが同じデータベースに分散されます。クエリ条件に cusno フィールドが含まれている場合、クエリに対応するデータベースを明確に見つけることができます。

アドバンテージ：

データシャーディングは比較的均一であり、ホットスポットや同時アクセスのボトルネックが発生する可能性は低い

欠点:

後でシャードクラスタを拡張する場合、古いデータを移行する必要があります（一貫性のあるハッシュアルゴリズムを使用すると、この問題をより適切に回避できます）
クロスシャードクエリの複雑な問題に直面するのは簡単です。例えば、上記の例で、よく使われるクエリ条件にcusnoが含まれていない場合、データベースが見つからないため、4つのデータベースに対して同時にクエリを開始し、メモリ上でデータをマージして、最小限のセットをアプリケーションに返す必要があり、データベースシャーディングが負担になります。