1. 背景
単一ノードにデータを一元的に保存する従来のソリューションでは、パフォーマンス、可用性、運用および保守コストの観点から、大量のデータのシナリオに対応することが困難でした。
パフォーマンスの面では、ほとんどのリレーショナル データベースはB+ツリー、データ量がしきい値を超えると、インデックスの深さが増加IOすることでディスク アクセス数も増加し、クエリ パフォーマンスの低下につながります。同時に、アクセス要求の同時実行性が高いため、集中データベースがシステムの最大のボトルネックになります。
可用性の観点から見ると、サービスのステートレスな性質により、少ないコストでランダムな拡張を実現できますが、これは必然的にデータベースに対するシステムの最終的な圧力につながります。そして、単一のデータ ノード、つまり単純なマスター/スレーブ アーキテクチャを購入するのがますます難しくなってきています。データベースの可用性がシステム全体の鍵となっています。
運用保守コストの観点から見ると、データベース インスタンス内のデータがしきい値を超えると、運用保守DBAへの増大します。データのサイズが大きくなると、データのバックアップとリカバリにかかる時間コストはますます制御できなくなります。一般に、単一データベース インスタンスのデータしきい値は1TB以内で、これは妥当な範囲です。
従来のリレーショナル データベースがインターネット シナリオのニーズを満たすことができない場合、データをネイティブ分散データベースに保存するNoSQL試み。NoSQLしかし、SQLエコシステムとの非互換性と不完全さにより、リレーショナル データベースでゲームの致命的な打撃を完了することは不可能ですが、リレーショナル データベースの地位は依然として揺るぎません。
2. データの断片化
データ シャーディングとは、パフォーマンスのボトルネックと可用性を改善するために、単一のデータベースに格納されているデータを特定のディメンションに従って複数のデータベースまたはテーブルに分散することを指します。
データ シャーディングの効果的な手段は、データベースとリレーショナル データベースのテーブルをシャーディングすることです。サブデータベースとサブテーブルの両方で、許容しきい値を超えるデータ量によって引き起こされるクエリのボトルネックを効果的に回避できます。
さらに、サブデータベースを使用して、データベースの単一ポイントへのアクセスを効果的に分散することもできます。サブテーブルはデータベースへの負担を軽減できませんが、分散トランザクションをローカル トランザクションに変換する可能性を提供します。ライブラリの更新操作や分散トランザクションにより、問題が複雑になることがよくあります。
マルチマスターおよびマルチスレーブのシャーディング方法を使用すると、データのシングルポイントを効果的に回避できるため、データ アーキテクチャの可用性が向上します。
これは、データをサブデータベースとサブテーブルに分割して各テーブルのデータ量をしきい値以下に保ち、トラフィックをチャネル化して大量のアクセス量に対処することで、同時実行性が高く大規模なデータ システムに対処する効果的な手段です。
データ シャーディングは、垂直シャーディングと水平シャーディングに分類できます。
2.1 垂直シャーディング
事業分割の方法に応じて、垂直シャーディング (垂直分割とも呼ばれます) と呼ばれ、その中心となる概念は専用データベースに特化しています。分割前のデータベースは複数のデータ テーブルで構成されており、各テーブルは異なるビジネスに対応しています。分割後、テーブルは業務に応じて分類され、異なるデータベースに分散されるため、異なるデータベースへの負担が分散されます。
次の図は、ビジネス ニーズに応じてユーザー テーブルと注文テーブルを異なるデータベースに垂直にシャーディングするスキームを示しています。
垂直シャーディングでは、多くの場合、アーキテクチャと設計の調整が必要になります。一般に、インターネット ビジネス要件の急速な変化に対応するには遅すぎますし、単一点のボトルネックを実際に解決することもできません。垂直分割はデータ量やアクセス量に起因する問題を軽減することはできますが、解決することはできません。垂直分割後もテーブル内のデータ量が単一ノードが保持できるしきい値を超えている場合は、さらなる処理のために水平シャーディングが必要になります。
2.2 水平シャーディング
水平シャーディングは水平分割とも呼ばれます。垂直シャーディングと比較すると、ビジネス ロジックに従ってデータを分類するのではなく、特定のフィールド (または複数のフィールド) を通じて特定のルールに従ってデータを複数のライブラリまたはテーブルに分散し、各シャードにはデータの一部のみが含まれます。たとえば、次のように、主キー シャーディングによれば、偶数主キーのレコードは 0 ライブラリ (またはテーブル) に配置され、奇数主キーのレコードは 1 ライブラリ (またはテーブル) に配置されます。次の図。
水平シャーディングは理論的には単一マシンのデータ処理のボトルネックを突破し、比較的自由に拡張できる、データ シャーディングの標準ソリューションです。
3. チャレンジ
データシャーディングはパフォーマンス、可用性、シングルポイントバックアップとリカバリなどの問題を解決しますが、分散アーキテクチャは利点を得る一方で新たな問題も引き起こします。
このように断片化されて分散したデータに直面すると、アプリケーション開発エンジニアやデータベース管理者のデータベースに対する操作が非常に重くなることが重要な課題の1つです。彼らは、データを取得する必要がある特定のデータベースのサブテーブルを知る必要があります。
もう 1 つの課題は、単一ノード データベースで正しく実行できるものが、SQL断片化されたデータベースでは必ずしも正しく動作するとは限らないことです。たとえば、テーブルを分割すると、テーブル名が変更されたり、ページネーション、並べ替え、集計グループ化などの操作が正しく処理されなくなったりします。
クロスデータベース トランザクションも、分散データベース クラスターが直面しなければならない難しい問題です。サブテーブルを合理的に使用すると、単一テーブル内のデータ量を削減しながらローカル トランザクションを最大限に使用でき、同じデータベース内の異なるテーブルを上手に使用することで、分散トランザクションによって引き起こされる問題を効果的に回避できます。
データベース間のトランザクションが避けられないシナリオでも、一部の企業は依然としてトランザクションの一貫性を維持する必要があります。ただし、分散トランザクションXAに、同時実行性の高いシナリオのニーズを満たすパフォーマンスが得られず、大手インターネット企業では大規模に使用されておらず、ほとんどの企業では、強力な一貫性のあるトランザクションではなく、結果整合性のある柔軟なトランザクションが使用されています。