📖 テーマ設定
🔊 音声設定
1.2
1.0
1.0
▶️ 再生コントロール
🎵 BGM設定
0.3
🔔 効果音設定
0.3

永続化とACID

概要

  • 日程: Day 3 / セッション 06
  • 時間: [13:00-13:30]
  • 形式: 座学
  • ゴール: ACIDの4要素を1文ずつ説明でき、ファイル/RDB/KVSの3つを「データの性質・整合性要件」の観点で使い分けられる
  • 学習形式: 対話型解説

導入(5分)

午前中は「設計の進め方」を学びました。午後は「設計したシステムが扱うデータをどこに、どう残すか(永続化)」というテーマです。

「永続化」と聞くと難しそうですが、要は「電源を切ってもデータが消えないようにする」ことです。アプリのメモリ上のデータは電源を切ると消えます。残したいデータは、ディスク(HDD/SSD)に書き出す必要があります。

ECサイトで注文ボタンを押した瞬間に停電しても、注文データが失われない。そんな当たり前のことを実現するための仕組みが、本セッションの主役です。

本編(20分)

1. 永続化(Persistence)とは

メモリ上のデータをディスクなどに書き出して、プログラム終了後も残す処理を「永続化」と呼びます。

flowchart LR A["アプリ #quot;メモリ上のデータ#quot;"] --> P["永続化処理"] P --> B["ディスク #quot;ファイル/DB/KVS#quot;"] B --> R["読み込み処理"] R --> A

主な永続化手段は3つ。

手段 特徴
ファイル CSV、JSON、テキスト シンプル、検索遅い、整合性は自前
RDB(リレーショナルデータベース) MySQL、PostgreSQL、SQLite 表形式、SQLで検索、トランザクション対応
KVS(Key-Value Store) Redis、Memcached、DynamoDB キーから値を高速に取得、集計は弱い

2. ACIDの4要素

データベースが「信頼できる永続化」を提供するために守るべき4つの性質。1983年、IBMのアンドレアス・ロイターとテオ・ヘアダーが命名。

性質 英語 意味 たとえ話
原子性 Atomicity 全部成功か全部失敗 振込: 出金成功・入金失敗は許されない
一貫性 Consistency ルールを破った状態にしない 口座残高がマイナスにならない
独立性 Isolation 他の処理の影響を受けない 同時に2人が同じ席を予約できない
永続性 Durability 障害があっても残る 停電してもコミット済みは消えない

コード例・実例

「銀行振込」を例に、ACIDを見てみましょう。

BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 1000 WHERE id = 1;  -- Aから出金
UPDATE accounts SET balance = balance + 1000 WHERE id = 2;  -- Bに入金
COMMIT;
  • Atomicity: 2つのUPDATEは「両方成功」or「両方なかったこと」のどちらか
  • Consistency: 残高が負にならない(CHECK制約などで守る)
  • Isolation: 同じ口座を別取引が同時に触っても、整合性が崩れない
  • Durability: COMMIT後の変更は、停電しても消えない

ここがポイント

ACIDを守るのは「お金や注文など、絶対に間違えてはいけないデータ」を扱う場合です。SNSのいいね数のように「多少ズレてもOK」なデータは、ACIDを緩めて性能を取ることもあります(後述のBASE)。

3. CAP定理とBASE(補足)

分散システムでは、一貫性(C)・可用性(A)・分断耐性(P)の3つすべては同時に満たせない、という定理(CAP定理、エリック・ブリュワー2000年)があります。多くの大規模サービスはACIDを緩めて「BASE」(Basically Available, Soft state, Eventually consistent)という方針を取ります。

つまり「絶対に正確」ではなく「最終的にそろえばOK」という考え方。SNSや在庫表示でよく使われます。

コラム

RDBMSの先祖は1970年、IBMのエドガー・F・コッドが論文「A Relational Model of Data for Large Shared Data Banks」で提唱したリレーショナルモデルです。コッド博士は数学者で、データを「集合」と「関係(リレーション)」として扱う着想を、純粋数学から持ち込みました。その50年後、世界中の業務システムが彼の理論で動いています。

4. ファイル/RDB/KVSの使い分け

観点 ファイル RDB KVS
構造の柔軟さ 中(スキーマあり)
検索性能 中〜高(インデックス) 超高速(キー指定のみ)
トランザクション なし あり(ACID) 限定的(BASE寄り)
集計(GROUP BY等) 苦手 得意 苦手
データ量 〜数GB 〜数TB TB〜PB
設定ファイル、CSVエクスポート 業務システム キャッシュ、セッション管理

ここがポイント

「データの性質」と「整合性要件」で選びます。「お金が動くか」「同時アクセスが多いか」「複雑な検索があるか」を問うと自然に決まります。

5. インピーダンス・ミスマッチとORM

オブジェクト指向プログラムのデータ構造(オブジェクト)と、RDBのデータ構造(テーブル)の構造ギャップを「インピーダンス・ミスマッチ」と呼びます。これを橋渡しするのがORM(Object-Relational Mapping)です。

flowchart LR O["プログラム上のUserオブジェクト #quot;id, name, posts#quot;"] --> ORM["ORM"] ORM --> T["DB上のusers/postsテーブル #quot;JOIN#quot;"] T --> ORM ORM --> O

代表的なORM: Sequelize(Node.js)、Prisma(Node.js)、TypeORM、ActiveRecord(Rails)、Hibernate(Java)

ここがポイント

ORMは便利ですが、複雑なクエリでパフォーマンスが落ちる「N+1問題」などの罠もあります。「魔法ではなく、SQLを書く労力との交換」と覚えておきましょう。

💬 AIに聞いてみよう

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば:

  • 「ACIDの4要素を、私の開発テーマ(〜)の具体例で説明して」
  • 「KVSのRedisを使うとどんなときに便利? 3つ例を挙げて」
  • 「N+1問題って何? Sequelizeで起きる例を見せて」

まとめ(5分)

永続化は「データをディスクに残す」こと。RDBの信頼性を支える4つの約束がACID。ファイル/RDB/KVSは、データの性質と整合性要件で使い分けます。プログラム世界とDB世界のギャップを埋めるのがORMです。

次のセッションでは、RDB設計の核となる「正規化」と、Day 1で学んだIAの整理分類の違いを考察します。

🔄 振り返りチェック

  • ACIDの4要素を1つずつ説明できますか?
  • ファイル/RDB/KVSをそれぞれどんな場面で使うか答えられますか?
  • インピーダンス・ミスマッチとは何で、ORMが何を解決するか説明できますか?

補足資料

  • 参考リンク: ミック『SQL 第2版 ゼロからはじめるデータベース操作』、Martin Kleppmann『データ指向アプリケーションデザイン』
  • 発展課題: 自分の開発テーマのデータを、ファイル/RDB/KVSのどれで持つかを分類してみる

学習ガイド

想定される質問と回答例

質問 ヒント
NoSQLとRDBはどっちが新しい? NoSQLは2000年代以降に普及。「Not Only SQL」の意味で、RDBを否定するものではない
トランザクションはRDB以外にもある? あるが限定的。KVSや分散DBではトランザクション機能が弱い/無い
なぜRDBは「リレーショナル」と呼ぶ? テーブル間の「関係(リレーション)」を扱うから。リレーションは数学用語の集合関係

つまずきやすいポイント

つまずきポイント ヒント
ACIDが暗記しづらい 「振込の例」で1度しっかり腑に落とすと忘れない
RDBとKVSの使い分けが分からない 「複雑な検索が必要か」「キー1つで取れるか」が判断軸
ORMが何を解決するか想像できない 試しにORMなしで生のSQLを書く演習をすると有り難みが分かる
読み上げを開始します...

AIに質問する