# 適時性と完全性 ## 定義 適時性(timeliness)と完全性(integrity)は、DDIA第13章が「一貫性(consistency)」という語が本来混同してきた2つの独立した要求として分解して提示する概念対である。**適時性**はユーザーが最新の状態を観測できることを意味し、レプリケーションラグにより古いデータを読んでしまう不整合は一時的であり、待つ・再試行することで解消する。CAP定理が言う「consistency」は線形化可能性の意味であり、適時性を達成する強い手段の1つである。**完全性**はデータの欠損・矛盾・虚偽がないことを意味し、導出データセットがビューとして維持される場合、その導出過程自体が正しくなければならない(欠損レコードを持つインデックスは役に立たない)。完全性の違反は永続的であり、待っても解消せず、明示的な検査と修復を要する。ACIDトランザクションの文脈での「consistency(C)」は通常この完全性の意味で理解される。標語的には「適時性の違反は結果整合性のもとで許容されるが、完全性の違反は永続的な不整合をもたらす」とまとめられ、ほとんどのアプリケーションでは完全性の方がはるかに重要である。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Timeliness and Integrity") ## データフローシステムにおける正しさ ACIDトランザクションは通常、適時性(線形化可能性)と完全性(アトミックコミット)の両方を同時に提供するため、両者の区別を意識する必要が薄い。一方、本書が論じてきたイベントベースのデータフローシステム(ストリーム処理・CDC・イベントソーシング)は、この2つを明確に**分離する**。イベントを非同期に処理する以上、適時性の保証は既定では存在しない(コンシューマがメッセージの到着を明示的に待たない限り)。しかし完全性はストリーミングシステムにとって中核的な要求であり続ける——正確に一度(exactly-once)またはeffectively-onceのセマンティクス、ならびに端から端までの重複抑制(べき等な操作)によって、メッセージの喪失や二重適用を防ぐことが完全性維持の鍵となる。具体的には、(1) 書き込み操作を単一のメッセージとして表現しアトミックに書き込むこと、(2) そのメッセージから決定的な導出関数によって他の状態更新を導くこと、(3) クライアント生成のリクエストIDをエンドツーエンドで伝搬させ重複抑制とべき等性を可能にすること、(4) メッセージをイミュータブルにし導出データを随時再処理できるようにすること、の4つの組み合わせによって完全性が達成される。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Correctness of dataflow systems") ## 緩い制約とコーディネーション回避 厳密な一意性制約は同期的な調整(コンセンサス)を要求し不可避のコストを伴うが、多くの実際のビジネス要求は「厳格な制約」ではなく「緩い制約」を許容する——注文が在庫を超過したら追加発注して詫びる、航空会社・ホテルはオーバーブッキングを見込んで補償プロセスを用意する、口座残高を超えた引き出しには超過手数料を課す等。このような制約違反を事後に修正する処理は**補償トランザクション(compensating transaction)**と呼ばれる。詫びのコストが低いビジネス領域では、書き込み前の同期検証にこだわらず楽観的に書き込み、事後に非同期で検証・補償する方が可用性・性能で有利になりうる。これらのアプリケーションは完全性(お金が消えてはならない、予約は失われてはならない)を要求するが、制約の強制については適時性を要求しない。 この2つの観察——(a) データフローシステムはアトミックコミットや線形化可能性なしに完全性を維持できる、(b) 厳密な制約より緩い制約で十分なアプリケーションは多い——を組み合わせると、**コーディネーション回避型(coordination-avoiding)**データシステムという設計方針が得られる。地理的に分散した複数のデータセンタが非同期マルチリーダー構成で独立に稼働しつつ、強い完全性保証を維持できる。コーディネーションを局所化する(復元不能な操作の前だけ同期検証を残す等)ことで、不整合への「詫び」の回数と可用性低下への「詫び」の回数の間の最適なトレードオフを狙う。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Loosely Interpreted Constraints", "Coordination-avoiding data systems") ## Trust, but Verify(監査) ハードウェア(メモリ・ディスク・ネットワーク)もソフトウェア(データベース自体を含む)も完全には信頼できない——MySQLの一意性制約不具合やPostgreSQLの直列化可能分離での書き込みスキュー再現など、成熟したデータベースにもバグは存在する。伝統的なシステムモデルは障害を二値(起こりうる/起こりえない)で扱うが、実際には確率の問題であり、大規模になるほど稀な事象も現実に発生する。そのため、完全性を継続的に検査する**監査(auditing)**が必要になる——HDFS・Amazon S3はディスクを完全には信頼せず、バックグラウンドでファイルを読み返し複製と比較するスクラビングを行う。 イベントベースのシステムは、決定的で再現可能な導出過程(イベントログの再実行、あるいは冗長な並行導出との突き合わせ)によって監査可能性(auditability)を高める。ハッシュによるイベントログ自体の破損検査、時間旅行的なデバッグ(異常が起きた正確な状況の再現)も可能になる。この「trust, but verify」の考え方をエンドツーエンドで適用すればするほど(パイプライン全体を検査対象に含めるほど)、破損が見過ごされる余地は減る。ブロックチェーンやMerkle木・Certificate Transparencyのような暗号学的検証技法は、この方向性の重量級の実例であり、今後より軽量な文脈での応用が期待される。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Trust, but Verify") ## 横断的知見 - **CAP定理の「consistency」は本ページの適時性(timeliness)の一種にすぎず、[[外部一貫性]]が扱ってきた線形化可能性はその中でも最も強い実現手段として位置づけ直される**: [[外部一貫性]]は Spanner の commit wait・CockroachDB の HLC を通じて「実時間順序の保証」を論じてきたが、これらはいずれも第13章の語彙では**適時性を達成する強い手段**の一種であり、完全性とは独立の軸である。第13章の分解に照らすと、Spanner・CockroachDBが払う commit wait や不確実性区間の待機コストは、完全性のためではなく専ら適時性のために支払われていることが明確になる——外部一貫性の議論はこれまで「一貫性の強さ」という単一軸で語られてきたが、第13章の枠組みはこれを適時性軸に位置づけ、完全性は別の(多くはべき等性・監査による)手段で独立に達成すべきものだと再定義する。(Source: [[@2013__TOCS__Spanner - Google's Globally Distributed Database]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Timeliness and Integrity") - **[[結果整合性]]が蓄積してきたDynamo/Cassandraの「結果整合性」は、第13章の語彙では純粋に適時性の緩和であり、完全性の緩和ではないことが明確化される**: [[結果整合性]]はこれまで「読み取りが最新の書き込みを反映しない」という現象を軸に議論を蓄積してきたが、Dynamo/Cassandraのベクタクロック・LWWによる衝突解決自体は、書き込みが失われたり矛盾した状態のまま放置されたりしないことを目指す**完全性維持の機構**でもある。第13章の分解を適用すると、Dynamo/Cassandraが「結果整合性を受け入れる」というときそれは適時性の緩和を指しており、完全性(最終的に全レプリカが正しい状態に収束すること)は別途、衝突解決アルゴリズムによって維持されるべき要求として区別できる。この整理は、[[結果整合性]]が既に導入していた「強い結果整合性(strong eventual consistency、CRDT等による収束保証)」という概念と符合する——強い結果整合性とはまさに「適時性は犠牲にするが完全性(収束)は保証する」という第13章の理想を指した言葉であったと再解釈できる。(Source: [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Timeliness and Integrity") - **SRE/SLO 実務書が独立に「適時性(timeliness)」の語を鮮度の同義語として用いており、DDIA第13章の理論的区別が実務側で自然発生的に収束していたことを示す**: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]]は、データ属性の1つ「鮮度(Freshness)」を定義する際に「適時性(timeliness)と呼ばれることもあります」と明記する。DDIA第13章がストリーミングシステムの理論として「一貫性」を分解して導入した適時性という語を、SLO実務書は理論的系譜への言及なしに全く同じ意味(最新のソース入力に対してデータがどれだけ古いか)で独立に使っている。これは、適時性という切り口が抽象理論の産物ではなく、データ集約型サービスを運用する実務家が SLI を設計する過程で自然に必要とする区別であることを裏付ける(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]] §11.3.2.1, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Timeliness and Integrity")。 - **DDIA第13章の単一の「完全性(integrity)」軸は、Hidalgoの書籍では計測可能な3つの属性(完全性・厳密性・整合性)に分割され、実装可能な粒度まで分解される**: DDIA第13章の完全性は「データの欠損・矛盾・虚偽がないこと」を包括的に指す理論的な軸だが、Hidalgoの書籍は同じ問題領域を、(1) データ項目の欠損の有無を計測する**完全性(Completeness)**、(2) データが事実をどれだけ正確に表すかを計測する**厳密性(Accuracy)**、(3) データが意図せず・悪意を持って改変されていないかを計測する**整合性(Integrity)**、という3つの独立した SLO 対象に切り分ける。特にHidalgoの「整合性」はガバナンス・トレーサビリティ・改ざん検知(ハッシュチェック、証明システム)に焦点を当てており、DDIA が想定するデータフローシステムの完全性(exactly-onceセマンティクス・べき等性による喪失/重複防止)とは異なる、よりセキュリティ・監査寄りの意味で使われている。同じ英単語 "integrity" が、DDIA(データが失われず重複もしない)とHidalgo(データが不正に改変されていない)とで異なる射程を指す**用語の空似(false friend)**である点は、書籍間で概念を接続する際に注意を要する(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]] §11.3.2.2, §11.3.2.4, §11.3.2.6, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]] "Timeliness and Integrity")。 ## 未解決の問い - 「詫びのコスト」を定量化するフレームワーク(金銭的コスト・評判コスト・顧客離反率等)は、コーディネーション回避型システムの設計判断にどこまで体系的に組み込めるか。書籍は定性的な議論にとどまる。 - Merkle木・Certificate Transparencyのような重量級の暗号学的監査技法を、一般的なデータパイプラインへ「軽量な文脈」で応用する具体的な実装例(書籍が示唆するのみ)はどこまで実用化されているか。 - 適時性と完全性という2軸の分解は、CAP定理・PACELC定理のような既存の理論的フレームワークとどう厳密に対応づけられるか。CAP定理の「A(可用性)」は本ページのどちらの軸とも異なる第3の軸に見えるが、書籍はこの整理を明示的には行っていない。 - Hidalgo の書籍が完全性・厳密性・整合性に3分割した実務的な属性群は、DDIA第13章の完全性という単一理論軸とどこまで1対1で写像できるか。特に Hidalgo の「一貫性(Consistency)」(複数コピー間の一致)は DDIA の適時性・完全性いずれの軸に属するか、あるいは両者にまたがるか、本ページ単独では未整理。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]("Timeliness and Integrity", "Trust, but Verify") / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]] - 概念: [[結果整合性]](適時性の緩和の具体例) / [[外部一貫性]](適時性を強く保証する手段) / [[べき等性]](完全性維持のメカニズム) / [[エンドツーエンド論]](監査・完全性検査の一般原理) / [[データ品質SLO]](完全性・鮮度をSLO化する実務パターン) ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 13 A Philosophy of Streaming Systems]]("Aiming for Correctness", "Timeliness and Integrity", "Trust, but Verify") - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]](§11.3.2.1 鮮度, §11.3.2.2 完全性, §11.3.2.6 整合性)