MySQL でよく使用されるデータベースとテーブルシャーディングソリューションの概要

1. データベースのボトルネック

IO ボトルネックであろうと CPU ボトルネックであろうと、最終的にはデータベースのアクティブ接続数が増加し、データベースが処理できるアクティブ接続数のしきい値に近づいたり、さらには到達したりします。ビジネスサービスの観点から見ると、利用可能なデータベース接続はほとんどないか、まったくありません。次に何が起こるかは想像がつきます (同時実行性、スループット、クラッシュ)。

1. IOボトルネック

最初のタイプ: ディスク読み取り IO ボトルネック。ホットデータが多すぎるため、データベースキャッシュに保存できません。各クエリで大量の IO が生成され、クエリ速度が低下します -> シャーディングと垂直シャーディング。

2 番目のタイプ: ネットワーク IO ボトルネック、要求されるデータが多すぎる、ネットワーク帯域幅が不十分 -> シャーディング。

2. CPUボトルネック

1 つ目のタイプ: SQL の問題。たとえば、SQL に join、group by、order by、非インデックスフィールド条件クエリなどが含まれる場合、CPU 計算操作が増加します -> SQL の最適化、適切なインデックスの確立、ビジネスサービスレイヤーでのビジネス計算の実行など。

2 番目のタイプ: 単一テーブル内のデータ量が大きすぎるため、クエリ中にスキャンされる行数が多すぎて、SQL 効率が低く、CPU が最初のボトルネックになる -> 水平テーブルパーティション分割。

2. サブライブラリとサブテーブル

1. 水平データベース

概念:フィールドと特定の戦略 (ハッシュ、範囲など) に基づいて、1 つのデータベース内のデータを複数のデータベースに分割します。

結果：

各ライブラリの構造は同じです。
各データベースのデータは異なり、重複はありません。
すべてのライブラリを結合したものが完全なデータです。

シナリオ:システムの絶対的な同時実行性が増加し、テーブルシャーディングでは根本的な問題の解決が困難です。また、データベースを垂直にシャーディングするための明確な業務提携がありません。

分析:ライブラリが増えると、IO と CPU への負荷が飛躍的に軽減されます。

2. 横長テーブル

概念:フィールドと特定の戦略 (ハッシュ、範囲など) に基づいて、1 つのテーブル内のデータを複数のテーブルに分割します。

結果：

各テーブルの構造は同じです。
各テーブルのデータは異なり、共通部分はありません。
すべてのテーブルを結合したものが完全なデータです。

シナリオ:システムの絶対的な同時実行性は向上していませんが、単一テーブル内のデータ量が大きすぎるため、SQL の効率に影響し、CPU の負荷が増加してボトルネックになります。推奨: SQLクエリ最適化の原則の分析

分析：テーブル内のデータ量が削減され、単一のSQL実行の効率が高くなり、CPUへの負担が自然に軽減されます。

3. 垂直サブデータベース

概念:テーブルに基づいて、さまざまなビジネス属性に応じてさまざまなテーブルが異なるデータベースに分割されます。

結果：

各ライブラリの構造は異なります。
各データベースのデータも異なり、共通部分はありません。
すべてのライブラリを結合したものが完全なデータです。

シナリオ:システムの絶対的な同時実行性が向上し、個別のビジネスモジュールを抽象化できるようになりました。

分析:この時点で、基本的にサービスに変えることができます。

たとえば、ビジネスが発展するにつれて、公開されている構成テーブルや辞書テーブルが増えていきます。このとき、これらのテーブルを別のライブラリに分離したり、サービス化したりすることもできます。さらに、ビジネスが発展し、一連のビジネスモデルが開発されると、関連するテーブルを個別のデータベースに分離したり、サービスに変換したりすることもできます。

4. 縦型テーブル

概念:フィールドに基づき、フィールドのアクティビティに応じて、テーブル内のフィールドは異なるテーブル (メインテーブルと拡張テーブル) に分割されます。

結果：

各テーブルの構造は異なります。
各テーブルのデータも異なります。一般的に、各テーブルのフィールドには少なくとも 1 つの交差する列 (通常は主キー) があり、これを使用してデータを関連付けます。
すべてのテーブルを結合したものが完全なデータです。

シナリオ:システムの絶対的な同時実行性は向上していません。テーブルにはレコードは多くありませんが、フィールドは多くあります。ホットデータと非ホットデータが一緒に保存されるため、1 行のデータに必要なストレージスペースが大きくなります。その結果、データベースキャッシュ内のデータ行数が減少し、クエリ中にディスクデータを読み取るときに大量のランダム読み取り IO が生成され、IO ボトルネックが発生します。

分析:リストページと詳細ページを使用して理解を深めることができます。垂直テーブル分割の原則は、ホットデータ (冗長性があり、一緒にクエリされることが多いデータ) をメインテーブルとしてまとめ、非ホットデータを拡張テーブルとしてまとめることです。この方法では、より多くのホットデータをキャッシュできるため、ランダム読み取り IO が削減されます。分割後、すべてのデータを取得するには、2 つのテーブルを結合してデータを取得する必要があります。

ただし、結合は CPU の負荷を増やすだけでなく、2 つのテーブルを結合してしまうため (1 つのデータベースインスタンス上に存在する必要があります)、結合は絶対に使用しないでください。関連データについては、ビジネスサービスレイヤーで作業し、メインテーブルと拡張テーブルのデータを個別に取得し、関連フィールドを使用して関連付けることですべてのデータを取得する必要があります。

3. ライブラリとテーブルシャーディングツール

sharding-sphere: jar、以前は sharding-jdbc;
TDDL: jar、Taobao 分散データレイヤー。
Mycat: ミドルウェア。

注意: 公式ウェブサイトとコミュニティを優先し、ツールの長所と短所を自分で調べてください。

4. データベースとテーブルを分割する手順

容量 (現在の容量と増加) に基づいてシャードまたはテーブルの数を評価 -> キーを選択 (均等に) -> テーブルシャーディングルール (ハッシュまたは範囲など) -> 実行 (通常は二重書き込み) -> 容量拡張の問題 (データの移動を最小限に抑える)。

5. シャーディングの問題

1. 非パーティションキークエリの問題

水平データベースとテーブルシャーディングに基づく分割戦略は、一般的に使用されるハッシュ方式です。

パーティションキーに加えて、クエリの条件としてクライアント上にはパーティション以外のキーが1つだけあります。

マッピング方法

遺伝学的方法

注: 書き込み時に、図に示すように、user_id は遺伝的手法によって生成されます。例えば、x ビット遺伝子については、8 つのテーブルに分割すると、23=8 なので、x は 3 となり、3 ビット遺伝子となります。 user_id に基づいてクエリを実行する場合、モジュールは対応するサブライブラリまたはサブテーブルに直接ルーティングできます。
user_name に基づいてクエリを実行する場合は、まず user_name_code 生成関数を使用して user_name_code を生成し、次に係数を取得して対応するサブライブラリまたはサブテーブルにルーティングします。 ID 生成によく使用される Snowflake アルゴリズム。

パーティションキーに加えて、クライアントのクエリの条件として複数の非パーティションキーがあります。

マッピング方法

冗長化方式

注: order_id または buyer_id でクエリを実行する場合、クエリは db_o_buyer データベースにルーティングされます。seller_id でクエリを実行する場合、クエリは db_o_seller データベースにルーティングされます。ちょっと本末転倒な気がしますね！他に良い方法はあるでしょうか？テクノロジースタックを変更するのはどうでしょうか?

パーティションキーに加えて、バックグラウンドにはさまざまな非パーティションキーの組み合わせ条件クエリもあります。

NoSQLアプローチ