このポストについて

DMBOK2 を読み進めていくシリーズ。
今回は第5章「データストレージとオペレーション」について。
主にデータベースの運用に関する内容となっており、いわゆるデータベースエンジニアの人には当たり前の話？が書かれている。

以降、特に注釈のない引用は DMBOK2 第6章からの引用とする。

データストレージとオペレーションとは

以下のように定義されている。

データの価値を最大化するために、永続化されるデータを設計し、実装し、サポートすること

主にデータベース管理者 (DBA: Database Administrators) が行うことになる。
次の2つのアクティビティが含まれる。

  • データベースサポート: データベース環境の初期実装からデータの取得、バックアップ、廃棄までのデータライフサイクル関連アクティビティ
  • データベース技術サポート: 技術要件を決め、技術的なアーキテクチャを定義し、技術を実装・管理する

事業がデータに依存する企業においてはデータストレージとオペレーションのアクティビティは事業の継続性のために必要不可欠である。
ゴールは次のとおり

  • データライフサイクル全体にわたるデータの可用性を管理する
  • データ資産の完全性を保証する
  • データ処理の性能を管理する

概念・用語など

データベースアーキテクチャの種類

  • 集中型データベース: 単一システム内で使うデータを一箇所にまとている
  • 分散型データベース: 多数のノードにデータが配置される
  • 連邦型データベース: 自立した複数のデータベースシステムを単一の連邦型データベースに割り当てる
  • 仮想化／クラウドプラットフォーム: クラウド上のデータベースを実装

データベース処理のタイプ

  • ACID: トランザクションの信頼性のための制約
    • 原子性 (Atomicity): 操作はすべて実行されるかまったく実行されないかのどちらか
    • 一貫性 (Consistency): トランザクションはシステムが定義するすべてのルールを常に満たさなければならない
    • 独立性 (Isolation): 各トランザクションは実行中の他のトランザクションの影響を受けない
    • 永続性 (Durability): トランザクションは完了すると元に戻せない
  • BASE: データの量と多様性を受けた、ACID とは異なる考え
    • 基本的に利用可能 (Basically Available): ノードの障害発生時もあるレベル以上の可用性を保証する
    • ソフトステート (Soft State): データは一定の変動状態にある
    • 最終的な一貫性の確保 (Eventual Consistency): データは最終的にすべてのノードで一貫性を保つが、各トランザクションの一貫性が常に確保されているわけではない
  • CAP: 分散システムでは以下のどれか2つしか満たせない
    • 一貫性 (Consistency): システムは常に想定どおり動作できなければならない
    • 可用性 (Availability): システムは要求時に利用可能でなければならに
    • 分断耐性 (Partition Tolerance): システムは部分的な障害の発生時に運用を続行できなければならない

データベース構成

上から順により制御された構造であり、かつ古くからあるものとなっている。

  • 階層型
    • tree schema
      • データは親子関係が必要な木構造として整理されている
  • リレーショナル型
    • 集合理論や関係代数にもとづく
    • schema on write
      • 書き込み時に構造を知っておく必要がある
  • 非リレーショナル型
    • データを単純な文字列や完全なファイルとして保存することができる
    • schema on read
      • 様々な方法で読み取ることができる

一般的なデータベースプロセス

すべてのデータベースは何らかの形で以下のプロセスを実現する。

  • アーカイブ
  • 最大容量と増加の予測
  • 変更データキャプチャ (CDC: Change Data Capture)
  • 廃棄
  • レプリケーション
  • 耐障害性と復旧
  • 保持
  • シャーディング (区画化)

アクティビティ

データストレージとオペレーションでは主にデータベース技術の管理とデータベースの管理の2つのアクティビティがある。

データベース技術の管理

  • データベース技術の特徴に対する理解
    • 技術選定において候補となるデータベース技術の特徴を理解しておく必要がある
    • 1つのデータベースアーキテクチャや DBMS があらゆるニーズに対応しているわけではない
  • データベース技術の評価
    • 戦略的に DBMS ソフトウェアを選定することが重要
    • 小規模なパイロットプロジェクトや PoC の実施を推奨
  • データベース技術の管理と監視
    • データベース技術の実装、サポート、利用に関わる人にトレーニングが必要
    • 定期的なバックアップとリカバリテスト

データベースの管理

  • 要件の理解
    • 容量見積などを含むストレージ要件
    • トランザクション型、大規模な書き込み & 検索型などの使用パターン
    • データアクセスのための言語、手法などのアクセス要件
  • 事業継続性の計画
    • 災害や有害事象への備え
    • バックアップの作成
    • データのリカバリ
  • データベースインスタンスの実装
    • 物理ストレージ環境の管理
    • データベース・アクセス統制管理
    • ストレージコンテナの作成
    • 物理データモデルの実装
    • データの取り込み
    • データのレプリケーション管理
  • データベース性能の管理
    • SLA の設定
    • データベースの可用性の管理
    • データベースの稼働管理
    • サービスレベルの維持
    • トランザクション性能とバッチ性能
    • 性能の問題の修復
    • 代替環境の維持
  • テスト用データセットの管理
    • 効率的なテストのための高品質なデータ
  • データ移行の管理

まとめ

この章はいわゆるオペレーショナルな RDBMS について書かれているようにも見えるが、抽象度が高いので組織レベルのデータ基盤や DWH にも当てはまる。
DMBOK2 の内容は抽象的に書かれていることも多く、それゆえ現場エンジニアにとってぱっと理解しにくいものとなっていることもある。

ACID は大事だと思うが、データレイクの運用であまり考慮されていないケースを見かけることがある。
CAP 定理は書籍「データ指向アプリケーションデザイン」で疑問を投げかけられてたな。