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

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

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

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

データベース・アーキテクチャ

[編集]

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

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

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

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

水平分割との比較

[編集]

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

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

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

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

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

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

実装

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

短所

[編集]

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

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

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

語源

[編集]

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

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

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

注釈

[編集]
  1. ^ Typically 'supporting' data such as dimension tables

脚注

[編集]
  1. ^ a b Sadalage, Pramod J.; Fowler, Martin (2012). “4: Distribution Models”. NoSQL Distilled. ISBN 978-0321826626 
  2. ^ Rahul Roy (July 28, 2008). “Shard - A Database Design”. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  3. ^ Ries, Eric. “Sharding for Startups”. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  4. ^ Wang, Gang; Shi, Zhijie Jerry; Nixon, Mark; Han, Song (21 October 2019). “SoK: Sharding on Blockchain”. AFT '19: Proceedings of the 1st ACM Conference on Advances in Financial Technologies: 41–61. doi:10.1145/3318041.3355457. ISBN 9781450367325. https://dl.acm.org/doi/abs/10.1145/3318041.3355457. 
  5. ^ Yu, Mingchao; Sahraei, Saeid; Nixon, Mark; Han, Song (18 July 2020). “Coded Merkle Tree: Solving Data Availability Attacks in Blockchains”. FC 2020: Financial Cryptography and Data Security: 114–134. doi:10.1145/3318041.3355457. ISBN 9781450367325. https://dl.acm.org/doi/abs/10.1145/3318041.3355457. 
  6. ^ “Apache HBase – Apache HBase™ Home”. hbase.apache.org. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  7. ^ “Introducing Elastic Scale preview for Azure SQL Database”. azure.microsoft.com. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  8. ^ “Alibaba Cloud Help Center - Cloud Definition and Explanation of Cloud Based Services - Alibaba Cloud”. www.alibabacloud.com. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  9. ^ “Focuses on Large-Scale Online Databases - Alibaba Cloud”. www.alibabacloud.com. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  10. ^ “Index Shard Allocation | Elasticsearch Guide [7.13 | Elastic]”. www.elastic.co. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  11. ^ “IBM Docs”. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  12. ^ “Hibernate Shards” (2007年2月8日). Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  13. ^ “Hibernate Shards”. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  14. ^ “New Grid queries for Informix”. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  15. ^ “NoSQL support in Informix (JSON storage, Mongo DB API)” (September 24, 2013). Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  16. ^ “Spider”. MariaDB KnowledgeBase. 2022年12月20日閲覧。
  17. ^ “MonetDB July2015 Released” (31 August 2015). Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  18. ^ “MySQL Cluster Features & Benefits” (2012年11月23日). Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  19. ^ “MySQL Fabric sharding quick start guide”. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  20. ^ “Oracle Sharding”. Oracle (2018年5月24日). 2021年7月10日閲覧。
  21. ^ “DistributedSearch - SOLR - Apache Software Foundation”. cwiki.apache.org. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  22. ^ “Spanner: Google's Globally-Distributed Database”. Proceedings of OSDI 2012. 24 February 2014閲覧。
  23. ^ “sqlalchemy/sqlalchemy” (July 9, 2021). Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  24. ^ “Partitioning and Sharding Options for SQL Server and SQL Azure”. infoq.com. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  25. ^ “A faster, more efficient cryptocurrency”. MIT News. 2019年1月30日閲覧。
  26. ^ “Vitess”. vitess.io. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  27. ^ “ShardingSphere”. shardingsphere.apache.org. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  28. ^ Sarin, DeWitt & Rosenberg, Overview of SHARD: A System for Highly Available Replicated Data, Technical Report CCA-88-01, Computer Corporation of America, May 1988
  29. ^ “Database "sharding" came from UO?”. Raph Koster's Website (2009年1月8日). 2015年1月17日閲覧。
  30. ^ a b c “Ultima Online: The Virtual Ecology | War Stories”. Ars Technica Videos. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。
  31. ^ “データベース用語の「シャーディング」はMMORPGの「ウルティマオンライン」が由来かもしれない”. GIGAZINE (2023年4月15日). 2023年6月14日閲覧。

関連項目

[編集]

外部リンク

[編集]