# 並列データベース ## 定義 並列データベース（Parallel Database System）とは、複数のプロセッサ・ディスク・メモリを協調させてリレーショナルデータベースの処理を高速化するデータベース管理システムである。[[David DeWitt]] と [[Jim Gray]] が [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]]（CACM 1992）で体系化した概念であり、リレーショナルモデルの**均一データストリーム**という特性が演算子を自然に並列化可能にするという洞察に基づく。並列化の形態として**パイプライン並列化**（演算子連鎖による並列）と**パーティション並列化**（データ分割による複製演算子の同時実行）の 2 種がある。後者がより大きなスピードアップとスケールアップの機会を提供する。 ## 横断的知見 - **シェアードナッシングが 1992 年に既に事実上の勝者と判定されていた**: DeWitt と Gray は 3 種アーキテクチャ（シェアードメモリ・シェアードディスク・シェアードナッシング）を比較し、シェアードメモリは 32 プロセッサ程度が上限・シェアードディスクはページ交換でネットワーク逼迫、と結論した。30 年後の分散データベース（Bigtable・Dynamo・BigQuery・Snowflake）がいずれもシェアードナッシングを採用している事実と一致する。(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]]) - **スケールアップ指標はクラウドデータベース時代の設計目標と直結する**: 1992 年の「N 倍ハードウェアで N 倍大きな問題を同じ時間で」というスケールアップ定義は、現代の Aurora Limitless Database（[[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]）のスケールアウト OLTP 設計目標と本質的に同一である。30 年の技術進歩にもかかわらず測定の軸は変わっていない。(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]]) - **startup/interference/skew の 3 脅威はクラウドスケール分散システムにも適用される**: 1992 年に定式化された線形スピードアップを阻む 3 要因は、GPU 分散訓練のストラグラー問題（skew）・RDMA ネットワーク輻輳（interference）・ジョブ起動オーバーヘッド（startup）として現代システムでも再現する。語彙は同一で対象が変わった。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]]) - **並列リレーショナル演算子は 2023 年の Monarch スケール監視 DB にも受け継がれる**: Adams+ VLDB 2020 の Monarch は、並列 SQL クエリによるプラネットスケール集約を設計の柱としており、DeWitt/Gray が示した「均一演算子の自然な並列化」の延長線上にある。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]]) - **ウェブ検索エンジンの多段サービス木(serving tree)アーキテクチャが、DeWitt/Gray の想定しなかった第三の並列化手段として集計クエリに応用された**: DeWitt/Grayが1992年に定式化したパイプライン並列化・パーティション並列化はいずれもリレーショナル演算子の並列実行を対象とするのに対し、[[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]]はウェブ検索の多段サービス木の概念(クエリを木構造に沿って下位へ押し下げ、各段で書き換えて再帰的に集約する)をDB集計クエリの実行に転用した。数千ノード規模で線形に近いスケーラビリティ(Figure 13: ノード数を1000→4000に増やしても総CPU時間はほぼ一定のままユーザー体感時間がほぼ線形に減少)を実証しており、DeWitt/Grayが並列DBMSの理論的上限として想定した規模を大きく超える実データでの検証例となっている。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]], [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]]) - **DeWitt/Gray のパイプライン並列化・パーティション並列化の分類が、34 年後の単一プロセス組み込み DBMS の演算子レベル実装として具体化される**: DuckDB の[[プッシュ型パイプライン実行]]は「パイプライン」という単位の中に両形態を統合する。パイプライン内の演算子連鎖自体がパイプライン並列化に相当し、各スレッドが独立にパイプラインインスタンスを走らせ(ソースが行を分割し各スレッドが担当分を処理する)点がパーティション並列化に相当する。1992 年の分類は複数ノードにまたがる分散 DBMS を主眼に体系化されたが、単一プロセス・単一マシン内のマルチコア並列にも同じ語彙がそのまま適用できる。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]], [[@2026__DiDi__Query Execution Plans and Pipelining]]) - **skew(歪み)への対処方針が、複雑な負荷分散ロジックの実装ではなく設計上の選択という形で現れる**: DeWitt/Gray が定式化した startup/interference/skew の 3 脅威のうち skew について、DuckDB の DiDi #06 は「独立パイプラインの並列実行はパイプライン間の作業量差やキャッシュ局所性低下を招くため、1 本のパイプラインへより多くのコアを投入する方が有利」という設計判断を示す。これは 1992 年の抽象的な脅威分類が、実装レベルでは「歪みを検知して動的に負荷分散する」のではなく「歪みが生じにくい実行モデルを選ぶ」という保守的な解法に落ち着いた一例である。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]], [[@2026__DiDi__Query Execution Plans and Pipelining]]) - **クラウドネイティブなコンピュート・ストレージ分離は、シェアードナッシングの弱点表とほぼ一致する動機から生まれた**: [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]] が挙げるシェアードナッシングの4課題（ヘテロジニアスなワークロード・メンバーシップ変更・オンラインアップグレード・クラウドでの常態的なノード障害）は、DeWitt/Gray が1992年に想定した「小さく静的なオンプレクラスタ」では軽微だが、クラウドでは深刻化する。DeWitt/Gray の理論的枠組み自体は不変のまま、実行環境の変化（オンプレ→クラウド）が新アーキテクチャを要請した例である。(Source: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]], [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]]) ## 未解決の問い - **バッチ OLTP 混在問題は 30 年後にどう解決されたか**: DeWitt/Gray が 1992 年時点で未解決とした「大規模分析クエリとリアルタイム OLTP の同時実行」は HTAP（Hybrid Transactional/Analytical Processing）として現在も研究が続く。Aurora Limitless はこの課題をどの程度解決しているか - **クラウドネイティブ分離アーキテクチャの正式なカテゴリ分類は未確定**: Snowflake は自らを「マルチクラスタ・シェアードデータ・アーキテクチャ」と呼び、DeWitt/Gray の3分類のいずれとも一対一対応しない第4カテゴリとして提示した（詳細は [[シェアードナッシング]] を参照）が、これは同論文の自称にとどまり、BigQuery・Redshift 等の他システムを含めた学術的な分類体系としては未確立 - **データ歪み対策の現状**: DeWitt/Gray が未解決課題とした「高度に歪んだデータ分布への対応」は現代の分散クエリエンジンでどこまで自動化されているか - **サービス木の段数設計は理論化されているか**: Dremel の実験(Figure 11)はクエリが返すグループ数が多いほどツリー段数を増やす効果が大きいことを示すが、最適な段数をワークロード特性(返却行数・データサイズ)から自動決定する一般的な理論やアルゴリズムは並列データベース研究の中に存在するか。 ## 関連 - ソース: [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]] / [[@2026__DiDi__Query Execution Plans and Pipelining]] / [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]] / [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]] - 概念: [[シェアードナッシング]] / [[データパーティショニング]] / [[専用データベースシステム]] / [[OLTPシステムアーキテクチャ]] / [[分散ストレージ]] / [[分散 PostgreSQL]] / [[プッシュ型パイプライン実行]] / [[ネスト型カラムナストレージ]] - エンティティ: [[David DeWitt]] / [[Jim Gray]] / [[Teradata]] / [[Tandem Computers]] / [[University of Wisconsin]] / [[DuckDB]] / [[Snowflake Computing]] ## 出典 - [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]]（並列データベースの基礎概念を体系化した原典） - [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]]（コンピュート・ストレージ分離アーキテクチャの産業実装例） - [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]]（ウェブ検索由来の多段サービス木をDB集計クエリへ応用した実装例）