データパニックを防ぐDBMSの仕組み（別バージョン）

巨大な倉庫は、なぜパニックにならないのか

動画は、こんな想像から始まります。何千万、何億もの荷物が保管された巨大な倉庫に、世界中から1秒間に何万件も「これを出して」「あれをしまって」と注文が殺到する。現実の倉庫なら、数秒で大パニックになるはずです。ところが、スマホで買い物をするときも、SNSを更新するときも、銀行で振り込むときも、裏側ではまさにこの状態が24時間365日続いています。それでも私たちは、パニックの気配をまったく感じません。

この「縁の下の力持ち」が、データベースの仕組みです。動画は、DBMS、三層スキーマ、トランザクションとACID特性、同時実行制御とデッドロック、障害回復の順に進みます。用語と「なぜそうなるのか」をセットで押さえましょう。

DBMSは倉庫の「門番」

データベースは、データを保管する巨大な倉庫にすぎません。そこへ、ショッピングアプリや在庫管理システムが「俺は手前から取る」「私は奥に押し込む」と、勝手なルールで出入りしたらどうなるでしょう。あっという間にデータはめちゃくちゃです。そこで倉庫の入り口に立つのが、DBMS（データベースマネジメントシステム）という門番です。動画では、データベースをうまく使うためのミドルウェアと説明されます。

多数の利用者からの要求をDBMSがまとめて引き受け、DBMSがデータベースに処理を行う。アプリが直接倉庫に入ることはなく、必ずDBMSを通ります。この管理人の仕事が、動画では大きく3つの機能に分けられます。

機能	することの例
DB定義	データベースの構造や格納方法などの枠組みを決める
DB操作	データの抽出や削除などをする
DB制御	データの整合性の確保や障害回復などをする

（補足：IPAの基本情報技術者試験シラバスVer.9.2にも、DBMSの機能の用語例として、定義・操作・制御の各機能が並んでいます（ほかに保全機能なども用語例にあります）。）

三層スキーマ：レストランでたとえる

1つ目の「DB定義」で出てくるのが三層スキーマです。聞き手が「1つの設計図ではだめなのですか」と尋ねると、答えは「全部を1つに詰め込むと、少し変更しただけでシステム全体を作り直す羽目になるから」。そこで視点ごとに、3つの層に分けます。

層	視点	着目点
外部スキーマ	ユーザーが見る表	何を見せるか
概念スキーマ	開発者から見た構造	どう関連するか
内部スキーマ	DBMS内部の格納	どこにしまうか

聞き手は、これをレストランにたとえました。

シェフが冷蔵庫の置き場所を一番上の段から一番下の段に変えた（内部スキーマの変更）としても、お客さんのメニュー（外部スキーマ）を印刷し直す必要はありません。層を独立させておけば、物理的な置き場所や論理的な構造が変わっても、ユーザーが使うアプリケーション側に影響を出さずにすみます。動画は、これを三層スキーマの最大の強みとしています。

（補足：IPAシラバスも、外部スキーマを利用者から見たデータの定義、概念スキーマを論理的なデータ構造、内部スキーマを物理的なデータ構造としており、動画と合っています。この3層の考え方は、1975年にANSI/X3/SPARCが提案したモデルが元とされますが、正式な標準にはなりませんでした。）

トランザクションとACID特性

ここからは、DBMSの「絶対に中途半端を許さない」ルールの話です。トランザクションとは、データを処理するときの処理の単位のこと。動画では、トランザクションはACID特性と呼ばれる4つの性質を満たす必要があるとされます。

聞き手の例です。限定スニーカーの決済ボタンを押した瞬間にスマホの電源が切れたら、お金だけ取られてスニーカーは出ないかもしれません。それを防ぐのが、次の4つです。

• A 原子性（アトミシティ）：処理はこれ以上分割できず、「すべて処理済み」か「完全に未処理」のどちらかだけ。自動販売機で、お金だけ取られてジュースが出ない状態は作らない。
• C 整合性（コンシステンシー）：実行結果に矛盾がない。「口座残高はマイナスにならない」というルールがあれば、破る処理は弾かれる。
• I 独立性（アイソレーション）：他のトランザクションの影響を受けない。自分だけの個室で作業するイメージ。
• D 耐久性（デュラビリティ）：実行結果が失われない（永続性）。確定したあとは、クラッシュや停電があってもデータは失われない。

（補足：独立性は少し単純化されています。実際のDBMSでは独立性の強さを選べ、SQL標準は4段階の隔離水準を定めています。PostgreSQLの公式文書では、既定のRead committedは、コミット前のデータは見えませんが、同じ検索を繰り返すと結果が変わることがあります。最も厳しいSerializableは、同時に実行した結果が、1つずつ順番に実行した結果と同じになると保証します。動画の説明は、この最も厳しい水準に近いものです。製品固有の記述を含みます。）

同時実行制御：ロック方式

ここで動画は「大きな壁」にぶつかります。世界中の人が同じスニーカーを狙っているので、複数の人が同時に作業しても、データがバラバラに更新されないよう管理する必要があるのです。これが同時実行制御です。みんなが押し寄せたときの交通渋滞をどうさばくか、という交通整理ですね。代表的な方法として、動画はロック方式と時刻印アルゴリズムの2つを挙げます。

ロック方式は、トランザクションを実行する間、他の人に誤ってDBを変更されないよう、鍵（ロック）をかける方法です。「ここは今使っているから入らないでね」というわけです。

（補足：動画の2つは代表例です。IPAの基本情報技術者試験シラバスは「ロック方式、セマフォ方式、コミットメント制御」を挙げ、応用情報技術者試験Ver.7.2には多版同時実行制御（MVCC）も入っています。）

デッドロック：胸ぐらをつかんだまま離さない

ただ、ロックには問題があります。巨大な倉庫でみんなが「俺が使うからここもロック」と始めたら、誰も動けなくなりそうです。複数のデータがロックの対象になると、お互いが相手の作業の終了を待ち、どちらの作業もできなくなることがあります。これがデッドロック（膠着状態）です。聞き手は「渋滞はゆっくりでも進むが、デッドロックはもっと絶望的」と指摘し、講師は「お互いの胸ぐらをつかんだまま、意地でも離さない2人のけんか」だと応じました。

動画の例はこうです。データXとYを、プロセス1とプロセス2が使います。プロセス1はXを使ってからYを、プロセス2はYを使ってからXを使おうとします。ここでプロセス1がX、プロセス2がYを同時にロックすると、プロセス1は「お前がYのロックを外したら、俺がXを外す」、プロセス2は「いや、お前が先にXを外せ」と言い張り、固まってしまいます。

順番	プロセス1	プロセス2
1	Xをロックする	Yをロックする
2	Yを使いたい（Yの解除待ち）	Xを使いたい（Xの解除待ち）

ロックをやめればデッドロックは起きませんが、それではデータが壊れます。動画は、避けるにはロックをかける単位と、かける順番に注意が必要だと説明します。

（補足：PostgreSQLの公式文書は、デッドロックを避ける最善の方法として、複数のロックをすべてのアプリが一貫した順序で取ることを挙げています。上の例で両方がX、Yの順に取れば、起きません。また、PostgreSQLはデッドロックを自動で検出し、関係する1つを中止して他を進めます。製品固有の挙動で、他のDBMSは確認していません。）

ロックの粒度：ジレンマがある

ロックをかける範囲を、ロックの粒度といいます。動画では、ここにジレンマがあると説明されます。

粒度	良い点	困る点
大きい（粗い）	処理の負担が小さい	競合しやすい。待ち時間が長くなり、並列に実行できる数が減る
小さい（細かい）	聞き手の発想では、待たされる人が減りそう	ロックを管理する負担が増え、動画ではデッドロックも起きやすくなるとされる

（補足：「ロック粒度」はIPAシラバスの用語例です。ただ、動画の「細かいとデッドロックも起きやすい」の根拠として、粒度との関係を直接書いた資料は、今回は確認できませんでした。PostgreSQLの文書は、明示的なロックの使用や行ロックでもデッドロックが起きると述べています。）

時刻印アルゴリズム：整理券方式

聞き手は、こう言い出します。「いっそロックを使わず、整理券みたいに、アクセスした時間を記録して、順番どおりに処理すればいいのでは」。それがもう1つの方法、時刻印アルゴリズムです。アクセスした時間を示す時刻印（タイムスタンプ）をチェックしながら、データを更新してよいかを判断し、データがバラバラに更新されないよう管理します。聞き手は「ロックをしないのでデッドロックは起きないのでは」と指摘し、講師は一見フェアで完璧に見えるとしたうえで、実務上のデメリットを挙げます。（補足：基本形の時刻印順序制御では、ロックを使わないのでデッドロックは起きません。）

ただし実務ではデメリットがあります。非常に多くの人が処理する場合や、処理時間が長い場合、順番が狂ってやり直しばかりになります。やり直しの連続で、結果的に処理時間が極端に長くなるのです。

動画は、だからこそ状況に合わせて、ロックの粒度や順番を工夫する高度な設計が必要になると締めくくります。

障害回復：ロールバックとロールフォワード

どんなに完璧なルールを作っても、急な停電やハードウェアの故障は避けられません。DBに障害が起きたときの回復処理として、動画はロールバックとロールフォワードの2つを挙げ、障害の重さの違いで整理します。

ロールバックは、トランザクションエラーなどの軽い障害で、プログラムが異常終了したときの処理です。記憶媒体は無事で、処理が途中で失敗しただけ。作業中だった処理を更新前ログで取り消し、障害前の状態に戻します。ディスクは無事なので、ソフトウェア的に「戻るボタン」を押すイメージです。

ロールフォワードは、ハードウェアの破損などの重い障害のときの処理です。倉庫が焼け落ちて、データがすべて飛んだ状態ですね。まずバックアップファイルで障害前の状態にいったん戻します。ただ、それだけでは今日の分の作業が消えたままなので、更新後ログで障害前に行われた作業の分を更新しながら進め、直前の状態まで復旧します。「進む」から、フォワードです。

動画の覚え方はこうです。ディスクが生きているならロールバック、死んでいるならロールフォワード。なぜそのログを使うのか、物理的な理由が分かれば間違えない、と動画は言います。

（補足：IPAシラバスは、用語例に「フォワードリカバリ（ロールフォワード）」「バックワードリカバリ（ロールバック）」「ジャーナルファイル（ログファイル）」「チェックポイント」を挙げますが、動画の「軽い障害はロールバック、重い障害はロールフォワード」という対応までは書いていませんでした。障害の種類の分け方や、どちらを使うかの説明は資料により異なる可能性があるので、使っているテキストの分類も確認してください。）

まとめ

動画は、ストレスなくデジタルサービスを使えているのは、目に見えない仕組みが働き続けているおかげだと締めくくります。動画で語られた内容を、順に振り返りましょう。

動画は最後に問いかけます。もし明日、世界中のシステムから原子性のルールが1分間だけ消えたら、銀行口座やネットショッピングでどんな恐ろしいことが起きるでしょうか。上の振り込みの設例で10,000円が消える場面を、思い浮かべてみてください。