シャード (データベース・アーキテクチャ)
ローカルで最適化される前にデータベース・テーブルをシャーディングすると、複雑さが早まる原因となる。シャーディングは最適化のための他のすべてのオプションが不適切な場合にのみ使用すべしTemplate:According to whom。データベース・シャーディングの複雑さにより、次の潜在的な問題が発生する:
SQLの複雑さ - 開発者はシャーディング・ロジックを処理するためにより複雑なSQLを記述する必要があるため、バグが増加する
追加のソフトウェア - 分割、バランス、調整を行い、失敗する可能性のある整合性を保証する
単一障害点 - ネットワーク/ハードウェア/システムの問題による1つのシャードの破損は、テーブル全体の障害を引き起こす。
フェイルオーバー・サーバーの複雑さ - フェールオーバー・サーバーには、データベース・シャードのコピーが必要。
バックアップの複雑さ - 個々のシャードのデータベース・バックアップは、他のシャードのバックアップと調整する必要がある。
運用の複雑さ - インデックスの追加/削除、列の追加/削除、スキーマの変更は非常に困難になる。
これらDIYシャーディングの歴史的な複雑さは自動シャーディングを提供する独立系ソフトウェア・ベンダーによって対処された。
分割を超え、シャーディングはしたがって分割可能な大きなテーブルをサーバー全体に分割する一方、より小さなテーブルは完全なユニットとして複製される。
これがシャーディングがシェアード=ナッシング・アーキテクチャに関連している理由でもあり—一度シャード化されると、各シャードは完全に別個の論理スキーマ・インスタンス、物理データベース サーバー、データセンター、大陸に存在できる。他のシャード内の他の分割されていないテーブルへの(シャード間からの)共有アクセスを継続的に保持する必要はない。
これは複数のサーバー間でのレプリケーション(複製)を容易にする(単純な水平分割はこの限りではない)。またデータセンター間の通信リンクがボトルネックとなるアプリケーションの世界規模の配布にも役立つ。
分割されていないテーブルがアプリケーションの要求に応じて厳密に同期された状態が維持されるために、何らかのスキーマ・インスタンス間の通知および複製メカニズムも必要である。これは、シャード・システムのアーキテクチャにおける複雑な選択である: アプローチは、これらを実質的に読み取り専用にする(更新はまれでバッチ処理される)ものから、テーブルを動的にレプリケートする(シャーディングによる分散の利点の一部を犠牲にする)、およびその間の多くのオプションまで多岐にわたる。
ALTIBASE(英語版)はクライアント・アプリケーションに対して透過的な、結合された(クライアント側とサーバー側)シャーディング・アーキテクチャを提供する。
Apache HBaseは自動的にシャードできる。
Azure SQL Database Elastic Database ツールのシャードは、アプリケーションのデータ層をスケールアウトおよびスケールインする。
ClickHouse(英語版)は、高速なオープンソースのOLAPデータベース管理システム、シャードする。
Couchbase(英語版)は自動的かつ透過的にシャードする。
CUBRIDはバージョン9.0からシャードする。
Db2 データ分割機能 (MPP) は、個別のノードで実行されるシェアード=ナッシング・データベース分割である。
Alibaba CloudのDRDS(Distributed Relational Database Service)はデータベース/テーブル・シャーディングをし、そして光棍節(独身の日)をサポートする。
Elasticsearch エンタープライズ・サーチ・サーバーはシャードする。
eXtreme Scaleはクロスプロセスのインメモリ・キーバリュー(データ)ストア (NoSQLデータストア)。データとMapReduceスタイルの並列処理の両方をプロセス間でシャーディングを使用してスケーラビリティを実現する。
Hibernateはシャードする、しかし2007年以降はほとんど発展していない。
IBM Informixはバージョン12.