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

データベース・シャード (database shard、または単にシャード(shard)) は、データベースまたは検索エンジン内のデータの水平分割(パーティショニング)である。

負荷を分散するために、各シャードは別個のen:データベース・サーバーのインスタンスに保持される。

データベース内の一部のデータはすべてのシャードに存在するが、一部のデータは1つのシャードにのみ表示される。各シャード(またはサーバー)は、このデータのサブセットの単一ソースとして機能する。

データベース・アーキテクチャ水平分割は、データベース・テーブルの行を(程度は異なるが、正規化と垂直分割で行われる)列に分割するのではなく、個別に保持するデータベース設計方針である。各分割はシャードの一部を形成し、それは別々のデータベース・サーバーまたは物理的な場所に配置される場合がある。

水平分割アプローチには多くの利点がある。テーブルが複数のサーバーに分割されて分散されるため、各データベースの各テーブルの行の合計数が減らされる。これによりインデックス・サイズが削減され、一般に検索パフォーマンスが向上する。データベース・シャードは別々のハードウェアに配置でき、複数のシャードを複数のマシンに配置できる。これにより多数のマシン上にデータベースを分散できるようになり、パフォーマンスが大幅に向上する。加えて、データベース・シャードが現実世界のデータのセグメント化に基づいている場合（例: ヨーロッパの顧客とアメリカの顧客）、適切なシャード・メンバーシップを簡単かつ自動的に推測し、関連するシャードのみをクエリすることが可能になる場合がある。

実際には、シャーディングは複雑である。これは長い間手作業でコーディングされてきたが (特に上記の例のように、行が明確にグループ化されている場合)、柔軟性に欠けることがよくある。シャーディングをサポートするコードの追加と、個別にシャーディングされる候補の識別の両方の観点から、シャーディングを自動的にサポートしたいという要望がある。コンシステントハッシュ法は複数の小規模なサービスとサーバーにわたって大きな負荷を分散させるためシャーディングで用いられるテクニックである。

分散コンピューティングを使用して複数のサーバー間で負荷を分散する場合 (パフォーマンスまたは信頼性の理由のいずれか)、シャード・アプローチも役立つ場合があるかもしれない。2010年代には、(より伝統的なデータのシャーディングと同様に)実行能力のシャーディングは、ブロックチェーンのパフォーマンスとスケーラビリティの問題を克服するための潜在的なアプローチとして浮上した。

水平分割との比較水平分割では、通常はスキーマとデータベース・サーバーの単一インスタンス内で1つ以上のテーブルが行ごとに分割される。最初にインデックスを検索する必要がなく、特定の行がどのパーティションで見つかるかを識別する明確で堅牢で暗黙的な方法があれば、インデックス・サイズ(したがって検索労力)を削減することで利点が得られる可能性があるかもしれない、たとえば「CustomersEast」テーブルと「CustomersWest」テーブルの典型的な例では、ZIPコード(郵便番号)によってすでに所在地が示されている。

シャーディングはこれを超える: 問題のあるテーブルを同じ方法で分割するが、これは場合によってはスキーマの複数のインスタンスにわたって行われる。明らかな利点は大規模な分割テーブルの検索負荷を、同じ論理サーバー上の複数のインデックスだけでなく、複数の(論理または物理)サーバーに分散できることである。

複数の分離されたインスタンスにシャードを分割するには、単純な水平分割以上のものを要求する。単にen:ディメンション・テーブルを取得するためだけに、データベースをクエリすることは、クエリするにあたって複数のインスタンスを要求される場合、期待されていた効率の向上は失われる。分割を超え、シャーディングはしたがって分割可能な大きなテーブルをサーバー全体に分割する一方、より小さなテーブルは完全なユニットとして複製される。

これがシャーディングがシェアード=ナッシング・アーキテクチャに関連している理由でもあり—一度シャード化されると、各シャードは完全に別個の論理スキーマ・インスタンス、物理データベースサーバー、データセンター、大陸に存在できる。他のシャード内の他の分割されていないテーブルへの(シャード間からの)共有アクセスを継続的に保持する必要はない。

これは複数のサーバー間でのレプリケーション(複製)を容易にする(単純な水平分割はこの限りではない)。またデータセンター間の通信リンクがボトルネックとなるアプリケーションの世界規模の配布にも役立つ。

分割されていないテーブルがアプリケーションの要求に応じて厳密に同期された状態が維持されるために、何らかのスキーマ・インスタンス間の通知および複製メカニズムも必要である。これは、シャード・システムのアーキテクチャにおける複雑な選択である: アプローチは、これらを実質的に読み取り専用にする(更新はまれでバッチ処理される)ものから、テーブルを動的にレプリケートする(シャーディングによる分散の利点の一部を犠牲にする)、およびその間の多くのオプションまで多岐にわたる。

実装

はクライアント・アプリケーションに対して透過的な、結合された(クライアント側とサーバー側)シャーディング・アーキテクチャを提供する。 Apache HBaseは自動的にシャードできる。 Azure SQL Database Elastic Database ツールのシャードは、アプリケーションのデータ層をスケールアウトおよびスケールインする。は、高速なオープンソースのOLAPデータベース管理システム、シャードする。は自動的かつ透過的にシャードする。 CUBRIDはバージョン9.0からシャードする。 Db2 データ分割機能 (MPP) は、個別のノードで実行されるシェアード=ナッシング・データベース分割である。 Alibaba CloudのDRDS(Distributed Relational Database Service)はデータベース/テーブル・シャーディングをし、そして光棍節(独身の日)をサポートする。 Elasticsearch エンタープライズ・サーチ・サーバーはシャードする。 eXtreme Scaleはクロスプロセスのインメモリ・キーバリュー(データ)ストア (NoSQLデータストア)。データとMapReduceスタイルの並列処理の両方をプロセス間でシャーディングを使用してスケーラビリティを実現する。 Hibernateはシャードする、しかし2007年以降はほとんど発展していない。 IBM Informixはバージョン12.1 xC1から、MACH11テクノロジーの一部としてシャードする。Informix 12.10 xC2はMongoDBドライバーとの完全な互換性が追加され、通常のリレーショナル・テーブルとNoSQLコレクションを混在させることができ、シャーディング、フェイルオーバー、ACIDプロパティも引き続き可能。 Kdb+はバージョン2.0からシャードする。 MariaDB Spiderは、テーブルフェデレーション、テーブルシャーディング、XAトランザクション、ODBCデータソースをサポートするストレージエンジン。 MariaDB Spiderエンジンはバージョン10.0.4以降、MariaDBサーバーにバンドルされている。 MonetDBは(オープンソースの列ストア)は、2015年7月のリリースで読み取り専用シャーディングをするようになった。 MongoDBはバージョン1.6からシャードする。 :en:MySQL Clusterは低コストのコモディティ・ノード間で自動的かつ透過的にシャードするため、アプリケーションを変更することなく、読み取りおよび書き込みクエリのスケールアウトが可能になる。 MySQL Fabric (MySQLユーティリティの一部)はシャードする。 Oracle Databaseは12c Release 2からずっとシャードする: シャーディングの利点と、エンタープライズ対応のマルチモデル Oracle Database のよく知られた機能を組み合わせたもの。 :en:Oracle NoSQL Databaseは自動シャーディングとエラスティック、クラスターのオンライン拡張(シャードの追加)機能を備える。 OrientDBはバージョン1.7からシャードする。 Solr エンタープライズ・サーチ・サーバーはシャードする。 Spanner(Googleの世界規模の分散データベース)は、「数百のデータセンターにわたる数百万台のマシンと数兆のデータベース行」に拡張するため複数のPaxosステートマシンにまたがってシャードする。 SQLAlchemy ORMは、シャードするPythonプログラミング言語用のデータマッパー。 SQL Serverは、SQL Server 2005からサードパーティツールの助けを借りてシャードする。 Teradataは大規模な並列データベース管理システムを「」として販売 Vault(暗号通貨)はユーザーがネットワークに参加してトランザクションを確認する必要があるデータを大幅に削減するためにシャードする。これによりネットワークをさらに拡張できるようになる。 Vitess オープンソースのデータベース・クラスタリング・システムはMySQLをシャードする。これはCloud Native Computing Foundationプロジェクトである。 ShardingSphereは、データ・シャーディング、分散トランザクション、分散データベース管理を提供するデータベース・クラスタリング・システムに関連していた。これは、Apache Software Foundation (ASF) プロジェクトである。

短所ローカルで最適化される前にデータベース・テーブルをシャーディングすると、複雑さが早まる原因となる。シャーディングは最適化のための他のすべてのオプションが不適切な場合にのみ使用すべし。データベース・シャーディングの複雑さにより、次の潜在的な問題が発生する:

SQLの複雑さ - 開発者はシャーディング・ロジックを処理するためにより複雑なSQLを記述する必要があるため、バグが増加する追加のソフトウェア - 分割、バランス、調整を行い、失敗する可能性のある整合性を保証する単一障害点 - ネットワーク/ハードウェア/システムの問題による1つのシャードの破損は、テーブル全体の障害を引き起こす。フェイルオーバー・サーバーの複雑さ - フェールオーバー・サーバーには、データベース・シャードのコピーが必要。バックアップの複雑さ - 個々のシャードのデータベース・バックアップは、他のシャードのバックアップと調整する必要がある。運用の複雑さ - インデックスの追加/削除、列の追加/削除、スキーマの変更は非常に困難になる。

これらDIYシャーディングの歴史的な複雑さは自動シャーディングを提供する独立系ソフトウェア・ベンダーによって対処された。

語源データベースのコンテキストでは、「シャード」という用語は2つのソースのいずれかに由来する可能性が高いとほとんどの人が認識している: :en:Computer Corporation of Americaの「A System for Highly Available Replicated Data」Sarin, DeWitt & Rosenberg, Overview of SHARD: A System for Highly Available Replicated Data, Technical Report CCA-88-01, Computer Corporation of America, May 1988、これは(水平分割とは対照的に)データの複製を容易にするため冗長ハードウェアを利用した; または8つのギネス世界記録を樹立し、タイム誌によって史上最も偉大なビデオ・ゲーム100の1つに指定され、高い評価を得た1997年のMMORPGビデオ・ゲーム、ウルティマ・オンラインもある。

リチャード・ギャリオット(ウルティマ・オンラインの作者)は製作段階中に彼らが、プレイヤーが新しいインターネット・アクセス(当時としては革新的なテクノロジー)を活用して、ゲーム内リソースを操作したり収集したりできる自己調整型の仮想生態系システムを作成しようとしたとき、造語された用語を回想している。仮想生態系は社内テスト中は意図したとおりに機能していたが、プレイヤーがスポーン・システムが動作するよりも早く、プレイ可能なエリア全体で生きている野生生物をすべて殺したために、その自然のバランスは「ほぼ瞬時に」崩れた。ギャリオットの制作チームは、グローバル・プレイヤー・ベースを個別のセッションに分離することで、この問題を軽減しようとし、そしての終わりへのウルティマ・オンラインの架空のつながりの一部を書き換え、そこでは敵対者en:モンデインの敗北もマルチバース「シャード」の作成につながった。この修正によりギャリオット氏のチームは仮想環境のコピーの作成を正当化するために必要な架空の根拠を得ることができた。しかしながら、このゲームが急速に批評家からの評価を高めたことは、新しい多世界仮想生態システムもすぐに圧倒されてしまうことを意味した。数か月にわたるテストの後、ギャリオット氏のチームはこの機能を完全に放棄することを決定し、そしてゲームのその機能を取り除いた。

今日、「シャード」という用語は、データベース・システム全体での冗長ハードウェアの展開と使用を指す。

注釈

脚注

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

Źródło i licencja