概要

情報技術の基礎として理解しておきたい データベースの応用 について、データウェアハウス、OLAP、分散データベース、CAP定理、ビッグデータを整理する。

小さな売上表を切り出し・集約し、平均値を再計算する際の注意点を確認する。分散データベースでは通信が途絶えた場面から確定手順と一貫性・可用性の条件を考える。

この記事の構成

• データウェアハウスとOLAP
  日々の取引を扱うOLTPとの違いと分析基盤としての役割を整理。
• データウェアハウスの構成と基本操作
  小さな売上表を切り出し・集約し、粒度の変化と平均の再計算を確認。
• 分散データベース
  確定通知や複製先への通信が途絶えた例から一貫性と可用性の条件を確認。
• ビッグデータ
  データレイク、NoSQL、分散処理など、大量データを扱う技術を整理。

データウェアハウスとOLAP

応用情報技術 - データベース管理：トランザクション・排他制御・障害回復で扱ったトランザクション管理を利用し、注文、決済、予約など多数の短い取引処理をオンラインで実行する処理形態を、OLTP（Online Transaction Processing）という。

OLTPは短い取引を多数処理することを重視する。大規模な集計も同じ環境で実行できる場合はあるが、資源の競合によって取引処理へ影響するため、分析向けの構成を別に検討する。
分析処理では以下に示すデータウェアハウスやOLAPが利用される。

• データウェアハウス
  経営的な意思決定や分析を目的として複数の業務システムからデータを統合し、時系列で蓄積・管理する仕組みを指す。
  分析しやすいようデータの形式やコード体系をそろえ、用途に応じてスタースキーマなどの多次元的なモデルで構成する場合がある。
  ※ データウェアハウスの構成や操作については次項を参照。

• OLAP（Online Analytical Processing）
  OLAPとは蓄積したデータを複数の分析軸から集計し、対話的に分析する処理や操作を指す。OLTPのデータを別の分析基盤へ取り込む構成は代表例だが、スナップショットや別データベースの利用が定義上必須なわけではない。

• 日々の注文処理と長期間の集計では負荷が違う
  注文受付では一件ごとの在庫確認と登録を短時間で確定したい。一方、分析では数年分の売上を読み、商品や地域ごとに集計したい場合がある。同じ資源で重い集計を動かすと、日々の更新処理の待ち時間へ影響することがある。

  データウェアハウスへ分析用のデータを集める理由の一つは、この負荷と用途を分けることである。ただし、取込み間隔によって分析側のデータには遅れが生じる。最新の一件を扱うのか、一定時点までの傾向を見るのかによって、必要な鮮度も変わる。

データウェアハウスの構成と基本操作

スタースキーマなどのディメンショナルモデルでは、売上、数量、金額など分析対象となる事実や測定値を記録したテーブルをファクトテーブルという。

※ 複数のデータベースから統合する場合は、事前にデータクレンジングを行い、データ形式やコード体系を統一する。

また、商品、顧客、日付などの分析軸と説明属性を持つテーブルをディメンションテーブルという。一般に多数のファクト行が外部キーによって各ディメンション行を参照する。\(E-R\) 図で表すと中心にくるファクトテーブルの周りをディメンションテーブルが囲む形になることから、このデータ構成はスタースキーマと呼ばれる。

以下はデータウェアハウスの基本操作。

• スライシング
  一つの次元について特定の値を選び、多次元データから部分集合を取り出す操作。例えば時間次元を「2026年」に固定して売上を表示。

• ダイシング
  複数の次元について値や範囲を選び、元のデータからより小さなサブキューブを取り出す操作。分析軸の表示方向を入れ替える操作はピボットと呼ばれる。

• ドリリング
  以下の方法で分析・集計結果をさらに分析または集計する操作。
  

  • ドリルダウン（またはロールダウン）
    分析結果を更に深堀りし、詳細データに分ける操作。
    例えば年月単位の分析結果を日単位の詳細データに分ける。
  • ドリルアップ（またはロールアップ）
    分析結果を集計し、データをまとめる操作。
    例えば年月単位の分析結果を年単位のデータに集計する。

• 同じ売上を切り口と粒度を変えて見る
  月・地域・商品ごとの売上を次の4行で表す。ここでは一行の粒度を「一か月、一地域、一商品」と固定している。

  月	地域	商品	売上
  1月	東京	A	100
  1月	大阪	A	200
  2月	東京	A	150
  2月	東京	B	50

  東京だけに絞ると3行、売上合計300になる。月ごとへ集約すると1月300、2月200となり、地域と商品の内訳をまとめて見ることになる。さらに2月の200を商品別に開けば、Aが150、Bが50と確認できる。

  このようにスライスは特定の値で切り出し、ロールアップは粗い粒度へまとめ、ドリルダウンは保持されている細かい内訳へ戻って見る操作として理解できる。元データに持っていない一日ごとの内訳を月の合計だけから復元することはできない。

• 平均の平均では全体の平均にならない場合がある
  店舗Aでは2件の平均購入額が100円、店舗Bでは8件の平均購入額が200円だったとする。二つの平均をそのまま平均すると150円だが、全10件の平均は次のようになる。

  \[ \frac{2\times100+8\times200}{2+8}=180\ \text{円} \]

  集計済みデータをさらにまとめる場合、平均値だけでは重みとなる件数が失われる。合計額と件数を保持しておけば、合計同士・件数同士を足してから平均を再計算できる。集計の粒度を変えても正しい値を得るには、どの指標を足し合わせられるかを確認する必要がある。

分散データベース

分散データベース とは複数のノードにデータや処理を配置しながら、論理的には一つのデータベースとして扱うシステムを指す。データの配置場所や複製を利用者に意識させない 透過性 は代表的な設計目標だが、どの範囲まで透過的に扱えるかは製品や構成によって異なる。

※ 2相コミット は複数のデータベースや資源にまたがる一つのトランザクションをすべてコミットするか、すべてロールバックするかにそろえるための原子的コミット手順である。分散トランザクションで利用されるが、分散データベースの透過性全般に必須な仕組みではない。

分散システムでネットワーク分断が発生している間は、下記の 一貫性 と 可用性 を同時に保証できない。この関係を CAP定理 （またはブリュワーの定理）という。単純に常時「3つのうち2つを選ぶ」という意味ではなく、分断発生時のトレードオフを示す点に注意する。

• 特性 \(1\)： \([C]\) 一貫性（Consistency）
  すべての読取りが直近に完了した書込みを反映した単一のデータとして観測できること。

• 特性 \(2\)： \([A]\) 可用性（Availability）
  障害が発生していないノードへ届いたすべての要求が有限時間内に応答を受け取れること。応答内容が常に最新であることまでは意味しない。

• 特性 \(3\)： \([P]\) ネットワーク分断耐性（Partition-tolerance）
  ネットワークの分断によって \(2\) つ以上のノード群が互いに通信できない状態になっても正常に動作すること。

• ネットワーク分断がない場合
  ノード間で通信できる前提では一貫性と可用性の両方を満たす設計が可能となる。ただし、分断が発生した場合の動作を説明するCAP定理上の選択肢とは分けて考える。

• 分断時に \([C]\) 一貫性を優先する場合
  矛盾した応答を避けるため、一部の要求を拒否または待機させる。このため、分断中は\([A]\) 可用性を保証できない。

• 分断時に \([A]\) 可用性を優先する場合
  各ノードが要求への応答を継続するため、古い値や一時的に競合する値を返す可能性があり、\([C]\) 一貫性を保証できない。分断解消後にデータを収束させる設計が必要となる。

• 2相コミットで準備と確定を分ける理由
  二つのデータベースへ関連する更新を行うとき、一方だけ確定して他方が失敗すると不整合になる。2相コミットではまず各参加者に確定できる準備ができたかを確認し、全員の準備が整ってから調停役が確定の決定を通知する。

  ただし、準備完了を答えた後で調停役との通信が途絶えると、参加者は他の参加者へ確定の決定が届いたか判断できず、待ち続ける場合がある。分散してもすべてを一つの更新として扱うためには、この待ちや障害回復も考慮する必要がある。「2相ロック」はロック取得・解放の規則であり、名前が似ていても別の仕組みである。

• 通信が切れたとき、古い値で答えるか待つか
  同じ在庫1個を複製した拠点AとBの間で通信が切れたとする。Aで販売を確定して在庫0になった後に、Bへ在庫照会が来ても、Bにはその変更が伝わっていない。

  Bが手元の1を返せば応答できるが、直前に確定した更新と矛盾する。最新の確定結果との整合性を守るなら、必要な情報を得るまで回答を保留したり処理を拒否したりする必要がある。CAPの定理ではネットワーク分断が起きた条件下で、線形化可能な一貫性と障害を起こしていない各ノードでの可用性を同時に保証できないという関係を扱う。

  ここでの一貫性はACIDのCでいう「データが定めた制約を満たすこと」と同じ定義ではない。また、平常時から常に三つのうち二つしか選べないという単純な製品分類でもない。

ビッグデータ

ビッグデータとは\(DBMS\)（データベース管理システム）で取り扱うことが困難なデータ群や従来の技術による処理量を超えた大量のデータ群を指し、画像、音声、ログ、位置情報などの非構造化データや定型的でないデータも含まれる。

ビッグデータを保存・分析する基盤の一つにデータレイクがある。データレイクは構造化データ、半構造化データ、非構造化データを加工前の形式を含めて保持できるストレージリポジトリである。すべてのビッグデータ処理でデータレイクが必須なわけではない。

ビッグデータを取り扱うために必要な代表的な技術として、以下の仕組みがある。

• グリッドコンピューティング
  分散コンピューティングの一形態で、ネットワーク上に分散した複数のコンピューター資源を連携させ、大量データの分析など大きなタスクを共同で処理する仕組みを指す。

• データマイニング
  大量データを統計学やパターン認識、人工知能などの分析手法を駆使してパターンや相関、異常値などの新しい知見を得るための技術またはそのプロセスを指す。

• 超並列コンピュータ
  多数のプロセッサーや計算ノードを結合し、大規模な並列処理によって高速化を図るコンピューターシステムを指す。プロセッサー数や構成はシステムによって異なる。

• \(NoSQL\)（Not Only SQL）
  キーバリュー型、ドキュメント型、カラム指向型、グラフ型など、主に関係モデル以外のデータモデルを採用するデータベースの総称。SQLを一切使わないという意味に限定されず、製品ごとにデータモデル、一貫性、問合せ方法が異なる。

まとめ

• OLTPは日々の取引処理、OLAPは蓄積データの分析処理に向く。
• データウェアハウスは整形・統合した分析データを扱い、ファクトテーブルとディメンションテーブルを組み合わせたスタースキーマなどで構成する。データレイクは多様な形式の生データを蓄積する。
• スライシングは一つの次元を固定し、ダイシングは複数の次元から範囲を切り出す。ドリルダウンは詳細化、ドリルアップは集計を行う。
• 分散データベースではデータ配置を意識させない透過性が設計目標となり、2相コミットは複数の資源にまたがる処理結果をそろえるために使われる。透過性の範囲や2相コミットの採用有無は製品・構成によって異なる。

• CAP定理ではネットワーク分断中に一貫性と可用性を同時に保証できないため、システム要件に応じた選択が必要になる。

• 集計の粒度を変えるときは平均値だけでなく合計や件数を保持する。分散処理では準備後の待ちや通信分断中の応答方針まで含めて保証を考える。

参考文献

• 瀬戸 美月 (\(2020\)) 『徹底攻略 応用情報技術者教科書』株式会社インプレス
• Microsoft Learn「スター スキーマと Power BI での重要性を理解する」（日本語・公式解説）
• AWS「データレイクとは何ですか?」（日本語・公式解説）
• PostgreSQL Documentation, Two-Phase Transactions（英語・公式仕様）
• Seth Gilbert, Nancy Lynch, Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services（英語・CAP定理の原論文）