永続メモリ(PMEM)とDBの耐久性プリミティブ

バイト単位永続化という新しい地平

従来のストレージ階層は「速いが揮発する DRAM」と「遅いが永続するディスク・SSD」の二層に分かれていました。データベースがWAL（先行書き込みログ）や fsync に依存してきたのは、この断絶を埋めるためです。永続メモリ(PMEM、persistent memory)は両者の中間に座り、DRAM に近いレイテンシ（数百ナノ秒）で、しかも電源を切っても内容が残ります。

決定的な違いはアクセス粒度です。SSD はブロックデバイスで、最小でも 512 バイトや 4 KB 単位の I/O を発行します。PMEM は CPU のメモリバスに直結し、通常の load/store 命令で バイト単位 に読み書きできます。read()/write() システムコールもページキャッシュも介さず、ポインタをたどるだけでデータが永続化される――これが設計を根本から変えます。

なぜ store だけでは永続化されないのか

最大の落とし穴は、store 命令の完了が永続化を意味しないことです。CPU が store を実行すると、値はまず L1/L2/L3 のキャッシュラインに入ります。これらのキャッシュは 揮発性 です。ここで停電すれば、まだ PMEM デバイスへ追い出されていない値は消えます。

つまり耐久性を得るには、書いたキャッシュラインを明示的に「永続ドメイン（power-fail protected domain）」まで押し込む必要があります。永続ドメインとは、電源が落ちても残留電力（蓄電）で書き切られることが保証された境界です。CPU コアのキャッシュはこの外側、メモリコントローラ配下の書き込みペンディングキューは内側、という具合に境界が引かれます。

store v → [L1/L2/L3 キャッシュ] → [メモリコントローラの WPQ] → [PMEM メディア]
            ↑揮発・ドメイン外          ↑ここから永続ドメイン

この境界を越えさせる命令が、キャッシュラインフラッシュ系（clflush / clflushopt / clwb）です。とくに clwb（cache line write back）はラインを書き戻しつつキャッシュに残す（無効化しない）ため、直後に再アクセスする局所性の高いデータ構造で有利です。

フェンスが定める耐久性の順序

フラッシュ命令を発行しても、それだけでは足りません。clflushopt や clwb は 非同期 で、後続命令を待たせずに走ります。フラッシュが永続ドメインに到達したことを保証するには、ストアフェンス sfence で完了を待ち合わせる必要があります。順序保証の原理はこの一点に尽きます。

1. store data           # データ本体を書く
2. clwb data            # データのキャッシュラインを永続ドメインへ
3. sfence               # 2 の完了を待つ（ここで data は確実に永続）
4. store commit_flag    # 「有効」を立てる
5. clwb commit_flag
6. sfence               # commit_flag を永続化

重要なのは、commit_flag を立てる前に必ずデータ本体のフラッシュが完了していなければならない、という 依存順序 です。もし順序が逆転すると、停電復帰時に「フラグは立っているのに本体が未永続」という不整合が起こり得ます。これはWAL の write-ahead 規則――ログを書く前にデータを永続化してはならない――と同じ思想を、ハードウェアプリミティブで直接実現したものです。

ログレス／即時永続化の設計

PMEM の最大の魅力は、WAL を介さずにデータ構造を直接永続化する ログレス設計 が可能になる点です。従来は「データを更新する前に redo/undo ログを書く」二重書きが必須でしたが、PMEM ではデータそのものがバイト単位で即座に永続化されるため、ログを省ける余地が生まれます。

ただし無条件ではありません。問題は アトミック性の粒度 です。x86 の PMEM が単一の store でアトミックに永続化できるのは 8 バイト（自然境界に整列したワード）までです。これより大きい構造を「全部書けたか／全く書けていないか」の二択にするには、追加の工夫が要ります。

つまり「ログレス」とは「あらゆるログを消せる」意味ではなく、8 バイトアトミック更新で表現できる範囲はログ無しで即時永続化し、それを超える部分だけ局所的なログで補う、という設計判断です。グローバルな WAL とディスク fsync の往復が消える効果は大きく、コミットレイテンシは桁で縮みます。

永続ドメインの正体と「嘘をつくハードウェア」

耐久性は「どこまでが永続ドメインか」というハードウェアの保証範囲に完全に依存します。ここを誤解すると、コミット済みに見えたデータが電源断で消えます。

• ADR（Asynchronous DRAM Refresh）: 電源断を検知すると、メモリコントローラの書き込みペンディングキュー（WPQ）までの内容を残留電力で PMEM へ書き切る。CPU キャッシュは保護対象外。よってソフトウェアが clwb＋sfence でキャッシュを WPQ まで追い出す責任を負う。
• eADR（enhanced ADR）: 保護範囲を CPU キャッシュまで広げる。停電時にキャッシュ全体が書き戻されるため、原理的にはフラッシュ命令が不要になる（フェンスによる順序は依然必要な場面がある）。

同じコードでも、走るプラットフォームが ADR か eADR かで「フラッシュが必須か省けるか」が変わります。eADR 前提で書いたコードを ADR マシンで動かすと、フラッシュ漏れで永続化されません。

torn write とリカバリ

8 バイトを超える更新が途中で電源断に遭うと、一部だけ永続化された torn write（部分書き込み） が残ります。PMEM ではブロックデバイスのような 4 KB セクタアトミシティすら保証されないため、復旧時に「どこまで有効か」を自力で判定する仕組みが必須です。

典型的にはチェックサムやバージョン番号、あるいは前述の 8 バイトコミットフラグで「完全に書き切れたレコードだけを有効とみなす」設計にします。中途半端なレコードは無効として捨て、ローカルログがあればそこから巻き直します。リカバリの考え方自体はARIESの redo/undo と地続きですが、PMEM では「ログを舐めて再現する」コストが小さく、構造が直接永続化されているため復旧が高速になります。

まとめ

永続メモリは「バイト単位で永続化できるメモリ」という新しいプリミティブですが、その耐久性は無料ではありません。store の完了はキャッシュへの書き込みにすぎず、揮発性キャッシュは永続ドメインの外側にあります。耐久性を立てる鍵は順序であり、clwb/clflushopt でキャッシュラインを永続ドメインへ追い出し、sfence で完了を待ち合わせてからコミットフラグを書く、という依存順序を厳守します。これを土台に、8 バイトアトミック更新でコミットを表現できる範囲はログ無しで即時永続化し、超える部分だけ局所ログで補うのがログレス設計です。最後に効いてくるのは ADR か eADR かという永続ドメインの境界で、ここを誤ると一見コミット済みのデータが電源断で消えます。DRAM 並みの速度と永続性を両立できる代わりに、耐久性保証の責任がハードウェアからソフトウェアの命令列へと降りてくる――それが PMEM 時代のデータベース設計の本質です。