見出し画像

DMBOK第6章データストレージとオペレーション

zono

要約

ストレージに関する一般的な知識、データライフサイクル管理、ACIDとBASEの比較、CAP定理、変更データキャプチャ、データの廃棄、技法について述べています。これらは効果的なデータ管理の一環であり、原理原則を知っておくと他でも応用できます。

前章

前の章である第5章データモデリングとデザインはこちらです。

ストレージに関する一般的な知識

データライフサイクル管理とは

データベース管理者はライフサイクル全体にわたってデータの正確性と一貫性を維持し保証しなければいけません。データライフサイクルを管理するには、データを取得、移行、保持、有効期限を管理し廃棄します。そのためのポリシーや手順の実施が必要になってきます。

ACID vs BASE

ACIDは信頼性のあるトランザクションシステムの持つべき性質です。
どの入門書にも記載のある基礎的な内容です。

  • Atomicity（原子性）・・・ 操作は全て実行されるか、1つも実行されないか

  • Consistency（一貫性）・・・ トランザクションは定義されたすべてのルールを常に満たさないといけない

  • Isolation（独立性）・・・ 各トランザクションは独立している

  • Durability（永続性）・・・ 一旦完了すると元に戻せない

次にBASEです。分散システムでACIDを適用しようとすると、複数のサーバーで処理を分散させたときに一台のサーバーが障害でトランザクションが行えない等の問題があるため、新たに提唱された特性になります。

  • Basically Available・・・ システムはあるレベル以上の可能性を保障する

  • Soft-State・・・ データは一定の変動状態にある

  • Eventual Consistency・・・ 最終的にすべてのモードとすべてのデータベースで一貫性を保つ

ACIDとBASEの違いは下記の表にまとめています。

ACID vs BASE（DMBOKより）

CAP定理

この定理は、分散システムの場合、同時に次の2つの性質を保証することはできるが、同時に３つの性質を保証することはできないというものになります。

  • 一貫性(Consistency)
    全てのノードで同じデータを確認することができるという性質です。

  • 可用性(Availability)
    どのノードで障害が起きても処理の継続性が失われない性質です。
    単一障害点（システムを構成する要素のうち、停止するとシステム全体が停止してしまう部分）がないということです。

  • 分断耐性(Partition-tolerance)
    ネットワークが分断されることがないという性質です。
    ネットワークの分断に対する耐性が高いということです。

ACIDやBASE、CAP定理も同じような部分に着目していることが分かります。それだけ重要なのでしょう。

ACIDやBASE、CAP定理だけでなく、DMBOKに記載の無いトランザクション分離レベルの詳細な説明は下記の本に分かりやすく記載があるのでご覧になってみてはいかがでしょうか？オススメです。

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

変更データキャプチャ(CDC: Change Data Capture)

 変更データキャプチャとは、データが変更されたことを検出し、変更に関連する情報が適切に保存されることを保証するプロセスを指します。

変更を検出して収集するには、2つの方法があります。
1つ目が、データのバージョン管理で変更された行を識別する列を調べる方法（例えば、最終更新のタイムスタンプ、バージョン番号、ステータスインジケータ）です。
2つ目が変更を記録しているを読み、その変更を第二のシステム（別のシステム）に複製できるようにする方法です。

例えば、Java製のOSSであるDebeziumや

AWS DMS

GCP Datastream, SpannerCDC

などがあります。

廃棄

すべてのデータが1時ストレージに永久にとどまると想定するのは間違いです。データが利用可能な領域を埋めてしまい、いつか性能が低下し始める時が来るからです。
一部のデータが価値が低下し、保持する必要がなくなることがあります。 データマネジメントの主要な目標は、データの維持にかかるコストが、そのデータが組織にもたらす価値を超えないようにすることです。

技法

低スペック環境下でのテスト

これは基本中の基本でやっていないケースはなかなか見ませんが、 まずは最低レベルの環境（開発環境）に適応してテストをするべきです。OSのアップグレードやデータパッチソフトウェアやデータベースの変更プログラムコードの変更は対象になります。むしろ、対象にならないものはほとんどないと言っても良いかもしれません。

変更はすべてスクリプトを使用

データベース内のデータを直接変更する事は非常に危険です。これは他の章でも述べています。
ただし、データパッチ、合併や買収、緊急時等の変更要求が1回限りの場合や状況に対応できる適切なツールが無い場合は、直接変更する必要があるかもしれません。それでも、本番環境に適応する前に更新用スクリプトファイルを作り、非本番環境で徹底的にテストすることが重要になります。

まとめ

以上、データストレージとオペレーションについて解説しました。
分散システムといったデータパイプラインに必要な技術について幅広く紹介されていた章でした。データエンジニアリングの分野はまだまだ広く、この章だけでは網羅できないので、他の章や他の本（紹介した本）を読んでいただければと思います。

DMBOKのデータストレージとオペレーションについて特に重要な点を解説しました。ただし、非常に量が多いため解説していない部分が多々あります。詳細は本書を手にとってみて下さい。


また、DMBOKの各章をまとめた一覧はこちらです。


この記事が気に入ったらサポートをしてみませんか？