コンテキスト
単一のデータノードに集中的にデータを保存するという従来のソリューションでは、パフォーマンス、可用性、運用・保守コストの面で、インターネットの膨大なデータシナリオに対応することは困難でした。
性能の面では、ほとんどのリレーショナル・データベースはB+ツリー型インデックスを使用しているため、インデックスの深さが深くなると、データ量が閾値を超えたときにディスクアクセスのためのIO数が増加し、クエリ性能の低下につながります。
可用性の面では、サービタイゼーションの無状態性、任意の拡張の小さなコストを達成する能力、必然的にシステム上の究極の圧力につながるデータベースの上にあります。そして、単一のデータ・ノード、あるいは単純なマスター・スレーブ・アーキテクチャは、ますます耐え難くなっています。データベースの可用性は、システム全体の鍵になっています。
O&Mコストの面では、データベース・インスタンス内のデータがある閾値を超えると、DBAにかかるO&Mプレッシャーが増大します。データのバックアップとリカバリの両方の時間コストは、データ量が大きくなるにつれて制御不能になります。一般的に、1つのデータベースインスタンス内のデータの閾値は1TB以内であり、これはより合理的な範囲です。
従来のリレーショナル・データベースがインターネット・シナリオのニーズを満たせない場合、分散をネイティブにサポートするNoSQLにデータを格納する試みが増えています。しかし、NoSQLはSQLとの相性が悪く、エコシステムも不完全なため、リレーショナルデータベースとの勝負で致命的な打撃を与えることはできず、リレーショナルデータベースの地位は揺るがないままです。
データ・シャーディングとは、パフォーマンスのボトルネックや可用性を改善するために、1つのデータベースに格納されているデータを、ある次元に従って複数のデータベースやテーブルに分散させることを指します。データシャーディングの効果的な手段は、リレーショナルデータベースをライブラリとテーブルに分割することです。リポジトリとテーブルの両方を使用することで、データ量が許容しきい値を超えることによるクエリのボトルネックを回避することができます。また、リポジトリはデータベースの1点へのアクセスを効果的に分散させるために使用することができます。テーブルはデータベースへの圧力を軽減することはできませんが、分散トランザクションを可能な限りローカルトランザクションに変換する可能性を提供することができます。マルチマスターマルチスレーブシャーディングの使用は、効果的にデータの特異性を回避することができ、その結果、データアーキテクチャの可用性を向上させることができます。
ライブラリやテーブル単位でデータを分割し、各テーブルのデータ量を閾値以下に抑えるとともに、トラフィックをチャネリングして大量のアクセスに対応することは、高い同時実行性と巨大なデータシステムに対処する有効な手段です。データスライシングは垂直スライシングと水平スライシングに分けられます。
垂直スライス
事業別の分割は垂直スライシングと呼ばれ、垂直分割とも呼ばれます。分割では、データベースは複数のデータテーブルで構成され、それぞれが異なるビジネスに対応します。そして分割後、テーブルをビジネスに応じて分類し、異なるデータベースに分散させることで、異なるデータベースに圧力を分散させます。次の図は、ユーザーテーブルと注文テーブルを、ビジネスニーズに応じて異なるデータベースに縦割りするシナリオを示しています。
バーティカル・スライシングは、多くの場合、アーキテクチャや設計の調整を必要とします。一般的に言って、インターネットビジネス要件の急速な変化に対応するには遅すぎます。垂直分割は、データ量やアクセス量に起因する問題を緩和することはできますが、解決することはできません。垂直分割後もテーブル内のデータ量が1つのノードで処理できる閾値を超える場合は、水平スライシングによる処理が必要になります。
水平スライス
水平スライシングは水平分割とも呼ばれます。垂直スライシングに関連して、それはもはやビジネスロジックに従ってデータを分類しませんが、特定のフィールドを介して、複数のライブラリまたはテーブルにデータを広めるためにいくつかのルールに従って、各スライスは、データの一部のみが含まれています。例：主キーのスライスによると、次の図に示すように、0ライブラリに主キーのレコードの偶数、1ライブラリに主キーのレコードの奇数、。
水平スライシングは、理論的にはシングルマシンのデータ量処理のボトルネックを打破し、拡張は比較的自由で、ライブラリとテーブルのための標準的なソリューションです。
挑戦
データシャーディングはパフォーマンス、可用性、シングルポイントバックアップリカバリーの問題を解決しますが、分散アーキテクチャは利点と同時に新たな問題を引き起こします。
アプリケーション開発エンジニアやデータベース管理者は、断片化されたデータベースを扱わなければならないため、どこからデータを取得するかを知る必要があります。具体的にどのデータベーステーブルからデータを取得する必要があるのかを知る必要があるのです。
もう1つの課題は、シングルノード・データベースでは正しく動作するSQLが、シャーディング後のデータベースでは必ずしも正しく動作しないことです。たとえば、テーブルのシャーディングによってテーブル名が変更されたり、ページング、ソート、集約グループ化などの操作が正しく処理されなかったりします。
分散データベースクラスタにとって、クロスデータベーストランザクションも厄介な問題です。分割テーブルを合理的に使用することで、1つのテーブル内のデータ量を削減し、ローカルトランザクションを使用するようにし、同じライブラリ内の異なるテーブルをうまく使用することで、分散トランザクションによるトラブルを効果的に回避することができます。クロスライブラリトランザクションを避けられない場合でも、トランザクションの一貫性を維持する必要があるビジネスもあります。XAベースの分散トランザクションは、インターネット大手が大規模に使用することはありません。その理由は、高い同時実行性のシナリオではパフォーマンスがニーズを満たすことができないためであり、そのほとんどが強力な一貫性のあるトランザクションの代わりに柔軟なトランザクションの究極の一貫性を使用しています。
目的
ShardingSphere Data Sharding モジュールの主な設計目標は、シャーディングの影響を可能な限り透過的にし、ユーザが水平方向にシャーディングされたデータベース・クラスタを単一のデータベースと同じように使用できるようにすることです。
