シャード (データベース・アーキテクチャ)

 
データベース・シャード (database shard、または単にシャード(shard)) は、データベースまたは検索エンジン内のデータの水平分割(パーティショニング)である。
負荷を分散するために、各シャードは別個ののインスタンスに保持される。
データベース内の一部のデータはすべてのシャードに存在するが、一部のデータは1つのシャードにのみ表示される。各シャード(またはサーバー)は、このデータのサブセットの"単一"ソースとして機能する。
データベース・アーキテクチャ.
水平分割は、データベース・テーブルの行を(程度は異なるが、正規化と垂直分割で行われる)列に分割するのではなく、個別に保持するデータベース設計方針である。各分割はシャードの一部を形成し、それは別々のデータベース・サーバーまたは物理的な場所に配置される場合がある。
水平分割アプローチには多くの利点がある。テーブルが複数のサーバーに分割されて分散されるため、各データベースの各テーブルの行の合計数が減らされる。これによりインデックス・サイズが削減され、一般に検索パフォーマンスが向上する。データベース・シャードは別々のハードウェアに配置でき、複数のシャードを複数のマシンに配置できる。これにより多数のマシン上にデータベースを分散できるようになり、パフォーマンスが大幅に向上する。加えて、データベース・シャードが現実世界のデータのセグメント化に基づいている場合（例: ヨーロッパの顧客とアメリカの顧客）、適切なシャード・メンバーシップを簡単かつ自動的に推測し、関連するシャードのみをクエリすることが可能になる場合がある。
実際には、シャーディングは複雑である。これは長い間手作業でコーディングされてきたが (特に上記の例のように、行が明確にグループ化されている場合)、柔軟性に欠けることがよくある。シャーディングをサポートするコードの追加と、個別にシャーディングされる候補の識別の両方の観点から、シャーディングを自動的にサポートしたいという要望がある。コンシステントハッシュ法は複数の小規模なサービスとサーバーにわたって大きな負荷を分散させるためシャーディングで用いられるテクニックである。
分散コンピューティングを使用して複数のサーバー間で負荷を分散する場合 (パフォーマンスまたは信頼性の理由のいずれか)、シャード・アプローチも役立つ場合があるかもしれない。2010年代には、(より伝統的なのシャーディングと同様に)実行能力のシャーディングは、ブロックチェーンのパフォーマンスとスケーラビリティの問題を克服するための潜在的なアプローチとして浮上した。
水平分割との比較.
水平分割では、通常はスキーマとデータベース・サーバーの"単一" インスタンス内で1つ以上のテーブルが行ごとに分割される。 最初にインデックスを検索する必要がなく、特定の行がどのパーティションで見つかるかを識別する明確で堅牢で暗黙的な方法があれば、インデックス・サイズ(したがって検索労力)を削減することで利点が得られる可能性があるかもしれない、たとえば「codice_1」テーブルと「codice_2」テーブルの典型的な例では、ZIPコード(郵便番号)によってすでに所在地が示されている。
シャーディングはこれを超える: 問題のあるテーブルを同じ方法で分割するが、これは場合によってはスキーマの"複数" のインスタンスにわたって行われる。明らかな利点は大規模な分割テーブルの検索負荷を、同じ論理サーバー上の複数のインデックスだけでなく、複数の(論理または物理)サーバーに分散できることである。
複数の分離されたインスタンスにシャードを分割するには、単純な水平分割以上のものを要求する。単にを取得するためだけに、データベースをクエリすることは、クエリするにあたって"複数" のインスタンスを要求される場合、期待されていた効率の向上は失われる。分割を超え、シャーディングはしたがって分割可能な大きなテーブルをサーバー全体に分割する一方、より小さなテーブルは完全なユニットとして複製される。
これがシャーディングがシェアード=ナッシング・アーキテクチャに関連している理由でもあり—一度シャード化されると、各シャードは完全に別個の論理スキーマ・インスタンス、物理データベース サーバー、データセンター、大陸に存在できる。他のシャード内の他の分割されていないテーブルへの(シャード間からの)共有アクセスを継続的に保持する必要はない。
これは複数のサーバー間でのレプリケーション(複製)を容易にする(単純な水平分割はこの限りではない)。またデータセンター間の通信リンクがボトルネックとなるアプリケーションの世界規模の配布にも役立つ。
分割されていないテーブルがアプリケーションの要求に応じて厳密に同期された状態が維持されるために、何らかのスキーマ・インスタンス間の通知および複製メカニズムも必要である。これは、シャード・システムのアーキテクチャにおける複雑な選択である: アプローチは、これらを実質的に読み取り専用にする(更新はまれでバッチ処理される)ものから、テーブルを動的にレプリケートする(シャーディングによる分散の利点の一部を犠牲にする)、およびその間の多くのオプションまで多岐にわたる。
短所.
ローカルで最適化される前にデータベース・テーブルをシャーディングすると、複雑さが早まる原因となる。シャーディングは最適化のための他のすべてのオプションが不適切な場合にのみ使用すべし。データベース・シャーディングの複雑さにより、次の潜在的な問題が発生する:
これらDIYシャーディングの歴史的な複雑さは自動シャーディングを提供する独立系ソフトウェア・ベンダーによって対処された。
語源.
データベースのコンテキストでは、「シャード」という用語は2つのソースのいずれかに由来する可能性が高いとほとんどの人が認識している: の 「A System for Highly Available Replicated Data」、これは(水平分割とは対照的に)データの"複製" を容易にするため冗長ハードウェアを利用した; または8つのギネス世界記録を樹立し、"タイム誌"によって史上最も偉大なビデオ・ゲーム100の1つに指定され、高い評価を得た1997年のMMORPGビデオ・ゲーム、"ウルティマ・オンライン"もある。
リチャード・ギャリオット("ウルティマ・オンライン" の作者)は製作段階中に彼らが、プレイヤーが新しいインターネット・アクセス(当時としては革新的なテクノロジー)を活用して、ゲーム内リソースを操作したり収集したりできる自己調整型の仮想生態系システムを作成しようとしたとき、造語された用語を回想している。仮想生態系は社内テスト中は意図したとおりに機能していたが、プレイヤーがスポーン"・"システムが動作するよりも早く、プレイ可能なエリア全体で生きている野生生物をすべて殺したために、その自然のバランスは「ほぼ瞬時に」崩れた。ギャリオットの制作チームは、グローバル"・"プレイヤー"・"ベースを個別のセッションに分離することで、この問題を軽減しようとし、そしての終わりへの"ウルティマ・オンライン" の架空のつながりの一部を書き換え、そこでは敵対者の敗北もマルチバース「シャード」の作成につながった。この修正によりギャリオット氏のチームは仮想環境のコピーの作成を正当化するために必要な架空の根拠を得ることができた。しかしながら、このゲームが急速に批評家からの評価を高めたことは、新しい多世界仮想生態システムもすぐに圧倒されてしまうことを意味した。数か月にわたるテストの後、ギャリオット氏のチームはこの機能を完全に放棄することを決定し、そしてゲームのその機能を取り除いた。
今日、「シャード」という用語は、データベース"・"システム全体での冗長ハードウェアの展開と使用を指す。