永続化とACID
概要
- 日程: Day 3 / セッション 06
- 時間: [13:00-13:30]
- 形式: 座学
- ゴール: ACIDの4要素を1文ずつ説明でき、ファイル/RDB/KVSの3つを「データの性質・整合性要件」の観点で使い分けられる
- 学習形式: 対話型解説
導入(5分)
午前中は「設計の進め方」を学びました。午後は「設計したシステムが扱うデータをどこに、どう残すか(永続化)」というテーマです。
「永続化」と聞くと難しそうですが、要は「電源を切ってもデータが消えないようにする」ことです。アプリのメモリ上のデータは電源を切ると消えます。残したいデータは、ディスク(HDD/SSD)に書き出す必要があります。
ECサイトで注文ボタンを押した瞬間に停電しても、注文データが失われない。そんな当たり前のことを実現するための仕組みが、本セッションの主役です。
本編(20分)
1. 永続化(Persistence)とは
メモリ上のデータをディスクなどに書き出して、プログラム終了後も残す処理を「永続化」と呼びます。
主な永続化手段は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)です。
代表的な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を書く演習をすると有り難みが分かる |