# 分散ストレージ ## 定義 分散ストレージ（distributed storage）とは、複数のコモディティサーバにまたがってデータを格納・管理するシステムの総称である。単一マシンの容量・帯域・可用性の限界を超え、ペタバイトからエクサバイト規模のデータを水平スケーリングで取り扱う。データモデル（リレーショナル、キー値、多次元マップなど）、整合性保証、分散・レプリケーション戦略、障害耐性、運用モデルの設計がシステムごとに大きく異なる。(Source: [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]) ## 横断的知見 - **長寿命の分散ストレージは中核モデルを保ち、周辺機構で時代要求へ適応する**: 2006 年 Bigtable は多次元疎マップ、タブレット、SSTable/メムテーブル、単一行 ACID を提示した。2026 年の Bigtable 経験論文では、この中核はほぼ維持されつつ、レプリケーション、SQL、CDC、CRDT、マテリアライズドビュー、外部コンパクション、行キャッシュ、オートサイジングが追加された。これは「最初から完全な汎用 DBMS を作る」のではなく、制約の明確な中核を長期運用の中で拡張する設計パターンである。(Source: [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]) - **分散ストレージのスケーラビリティ課題はデータ分割からメタデータ・位置特定・運用分離へ移る**: 2006 年論文はタブレット分割と三階層位置特定を中心に設計を説明したが、20 年後の論文ではタブレット数爆発、位置キャッシュの冷え、メタデータホットスポット、マスタのロック競合、ファイルガベージコレクションの直列性、リバランサの副作用が主要課題として扱われる。規模拡大後の律速は「データを分けられるか」だけでなく「分けたものをどう安く管理するか」に移る。(Source: [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]) - **運用モデルは分散ストレージのアーキテクチャ要素である**: Bigtable は当初ユーザーが運用する想定だったが、2006 年半ば以降は Bigtable SRE チームが全社サービスとして運用するモデルへ移った。標準サーバ形状、メタデータ専用パーティション、プローバ、既定バックアップ、オートサイジングは、単なる運用手順でなくシステムの可用性・性能予測可能性を支える構成要素になっている。(Source: [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]) - **Raft を採用した分散ストレージでは、コンセンサスログが異常検知の無償データ源になる**: [[RBAD]]([[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]])は、Apache IoTDB・Alluxio において監視データ（収集でスループット -23.79%）やアプリログ（-55.37%）の代わりに、システムの正常動作に不可欠な Raft ログ（収集コスト -1.3%）を異常診断の入力とすることで、F1-Score 92–94% を達成した。これは分散ストレージの運用において「コンセンサスアルゴリズムの副産物を活用する」という新しい設計軸を開く。DB-Engine ランキング上位の大半（TiDB・Apache IoTDB・OceanBase・Google Spanner 等）が Raft または Paxos 系を採用しているため、この手法の適用範囲は広い。(Source: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]) - **ディスアグリゲートされた分散ストレージでは、ネットワークがストレージエンジンの一部になる**: Bigtable 系の知見はデータモデル、タブレット、メタデータ、サービス運用の長期進化を示す。一方、[[Azure Storage]] の RDMA 展開は、計算クラスタとストレージクラスタを分離したクラウドストレージでは、TCP/IP 処理の CPU 予約やリージョン内 RTT 差がストレージ性能・コストを直接支配することを示す。分散ストレージの設計対象は、データ配置や整合性だけでなく、ストレージ通信のトランスポート、輻輳制御、NIC/スイッチ更新、診断テレメトリまで広がる。(Source: [[@2026__SIGMOD Companion__Twenty Years of Bigtable]], [[@2023__NSDI__Empowering Azure Storage with RDMA]]) - **OLTP 向けの専用ストレージサービスは、汎用分散ストレージとは異なりログ処理の責任を担う**: Bigtable・Azure Storage が汎用ブロック/テーブルストレージとして設計されるのに対し、Aurora の分散ストレージサービスは RDBMS の Redo ログアプライヤを内包し、データページをバックグラウンド生成する。これにより「ログがデータベース」という抽象化が成立し、OLTP エンジンとストレージの間でやり取りするデータ量を大幅に削減できる（ページではなくログレコードのみ）。目的特化型ストレージはより深い最適化が可能だが、汎用性を失う。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) ## 未解決の問い - Bigtable のタブレットベース動的分割と、他の分散ストレージシステム（Dynamo の一貫性ハッシュ法など）のパーティショニング手法はどのような条件下で優劣が分かれるか。 - Bigtable が採用した Chubby への集中依存と、完全非集中のメンバーシップ管理（ゴシッププロトコルなど）は可用性・運用複雑性のトレードオフでどう評価されるか。 - NoSQL 系システムが時間とともに SQL・CDC・マテリアライズドビューを取り込むとき、中核の単純さとユーザー操作性の境界はどこに置くべきか。 - 単一行トランザクションのみの制約は、セカンダリインデックスやクロステーブル整合性が必要なアプリケーションでどう回避されたか。 - Bigtable のような全社サービス運用モデルは、オープンソース分散ストレージやマルチテナントクラウド DB でどこまで再現可能か。 - 分散ストレージが RDMA に依存するとき、通常時に節約した CPU コアと、TCP フェイルオーバー時に必要になる予備 CPU コアの容量計画をどう両立するか。([[@2023__NSDI__Empowering Azure Storage with RDMA]]) ## 関連 - ソース: [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] / [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] / [[@2023__NSDI__Empowering Azure Storage with RDMA]] - エンティティ: [[Bigtable]] / [[Google File System]] / [[Chubby]] / [[Google]] / [[Jeffrey Dean]] / [[Sanjay Ghemawat]] / [[Azure Storage]] - 関連 MOC: [[Systems for ML - MOC]] ## 出典 - [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] - [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] - [[@2023__NSDI__Empowering Azure Storage with RDMA]] - [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]（OLTP 向け専用ストレージとログ処理移譲）