# シェアードナッシング ## 定義 シェアードナッシング（Shared-Nothing）アーキテクチャとは、各プロセッサが専用のプライベートメモリと専用ディスクを保有し、プロセッサ間の通信は高速インターコネクトネットワークのみを通じて行う並列コンピュータ設計である。[[David DeWitt]] と [[Jim Gray]] が [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]]（CACM 1992）において、シェアードメモリ・シェアードディスクとの対比で定式化した。論文が引用する Stonebraker [29] が命名した。各ノードが「何も共有しない（nothing shared）」ことにより、共有リソースへの干渉（interference）を最小化し、数百〜数千プロセッサへの線形スケールを可能にする。 各プロセッサはリモートデータへアクセスする際、そのデータを管理するプロセッサへメッセージを送り、フィルタリング済みデータのみを受け取る。生のディスクアクセスはローカルで行われ、ネットワーク上を流れるのは「絞り込まれた（reduced）データ」のみである。 代表的商用実装: Teradata（1978〜）・Tandem NonStop SQL・nCUBE。研究システム: Gamma・Arbre・Bubba。 --- ## 3 アーキテクチャの比較 | アーキテクチャ | メモリ | ディスク | スケーラビリティ（1992 年時点） | |---|---|---|---| | シェアードメモリ | 共有 | 共有 | 〜32 プロセッサが上限 | | シェアードディスク | 専用 | 共有 | 数千ディスク・プロセッサへ理論拡張可能だが共有アクセス時にページ競合 | | **シェアードナッシング** | **専用** | **専用** | **数百〜数千プロセッサへの線形スケール実証済み** | シェアードメモリは干渉が少なくコーディングが容易だが、グローバルメモリのバンド幅が全プロセッサの帯域幅の合計を満たす必要があり、インターコネクト設計が極めて困難。シェアードディスクは読み取り専用 DB と更新競合のない用途では有効だが、書き込みがあるとキャッシュフラッシュとページ交換でネットワークを逼迫させる。 --- ## 横断的知見 - **シェアードナッシングはクラウド分散データベースの設計原理として 30 年後も支配的**: DeWitt/Gray が 1992 年に商業的勝者と断言したシェアードナッシングは、Bigtable（2006）・Dynamo（2007）・Cassandra（2010）・Snowflake・BigQuery のいずれも採用する。特に Cassandra は DeWitt/Gray の論文が実装例として挙げた Dynamo 型ハッシュパーティショニングと Bigtable 型データモデルを融合した。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]], [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]], [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]) - **シェアードナッシングはソフトウェアの複雑さをハードウェアの単純さと交換する**: 論文は「shared-nothing architectures actually simplify the software implementation」と断言した。SQL の標準化（ANSI/ISO）のおかげで、ユニプロセッサ向けの SQL アプリケーションをシェアードナッシングマシン上でそのまま並列実行できる。これは shared-memory / shared-disk での再設計コストと対照的。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]]) - **Aurora Limitless のシャード設計はシェアードナッシングの直接の後継**: [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] のルータ/シャード分離・シャード間 2PC は、DeWitt/Gray が定義したシェアードナッシング上の分散 OLTP の現代実装である。ただし DeWitt/Gray はオブジェクトストレージ（S3 等）によるコンピュート・ストレージ分離を想定していなかった点が大きな差異。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]], [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]) - **Grosch の法則の崩壊がシェアードナッシング普及の物理的条件だった**: DeWitt/Gray はコモディティ CPU ($250/MIPS) と RAM ($100/MB) の低価格化が Grosch の法則（大型計算機ほど費用対効果が高い）を無効化したと論じた。現代のクラウドでは GPU/AI アクセラレータが同様のコモディティ化過程にある。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]]) ## 未解決の問い - **オブジェクトストレージ層とのシェアード関係をどう分類するか**: クラウドネイティブ DB（Snowflake・Aurora Limitless 等）は各コンピュートノードが専用メモリを持つが、ストレージは S3 等のオブジェクトストアを「共有」する。DeWitt/Gray の 3 分類では「シェアードディスク」に当たるが、ページ競合ではなく HTTP API 経由のオブジェクト単位アクセスであり干渉の性質が異なる。新しいカテゴリが必要か - **シェアードナッシングと RDMA の組合せ**: [[RDMA]] を採用した高速ネットワーク（InfiniBand・RoCE）はシェアードナッシングの「メッセージパッシングのみ」という前提を変える。CPU を介さないリモートメモリ直接アクセスはシェアードメモリとシェアードナッシングの境界を曖昧にするか ## 関連 - ソース: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]] - 概念: [[並列データベース]] / [[データパーティショニング]] / [[専用データベースシステム]] / [[分散ストレージ]] / [[RDMA]] / [[分散 PostgreSQL]] - エンティティ: [[David DeWitt]] / [[Jim Gray]] / [[Teradata]] / [[Tandem Computers]] / [[University of Wisconsin]] ## 出典 - [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]]（シェアードナッシングを並列 DB アーキテクチャとして体系的に論じた原典。Teradata・Tandem・Gamma の比較を含む）