1. データシャーディングの概念
データベースのシャーディングとは、大規模なデータベースを複数の小さなデータベースに分割することを指し、それぞれの小さなデータベースはシャードと呼ばれます。このようにして、データベースの負荷を複数のサーバーに分散できるため、パフォーマンスのボトルネックと可用性が改善されます。
データ シャーディングの中核となる方法は、リレーショナル データベースとテーブルを分離することです。サブデータベースとサブテーブルの両方で、許容しきい値を超えるデータ量によって引き起こされるクエリのボトルネックを効果的に回避できます。さらに、サブデータベースを使用して、データ ノードへの単一ポイント アクセスを効率的に分散することもできます (考えてみて、注文をチェックする人は注文ノードに行き、ユーザーをチェックする人はユーザー ノードに行きます)。
サブテーブルはデータ ノードへの負担を軽減することはできませんが、分散トランザクションをローカル トランザクションに変換するために可能な限り多くの処理を提供できます。データベース間の更新操作が関与すると、分散トランザクションによって問題が複雑になることがよくあります (たとえば、ユーザーが注文するなど)その時は減点して在庫を減らすだけでポット一杯飲める）。
マスター/スレーブ シャーディング方式を使用すると、データの単一点を効果的に回避できるため、データ アーキテクチャの可用性が向上します (更新操作はマスター ノードに送信され、クエリ操作はスレーブ ノードに送信されます)。
これは、データをサブデータベースとサブテーブルに分割して各テーブルのデータ量をしきい値以下に保ち、トラフィックをチャネル化して大量のアクセス量に対処することで、同時実行性が高く大規模なデータ システムに対処する効果的な手段です。
シャーディングはいつ使用する必要がありますか?
シャード データベース アーキテクチャを実装する必要があるかどうかは、ほとんどの場合議論の対象になります。データベースが一定のサイズに達すると、シャーディングは避けられない結果であると考える人もいます。シャーディングによって運用が複雑になるため、これは頭の痛い問題であり、絶対に必要な場合を除いては避けるべきだと考える人もいます。
- (1) 大規模データの処理: データ量の急速な増加は、現代のアプリケーションではよくある状況です。データ量が単一サーバーの容量制限に達した場合、シャーディングはアプリケーションが大規模なデータを処理し、データを複数のノードに分散してクラスター リソースを最大限に活用するのに役立ちます。
- (2 ) 読み取りおよび書き込みパフォーマンスの向上: 断片化により負荷を複数のノードに分散できるため、データベースの読み取りおよび書き込みパフォーマンスが向上します。各シャードはデータの一部を独立して処理し、個々のノードの負荷を軽減し、クエリとトランザクションの並列処理を可能にします。
(3 ) スケーラビリティの向上: 断片化により、データベースの容量とスループットを需要に応じて拡張できます。データ量が増加した場合、個々のノードのハードウェアまたはソフトウェアをアップグレードする代わりに、単純にシャード ノードを追加できます。
(4 ) 単一障害点の削減: シャーディングは複数のノードにデータを分散することで、単一ノードの障害によるシステム全体への影響を軽減できます。ノードに障害が発生しても、他のノードは引き続き使用できるため、システムの可用性と耐障害性が確保されます。
( 5 ) 地理的位置の柔軟性の提供: 断片化により、地理的位置に応じてデータを保存できます。これにより、アプリケーションがデータ ストレージのコンプライアンス要件を満たし、データ アクセスの待ち時間を短縮することができます。
2.1 断片化の原理
2.1.1 垂直シャーディング
1. 原則
事業分割の方法によれば、それは垂直シャーディングと呼ばれ、垂直分割とも呼ばれ、専用のデータベースを意味します（会社の各部門の意味に似ており、それぞれが独自の職務を実行します）。分割前のデータ ノードは複数のビジネス テーブルで構成され、各テーブルには異なるビジネス データが格納されます。分割後、業務に応じてテーブルを分類し、異なるデータノードに分散することで、異なるデータノードへの負担を分散します。たとえば、ユーザーに関連するものはユーザー ライブラリに配置され、注文に関連するものは注文ライブラリに配置されます。
垂直シャーディングでは、アーキテクチャと設計を調整する必要があります。一般的に、インターネットビジネスのニーズの急激な変化（ダブルイレブンの注文急増など）に対応するには遅すぎ、また、単一点のボトルネックを根本的に解決することはできません。垂直分割はデータ量やアクセス量に起因する問題を軽減することはできますが、解決することはできません。垂直分割後もテーブル内のデータ量が単一ノードが保持できるしきい値を超えている場合は、さらなる処理のために水平シャーディングが必要になります。
2. 特長
(1) 各ライブラリ（テーブル）の構造が異なります。
(2) 各ライブラリ (テーブル) 内のデータの少なくとも 1 つの列が同じです (複数のライブラリまたはテーブルを関連付けるサブデータベースまたはサブテーブルの後の少なくとも 1 つのフィールドが同じです)。
(3) 各ライブラリ (テーブル) の和集合がデータの全量になります。
3. 利点
(1) 分割後の事業が明確であること（倉庫への移転の場合は事業に応じて分割する）。
(2) 動的と静的な分離、コールドとホットのデータ分離設計の実施形態を実現します。コールド ストレージはアクセスが少ないデータを指し、ホット ストレージはアクセスが多いデータを指します。
(3) データの保守が簡単で、業務ごとに異なるマシンにデータを配置します。
4. デメリット
(1) ビジネス要件の急速な変化に対応できない。
(2) 一部のビジネスを関連付けることができず、データベース間のクエリの問題が発生します。
2.1.2 水平シャーディング
1. 原則
水平シャーディングは水平分割とも呼ばれます (企業が日常業務を処理するためにさまざまな都市にさまざまな支店を設立するのと同じです)。垂直シャーディングと比較すると、ビジネス ロジックに従ってデータを分類するのではなく、特定のフィールド (または複数のフィールド) を通じて特定のルールに従ってデータを複数のノードまたはテーブルに分散し、各シャードにはデータの一部のみが含まれます。たとえば、主キー シャーディングによれば、偶数の主キーを持つレコードは 0 ライブラリ (またはテーブル) に配置され、奇数の主キーを持つレコードは 1 ライブラリ (またはテーブル) に配置されます。
水平シャーディングは理論的には単一マシンのデータ量処理のボトルネックを突破し、比較的自由に拡張できるため、サブデータベースとサブテーブルの標準ソリューションです。
2. 特長
(1) 各ライブラリ (テーブル) の原理は同じです。
(2) 各ライブラリ（テーブル）のデータは異なります。
(3) 各ライブラリ (テーブル) の和集合がデータの全量になります。
3. 利点
(1) 単一のデータベース (テーブル) のデータが一定量に保持されるため、パフォーマンスの向上に役立ちます。
(2) システムの安定性と耐荷重性を向上させます。
（３）分割ライブラリ（テーブル）の構造は同一であり、プログラムの修正が少ない。
4. デメリット
（１）データの拡張が非常に難しく、メンテナンス量が多く、分割ルールの抽象化が難しい。
2.1.3 データの断片化によって引き起こされる問題
シャーディングやシャーディング後にデータが散在する中で、開発エンジニアやデータベース管理者がデータベースに対して複雑な操作を行うことが重要な課題の 1 つです。彼らは、特定のデータベースのどのテーブルからデータを取得する必要があるかを知る必要があります。考えてみれば、私たちは皆同じ場所で働いており、その気になれば張三や李斯に電話するのは簡単ですが、今は全員が北と南に割り当てられているため、意思疎通が不便です。
(1) データの集計
単一ノード データベースで正しく実行できる SQL は、断片化されたデータベースでは必ずしも正しく実行できるとは限りません。たとえば、テーブルを分割すると、テーブル名の変更や、ページング、並べ替え、集計、グループ化などの操作の誤った処理が発生します。たとえば、順序テーブルの最初の 10 個のデータをクエリしたい場合、前に 1 つの SQL ステートメントが必要でしたが、今度は別のデータが取得されます。この時点でクエリのページングを考えていると、ノードがクラッシュします。
(2) 分散トランザクション
テーブル分割戦略を使用して、テーブル内のデータ量を減らしながらローカル トランザクションを使用するようにしてください。これは、クロスデータベース トランザクションの問題を回避するために、すべてのトランザクションが 1 つのデータ ノードの下にあるためです。
クロスデータベース トランザクションが避けられないシナリオでは、一部の企業は依然としてトランザクションの一貫性を確保する必要があります。同時実行性の高いシナリオにおける XA ベースの分散トランザクションのパフォーマンスはニーズを満たすことができません。ほとんどの企業では、強力なトランザクションではなく結果整合性を備えた柔軟なトランザクションが使用されています。一貫した取引。
2.2 断片化ミドルウェア
2.2.1 JDBC アプリケーション層の断片化
プロキシと比較すると、そのパフォーマンスは強力ですが、言語がjavaに制限されるため、大きな制限が生じます。
1、sharding-jdbc（shardingsphere）
2.2.2 プロキシ プロキシ層の断片化
言語制限なし！
1、マイキャット
2、mysql-プロキシ
2.3 断片化アルゴリズム
2.3.1 範囲
アイデア: ユーザー センターのビジネス主キー uid に基づいて、データを 2 つのデータベース インスタンスに水平方向に分割します。
db_1: 0 ～ 1000 万の uid データを保存します。
db_2: 1,000 万から 2,000 万の uid データを保存します。
(1) レンジアルゴリズムのメリット
- セグメンテーション戦略はシンプルで、ID とスコープに従って、データがどのデータベースにあるかをすぐに特定できます。
- 拡張は簡単です。容量が足りない場合は、db_3 を追加するだけです。
(2) レンジアルゴリズムの不備
- id は増分機能を満たす必要があります。
- データ量は不均一であり、新しく追加された db_3 の初期段階ではデータが少なくなります。
- リクエストの量は不均一であり、一般に、新しく登録されたユーザーのアクティビティは比較的高いため、db_2 の負荷が db_1 よりも高くなることが多く、サーバー使用率が不均衡になります。
2.3.2 ハッシュ
アイデア: ユーザー センターのビジネス主キー uid に基づいて、データを 2 つのデータベース インスタンスに水平方向に分割します。
db_1: ID が 1 を法とする ID データを格納します。
db_0: ID がモジュロ 0 である ID データを格納します。
(1) ハッシュアルゴリズムのメリット
- セグメンテーション戦略はシンプルで、uid とハッシュに基づいて、データがどのデータベースに存在するかをすぐに特定できます。
- データ量のバランスが取れているため、uid が均一である限り、各データベース上のデータの分散のバランスが取れている必要があります。
- uid が均一である限り、リクエスト量のバランスが取れており、各ライブラリの負荷分散のバランスが取れている必要があります。
(2) ハッシュアルゴリズムの不備
- 拡張が面倒、容量が足りないとライブラリ追加や再ハッシュでデータ移行になる可能性がある、データ移行をいかにスムーズに行うかが解決すべき課題
2.3.3 インデックステーブル
アイデア: ID はデータベースに直接見つけることができますが、データをデータベースに直接見つけることはできません。ID を使用してデータベースにクエリを実行できれば、問題は解決します。
解決策:
(1) id -> db のマッピング関係を記録するインデックス テーブルを作成します。
(2) ID を使用してアクセスする場合は、まずインデックス テーブルを通じて ID をクエリし、次に対応するライブラリを見つけます。
(3) インデックス テーブルは属性が少なく、多くのデータを収容でき、通常はデータベースに分割する必要がありません。
(4) データ量が多すぎる場合は、データベースを ID ごとに分割できます。
利点: ノードの拡張は効果がありません。
潜在的な欠点: データベース クエリが 1 つ多くなり、パフォーマンスが 2 倍になります。
2.4 断片化の実現
シャーディングの有効化には、データベース スキーマの設計、デプロイメント構成、アプリケーションの変更など、多くの側面が関係します。一般にシャーディングを有効にする手順は次のとおりです。
(1) シャーディング戦略の設計: まず、範囲ベース、ハッシュ、リストベースの方法など、アプリケーションに適したシャーディング戦略を決定する必要があります。アプリケーション要件とデータ特性に基づいて適切なシャーディング戦略を選択し、シャーディング キーの選択を検討してください。
(2) データベース アーキテクチャの設計: シャーディング戦略に従ってデータベースの全体的なアーキテクチャを設計します。シャードの数とノード サイズに加えて、データの関連付け方法とシャード間のデータ ルーティング ルールを決定します。
(3) 物理サーバーの導入: データベース アーキテクチャに従って物理サーバーを設計、導入、構成します。各ノードに十分なコンピューティング リソースとストレージ リソースがあることを確認するには、各シャードを独立した物理ノードまたはサーバーに割り当てる必要があります。
(4) データベース シャーディングの初期化: 各シャーディング ノード上にデータベース インスタンスを作成し、シャーディング戦略に従って初期化します。対応するテーブル構造、インデックス、制約などを作成して、各シャード ノードのデータベース構造が一貫していることを確認します。
(5) データ移行: 既存のデータをシャード クラスターに移行します。データはシャーディング戦略に従って分割され、各シャードにインポートされ、データの一貫性と整合性が確保されます。これには、データのエクスポート、変換、インポートのプロセスが含まれる場合があります。
(6) アプリケーションの変更: シャーディング アーキテクチャに適応できるようにアプリケーション コードを変更します。データベース接続構成を更新して、アプリケーションが適切にルーティングしてさまざまなシャードにアクセスできるようにします。さらに、クエリ ステートメント、トランザクション処理、およびデータ アクセス ロジックを、シャーディング環境に適応するように変更する必要があります。
(7) 負荷分散とルーティングの構成: 断片化されたクラスター内でリクエストが均等に分散されるように、負荷分散とルーティングのメカニズムを構成します。これは、ロード バランサーまたはプロキシを介してリクエストを適切なシャード ノードにルーティングすることで実現できます。
(8) テストと監視: シャーディング環境に対して包括的なテストを実施し、シャーディング戦略の正確さとパフォーマンスを確認します。各シャード ノードの実行ステータスとパフォーマンス インジケーターをリアルタイムで監視する監視システムをセットアップします。
シャーディングの有効化は、アプリケーション要件、データ特性、システム アーキテクチャを包括的に考慮する必要がある複雑なプロセスであることに注意してください。シャーディングの前に、シャーディングの適切な実装と運用保守を確保するために、十分な計画と評価を行うことをお勧めします。同時に、データ移行の複雑さとシステムアップグレードの課題も考慮する必要があります。