Claude Fable 5.2 および Mythos 5.2 の発表

Claude Fable 5.2 および Mythos 5.2

最も困難な技術的課題に取り組むために設計されたモデル、Claude Fable および Claude Mythos をアップグレードしました。

Claude Fable 5.2 および Claude Mythos 5.2 は、コーディング、推論、ビジョンなどの分野で改善が見られます。プレリリース段階のテストでは、エンジニアが通常は不可能であったソフトウェア移行を完了するのを支援し、ゼロから3つの動作する電子機器を設計し、ブラックホールの物理学における2つの未解決問題を解決し、ロボット工学の評価で実質的な進歩を遂げ、フェルマーの最終定理の証明を30時間で形式化するなど、その他多くの応用例があります。

Claude Fable と Claude Mythos は同じ基盤モデルです。Fable は強力なサイバーセキュリティと生物学の安全対策を備えており、悪用を防ぐことで、すべてのユーザーが利用できるようになっています。サイバーセキュリティまたは生物医学研究で有益な応用を追求する組織は、最近拡張されたライフサイエンスおよびサイバー検証プログラムを通じて Mythos へのアクセスを申請できます。

テスターは、Fable 5.2 および Mythos 5.2 が過去の Fable および Mythos モデルよりも明確にコミュニケーションできると評価しています。Claude Fable 5.1 および Claude Mythos 5.1 よりも最大30%高速にアウトプットを生成し、価格も低くなっています。入力トークン100万あたり8ドル、出力トークン100万あたり40ドルです。

Fable 5.2 および Mythos 5.2 には、オプションの高速モードも用意されており、トークン生成速度を最大2.5倍に向上させます。高速モードは、入力トークン100万あたり16ドル、出力トークン100万あたり80ドルで利用できます。

安全性とアライメント。 モデルの能力向上に合わせて安全性を維持するために、Fable 5.2 および Mythos 5.2 の基盤となるモデルに対して、広範なプレリリース安全テストを実施しました。これには、サンドボックスからの脱出のような特定の懸念される動作をより深く理解するための新しい評価の開発が含まれます。アライメントの不整合によるハイリスクなリスクは低いままであり、モデルはほとんどのアライメント測定において、最近のモデルと同等かそれ以上のパフォーマンスを示しました。Fable 5.2 のサイバーおよび生物学の安全対策は Fable 5.1 と同等に堅牢ですが、不要なブロックが少なくなり、蒸留攻撃に対するこれまでで最も強力な保護を実装しました。

安全性テストの詳細については以下で説明しており、完全な詳細はClaude Fable 5.2 および Mythos 5.2 システムカードで確認できます。

Claude Fable 5.2 および Mythos 5.2 を使用するタイミング。 Fable および Mythos は、最も野心的でオープンエンドな技術作業に最適です。ほとんどのコーディングおよび知識タスクについては、まず Claude Opus 5.5（当社の最も強力な日常的なドライバー）から始め、作業の範囲と複雑さに応じて、Fable または Mythos へ、あるいは Claude Sonnet 5.5 または Claude Haiku 5.5 へと切り替えることをお勧めします。Fable 5.2 は、アドバイザー（Haiku、Sonnet、Opus モデルがより困難な問題の解決を支援するために参照する）やオーケストレーター（より単純なタスクを小規模なモデルに委任する）の役割を果たすこともできます。

Claude Fable 5.2 および Mythos 5.2 の評価

ベンチマークパフォーマンス。 以下のベンチマーク表は、Claude Fable 5.2 および Mythos 5.2 が、評価したほぼすべての能力において Opus 5.5 を上回っていることを示しています。

評価方法の詳細については、Claude Fable 5.2 および Claude Mythos 5.2 システムカードを参照してください。Fable 5.2、Fable 5.1、および Opus 5.5 のスコアは、特に記載がない限り、セーフガードをオンにした結果を示しています。すべてのスコアは、特に記載がない限り、各モデルの利用可能な最高レベルの努力を示しています。† CyScenarioBench では、各ラボのスコアは固有のタスクに基づいています。‡ RoboDojo Sim は利用可能な最高レベルの努力を示し、内部で実行されました。

労力と効率。 Medium effort（Claude アプリおよび Claude Code のデフォルト）では、Fable 5.2 は Fable 5.1 よりも少ないトークンで困難なタスクを達成できます。FrontierCode 2.0 評価の初期テストでは、Fable 5.2 の High effort は Opus 5.5 の Max effort とほぼ同等で、タスクあたりのコストは約半分でした。Xhigh effort では、テストされたリリース済みモデルの中で最高のスコアを記録しました。

コーディング

Anthropic のコアコードベースにマージされた変更の90%以上は、Claude によって（人間のガイダンスとともに）作成されています。Fable 5.2 を使用して、数分で頑固なバグを修正し、すべてのサービスでパフォーマンスを最適化し、そうでなければ遅すぎるかコストがかかりすぎるため試みられなかった高価値のソフトウェアプロジェクトを完了しました。Fable 5.2 の初期バージョンのエージェントチームは、クリティカルな本番サービスを Python から Rust へ移行しました。このサービスは現在、より効率的で、より信頼性が高く、約26倍高速に起動します。Fable 5.2 は強力なエンジニアリング判断を発揮し、曖昧な要求からでも高品質な結果を生み出すことができることがわかりました。

実験として、ある Anthropic のエンジニアは Fable 5.2 にプロトタイプのオペレーティングシステムを設計するタスクを与えました。空のフォルダから開始し、モデルは1,000以上のサブエージェントを調整し、8日間昼夜を問わずコードの記述、テスト、レビューを行いました。ラップトップで起動する動作するオペレーティングシステムを生成しました。そのコアはマシンを駆動し、ディスク、キーボード、ネットワーク用のドライバー、永続ファイルストレージ、ウィンドウ、ログイン画面、インストーラー、および組み込みの Claude 機能（以下のビデオを参照）を備えています。

初期テスターは、Fable 5.2 のコーディングスキルが幅広いタスクにどれほど成功裏に適用できるかに感銘を受けています。

サイバーセキュリティ

Claude Mythos 5.2 は、サイバーセキュリティエンジニアリングにおいて最も有能なモデルです。以前のモデルよりも多くの脆弱性を検出でき、それらを再現して修正する能力も向上しています（Claude Fable 5.2 のセーフガードは、ほとんどのサイバーセキュリティ関連タスクをブロックすることに注意してください）。あるセキュリティ企業は、Claude Mythos 5.2 によって検出された確認済みバグの6分の1が、テストされた他のすべてのフロンティアモデルで見逃されていたと報告しています。当社の内部評価である CVE Rediscovery¹ では、Claude Mythos 5.2 は Claude Opus 5.5 よりも10.2%、Claude Mythos 5.1 よりも14.4%多くの脆弱性を検出しました。Claude Mythos 5.2 は、より優れた判断力とキャリブレーションも示しています。あるテスターは、以前のモデルが約20件に1件の発見の深刻さを過大評価していたのに対し、Claude Mythos 5.2 は過大評価していなかったと述べています。²

Claude Mythos 5.2 のサイバー能力は、当社のサイバー検証プログラムを通じて利用できます。このプログラムは継続的に拡張・改善されています。Claude Enterprise の顧客（サイバー検証プログラムのメンバーでなくても）は、当社の最も有能なモデル（現在は Claude Mythos 5.2 を含む）を使用してコードベースの脆弱性をスキャンするClaude Securityにアクセスできます。Claude Security の最近のアップデートにより、コードが更新される際にリポジトリを監視し、発見された脆弱性を追跡して修正を確認し、追加のコンテキストから学習し、API および MCP を通じてユーザーのツールに接続できるようになりました。

科学と工学

科学、工学、数学における重要なタスクは、ますますコーディングに依存するようになっています。データの分析、分子のモデリング、部品の設計、計器の制御はすべてソフトウェアを通じて行われます。以下では、Claude Fable 5.2 および Claude Mythos 5.2 が、研究者がこれらの分野の困難な問題の解決にどのように貢献したかについて説明します。

理論物理学

Claude Fable 5.2 は、理論物理学における2つの未解決問題を解決しました。どちらもブラックホールに関連しており、現代物理学の2つの要である相対性理論と量子力学を統一しようとする試みです。

Claude の両方の結果は、重力を含む特定の宇宙が、重力を含まない量子理論によって正確に記述できるという考えであるホログラフィック二重性に基づいています。最初の問題では、1983年の物理学者は、これらの宇宙が加熱されると、水が沸騰するように、ブラックホールが突然形成されることを示しました。しかし、彼らの方法は、相対性理論が適用できるほど大きい宇宙にしか適用できませんでした。非常に小さい宇宙、つまり量子記述のみが使用できる宇宙で同じことが当てはまるかどうかを判断するための計算は、2003年に提示されましたが、完了するには非常に手間がかかりました。Fable 5.2 は、大部分自律的にこれを完了し、そこでも遷移が突然であることを発見しました。2番目の問題では、Fable 5.2 は、物理学者が15年以上使用してきた、単純化された宇宙における量子重力の候補理論を排除するための技術の正確な限界を発見しました。これらの結果の詳細については、それぞれのプレプリントを参照してください。こちらとこちらです。

タンパク質フォールディング

アデノ随伴ウイルスは小型で無害なウイルスであり、そのタンパク質殻（カプシド）は遺伝子治療のデリバリーに使用できます。カプシドのタンパク質構造は重要です（例えば、治療が患者の免疫システムによってブロックされるかどうか影響します）が、非常に複雑でもあります。AlphaFold のような既存のタンパク質フォールディングモデルは個々のタンパク質を予測できますが、カプシドは数十個のタンパク質から構築されています。2つのオープンソースのタンパク質フォールディングモデルを基盤として、Claude Mythos 5.2 はカプシド全体の構造を正確に予測する新しい方法を発見しました。これらのモデルをタンパク質鎖の重複するグループに適用し、カプシドの既知の対称性に関する情報を使用してそれらをマージするコードを記述しました。

Claude の方法は、自然および人工のカプシドで機能しました（当社のテストでは、試行した34個中28個を正確にモデル化しました）。³ 3人の計算生物学者は、Claude のスキルが遺伝子治療の研究を加速するためにどのように使用できるかについて、次のコメントを共有しました。

数学

数学的形式化。 形式化とは、数学的証明をコンピュータが段階的に検証できる言語に翻訳するプロセスです。これにより、人間の数学者は手作業で検証する必要なく結果に自信を持つことができます（これは、AI モデルが人間には検証が難しい結果を生成する場合に特に重要です）。形式化は非常に手間のかかるプロセスであるため、AI が支援できれば、数学者は新しいアイデアを探求する時間をより多く費やすことができます。

当社初のフェルマーの最終定理の形式化は、リリースされていない研究バージョンの Claude によって行われ、11日かかりました。これは、専用のハーネスと人間の研究者のガイダンスに依存していました。対照的に、1,000体の Fable 5.2 エージェントのチームは、最小限の人間による介入で、わずか30時間で定理を完全に形式化しました。Fable 5.2 は最小限のプロンプトから開始し、独自の調整方法を構築し、数学的参照を使用せず、中間定理ステートメントのリストのみを使用して進捗をスコアリングしました。最初の形式化よりも3分の1のアクショントークンしか必要とせず、7倍短い証明を生成しました。下の図に見られるように、Opus 5.5（同じ1,000エージェントセットアップ）は18時間で形式化の26%しか完了せず、30時間後もほとんど進歩しませんでした。

形式化の詳細についてはこちらを参照してください。

ハードウェアとロボット工学

AI の潜在的な利点の多く（例えば、研究室の研究を加速すること）は、物理世界で動作する能力に依存しています。Claude Fable 5.2 は、現実世界でのモデルの有用性の向上という傾向を継続しており、ハードウェアデバイスの設計や物理ロボットの制御における実質的な進歩などのタスクで有望な結果を示しています。

ハードウェアエンジニアリング。 Fable 5.2 のハードウェアエンジニアリングスキルをテストし、1つの段落のプロンプトで、独自の回路基板、3Dプリントされた筐体、およびソフトウェアを備えた3つの動作する電子デバイスを設計・製造するように依頼しました。以下のデバイスは、回路基板の設計・製造を行う企業であるDiodeと協力して作成されました。これらは、ホームボイスアシスタントハブ、USBスピーカーフォン、およびハンドヘルド仮想ペットです。

Claude は独自の仕様を作成し、米国の販売業者から入手可能な電子部品を選択し、各デバイスの4層回路基板をルーティングし、コンピュータ支援設計で筐体をモデリングし、デバイスのソフトウェアをプログラムしました。各ボードは、最小限の人間による入力で1日以内に製造準備が整いました。Diode がボードを製造した後、Claude は同社のエンジニアにデバイスのテストと組み立てを指導しました。3つのデバイスすべてが、電気的な修正なしで動作しました。Claude のハードウェアエンジニアリングスキルに関する詳細はこちらで確認できます。

ロボット工学。 以前の Claude モデルと比較して、Fable 5.2 は物理ロボットの制御において大幅に改善されたスキルを示しています。これは、明示的にトレーニングされていないロボット工学タスクでも同様です。以下のビデオは、Fable 5.2 によって制御されたロボットが、パズルキューブを解く、ボトルキャップをねじって開ける、ロボットの絵を描くなど、さまざまなタスクを完了する様子を示しています。公開されているRoboDojoベンチマークでは、AI がカメラ画像からシミュレートされた2本腕ロボットをどのように制御できるかをテストしており、Fable 5.2 は同じハーネスで実行された他のフロンティアモデルや、ロボット制御専用に構築されたほとんどの AI システムを上回りました。

リサーチと分析

Claude Fable 5.2 をリサーチおよび分析タスクに使用した初期テスターは、以前のモデルよりも曖昧でデータ量の多いタスクを処理でき、特に抽象的な推論と設計を必要とする曖昧なタスクに対する判断力が向上したと述べています。プロプライエタリトレーディングファームの Jump Trading は、同社自身の研究で使用しているハーネスに似たハーネスに Fable 5.2 を組み込み、同社の定量研究タスクの一部に似たプロキシ評価で Fable 5.2 をテストしました。ある実行では、Fable 5.2 はコードライター、コーディネーター、プランナー、ジョブサブミッターといった必要なすべての役割を効果的に果たしました。以前のモデルでは、異なるモデルの強みと弱みに対応するために役割を手動で再調整するために、多大な時間投資が必要でした。

リサーチおよび分析組織の他のテスターからは、Fable 5.2 との経験について次のような声明が寄せられています。

安全性とアライメント

単一のテストでは、展開後に高度なモデルがどのように動作するかを知ることはできません。そのため、リリース前に多くの異なるテストと多くの種類の証拠に依存しています。Claude Fable 5.2 および Claude Mythos 5.2 の基盤となるモデルについては、デプロイ前の安全作業には、アライメントトレーニングとテスト、モデルの非協力的行動の傾向に関する新規評価、悪用に対するより強力なセーフガードの構築、行動監視のスケールアップが含まれます。モデルは、英国 AI 安全機関、Frontier Design、およびMETRを含む外部評価者によってもリリース前にテストされました。それらのレポートの概要⁴ および当社自身の安全および能力テストの詳細については、Claude Fable 5.2 および Mythos 5.2 システムカードを参照してください。

アライメントテスト

Claude Fable 5.2 および Claude Mythos 5.2 の行動アライメントの程度を評価するために、意図しない、潜在的に安全でない方法で動作する頻度をテストする評価スイートを実行しました。さまざまな評価全体で見たすべての証拠を考慮すると、ハイステークスな状況で安全でない方法で動作するリスクは低いと評価しています（他の最近のモデルと同様）。

Claude Mythos 5.2（特定のサイバーセキュリティまたは生物学のセーフガードなしの Fable 5.2 と同じ基盤モデル）を、約1,900のシナリオにわたるモデルの動作をテストする自動行動監査でテストしました。Claude Mythos 5.2 は、ほとんどの測定において、Opus 5.5、Sonnet 5.5、および Claude Mythos 5.1 と同等かそれ以上のパフォーマンスを示しました。例えば、ユーザーを誤解させるほとんどの測定において、これら3つのモデルよりも優れたスコアを記録しました。誤った入力、タスク完了の虚偽の主張、重要な情報の省略、および不十分または怠惰な作業の開示の失敗は、すべて Claude Mythos 5.2 で低下しました。⁵

最近の注目すべきサイバーセキュリティおよびアライメントインシデントの原因となった動作には、特に注意を払ってテストしました。例えば、Claude Mythos 5.2 は、Opus 5.5、Sonnet 5.5、および Mythos 5.1 よりも、バイアスのかかったまたは動機付けられた推論に従事する傾向が低いことがわかりました（そのような推論は、「シミュレーション内である」という証拠を「説明を回避」し、結果を現実的に理解せずにアクションを取ることを意味する可能性があります）。

サンドボックスからの脱出を試みるモデルの傾向をテストするために、複数の異なる評価を実行しました。以前使用した2つの評価では、Claude Mythos 5.2 は、テストした他のどのモデルよりも大幅に少ないサンドボックス脱出の試みを行いました。専用の評価（1,800以上のシナリオを含む敵対的実験で、ほとんどがサンドボックスからの脱出なしでは解決できず、サンドボックスには意図的な弱点がある）では、Claude Mythos 5.2 は、サンドボックスの外に配置した認証情報またはファイルを使用するシナリオが3.1%であり、Opus 5.5（3.3%）とほぼ同等、Sonnet 5.5（5.1%）よりも少なく、以前の Claude Mythos のイテレーション（それぞれ39%と21%）を大幅に下回りました。サンドボックスを説明したり、弱点を報告するツールを追加したりするなどの他の技術は、Claude Mythos 5.2 の脱出試行をさらに削減することがわかりました。他の測定（例えば、シミュレーション内であると誤って結論付けた後に有害な行動を取ることを含む）では、Claude Mythos 5.2 は Opus 5.5 よりもわずかに悪いスコアで、Claude Mythos 5.1 と同等でした。

モデルが展開される前にすべての失敗を確実に検出する評価を構築する問題は、未解決のままです。高度なモデルの評価の複雑さは、しばしば状況を不明瞭にします。例えば、Claude Mythos 5.2 と Fable 5.2 はそれぞれ、他のどの最近のモデルよりも頻繁に評価されていると疑いを表明しており、これは現実世界の設定でどのように動作するかを評価する能力に挑戦します。これらの設定が拡大し、将来のモデルで能力が増加するにつれて、この課題は増大すると予想されます。そのため、全体的な安全性の全体像を提供するために、これらの評価だけに依存するのではなく、トレーニング中の監視、内部使用のトランスクリプトのレビュー、外部評価者によるテスト、およびモデル内部で何が起こっているかを調査するための解釈可能性技術を活用しています。また、評価をより現実的にし、それらが何を見落としているかをよりよく理解するために取り組んでいます。

セーフガード

サイバーセキュリティと生物学のセーフガード。 以前の Claude Fable モデルと同様に、Fable 5.2 には、ペネトレーションテスト、エクスプロイト生成、バイナリベースの脆弱性検出など、高リスクのサイバーアクティビティや、研究生物学のほとんどのタスクをブロックする安全分類器が付属しています。クエリがブロックされると、ユーザーは代わりにサイバーセキュリティについては Opus 4.8、生物学については Opus 5 からの応答を受け取ります。Claude Fable 5.1 のリリース以来、安全分類器の誤検出を減らし続けています。claude.ai、Claude Code、および Cowork での初期テストに基づくと、Fable 5.2 は Fable 5.1 と比較してブロック数が約55%少なく（サイバーセキュリティで約60%、生物学で40%少なく）なりました。Claude Mythos 5.2 は、これらのデュアルユース分野で活動する検証済み組織に提供されます。

AI 研究開発。 Claude Fable 5.2 および Claude Mythos 5.2 の基盤となるモデルは、一般的な能力における一歩前進です。しかし、モデルのトレーニング中、AI 開発を最も直接的に加速できる特定の研究能力の進歩を制限するための措置を講じました。したがって、アクセラレータカーネル最適化や大規模言語モデルアーキテクチャの改善を含む関連分野では、Fable 5.2 および Claude Mythos 5.2 は Opus 5.5 レベルのパフォーマンスを示します。重要なのは、トレーニングの変更が、エージェントコーディング、ハードウェア開発、および従来の AI または機械学習研究（解釈可能性研究を含む）などの関連能力に影響を与えなかったことを確認したことです。モデルがユーザーに提供される際（つまり、推論時）にこれらの能力を変更することはありません。システムカードのセクション1.5¹ および以前のモデルと同様に、Fable 5.2 および Claude Mythos 5.2 には、このドメインの少数のトピック（特定の非標準アクセラレータ上のカーネル開発など）における Opus 5 への透明なフォールバックも含まれています。

アンチディストリレーション。 より高度なモデルの出力をトレーニングデータとして使用して高度なモデルの能力を抽出する蒸留は、しばしば数千の偽の Claude アカウントを伴い、産業規模で不正に行われています。蒸留は、Claude に組み込まれたセーフガードなしで高度な能力をリリースできるため、安全保障および国家安全保障上のリスクを生み出します（当社が検出および妨害した不正蒸留活動の詳細については、2026年9月の脅威インテリジェンスレポートを参照してください）。Fable 5.2 は、リリースしたどのモデルよりも蒸留に対する保護が最も強力です。これは、最近のレポートで説明した技術を使用しており、蒸留者が収集するデータを90%から99%削減しています。

不正な蒸留を防ぐ API 機能のロールアウトも拡大しています。保存された思考は、現在すべてのアカウントに適用されます。保存された思考は、蒸留者が Claude の以前のコンテキストを編集してその推論を抽出するのを防ぎます（開発者は、新しい API 機能で統合を更新する方法を学ぶために、保存された思考のドキュメントを参照できます）。

データプライバシーとエンタープライズフロンティアセーフガード

AI モデルの悪用のより複雑な形態の中には、複数のリクエストにわたるパターンを観察しないと検出できないものがあります。このため、Claude Fable 5.2 および Claude Mythos 5.2 のような強力なモデルは、使用状況データのウィンドウを監視するセーフガードに依存しています（個々の応答ではなく）。エンタープライズフロンティアセーフガードを使用すると、顧客のインフラストラクチャに保存されたプロンプトと応答に対して自動化された安全監視が実行され、ゼロデータ保持（ZDR）と互換性があります。エンタープライズフロンティアセーフガードは現在、Bridgewater、Salesforce、Stripe などの顧客とプライベートベータ版で提供されています。

エンタープライズ顧客は、アカウントチームに連絡するか、このフォームを完了することで、エンタープライズフロンティアセーフガードへのアクセスをリクエストできます。適格な顧客は、EFS による安全監視を実装する前に、ゼロデータ保持で Claude Fable 5.2 および Claude Mythos 5.2 を引き続き使用できます。その他の顧客については、安全監視のために30日間の保持期間があります。

利用可能性

Claude Fable 5.2 は、Amazon Web Services、Google Cloud、Microsoft Azure を含むすべてのプラットフォームで本日より利用可能です。開発者は、Claude Platform の claude-fable-5-2 で利用を開始できます。

今週、対象となる有料プランの加入者には、追加の Fable 利用特典を提供します。Fable モデルを含むプランとシートは、サブスクリプション期間に応じて1〜3回の Fable リセットを受け取ります。また、Pro プランおよび Team プランの標準シートでは、Fable は週の利用制限の最大50%に含まれます。Fable 5.2 のローンチプロモーションの詳細についてはこちらを参照してください。

サイバーセキュリティ専門家は、サイバー検証プログラムを通じて Claude Mythos 5.2 へのアクセスを申請できます。Claude Enterprise の顧客は、Claude Mythos 5.2 を含む当社の全モデルファミリーを搭載したClaude Securityも利用できます。ライフサイエンス研究者も、ライフサイエンス検証プログラムを通じて申請できます。

Claude Fable 5.2 および Claude Mythos 5.2 の高速モードは、Claude Code、Claude Platform、Google Cloud 上の Claude モデル（Anthropic 管理および Google 管理）、および Microsoft Foundry（Anthropic ホスト）で利用可能です。Claude Mythos の高速モードへのアクセスは、検証プログラムに参加している組織のみが利用できることに注意してください。

---

[2] タイトル: 集計値は関数であり、合計ではない
URL: https://alnovis.io/blog/aggregate-is-a-function
本文:

集計値は関数であり、合計ではない

レシートのストリームに対するレポート

私が働くシステムは、販売レシートを保存しています。すべてのレジからのレシートは Kafka を通じて到着し、ClickHouse がドキュメントとして保存します。

生のドキュメントの上には、人々が実際に目にするレポートがあります。レジ係のシフトごとの合計、店舗の時間ごとおよび日ごとの合計、マーチャントがレシートに付けるカスタムフィールドでグループ化された収益です。

これは標準的な ClickHouse のユースケースのように見えます。行を挿入し、それらを集計します。これには4回の試行が必要でした。

難しさの原因は、量ではなく、ストリームの3つの特性にあります。

レジで印刷された日時 1週間前に印刷 Kafka 経由で配信されるまでに1回、同じレシートが2回配信される late pipeline ダウンタイムはレシート1枚分です。一番上に印刷され、一番下に配信されます。通常のものは数秒かかります。

• ドキュメントが2回配信される。 Kafka の配信は少なくとも1回です。バッチが途中で失敗した場合、コンシューマーは再試行し、同じレシートが再度挿入されます。「挿入されたものの合計」はすべて間違っています。
• ドキュメントが遅延して配信される。 ほとんどのレシートは数秒以内に到着しますが、1週間オフラインだったレジがバックログを再接続時に送信します。ドキュメントの少量だが安定した割合は1日以上遅れて到着し、一部は1ヶ月遅れます。先週火曜日のレポートは決して最終になりません。
• パイプラインが停止する。 集計を計算するものは、デプロイ、ノードの再起動、バグなどにより、時々ダウンします。復旧した際には、何も失われていない必要があります。

レポートにはレイテンシ予算もあります。インタラクティブな呼び出しは数秒で応答し、数百のレジにわたる重いレポートは30秒未満で応答する必要があります。

4回の試行

1. 挿入時に合計する

最初のバージョンは古典的なものでした。挿入時のマテリアライズドビューで、部分的な合計を SummingMergeTree に書き込みます。各挿入はその貢献を追加し、バックグラウンドマージが行を折りたたみ、レポートは事前集計された行を読み取ります。

Kafka バッチ: レシート1234、500 コンシューマー挿入 SummingMergeTree 時間合計: 500 バッチが途中で失敗、再試行 Kafka 同じバッチが再度配信 コンシューマー再度挿入 SummingMergeTree 時間合計: 1000

2回目の挿入は合計に追加されるだけで、置き換えられません。合計には、どの500が2回含まれたかを示すものはありません。

高速ですが、再配信されたレシートは合計を2回追加し、一度加算された2つの数値から正しい方を後で減算する方法はありません。集計値は、どのドキュメントがそれに貢献したかを記録しません。

2. ワイドテーブルから再計算する

2番目のバージョンは、再計算によって重複カウントの問題を修正しました。更新可能なマテリアライズドビューが、重複をドキュメントキーで折りたたむことで、最近変更されたシフトと時間の合計を定期的に再構築しました。

このバージョンは正確でした。しかし、メインのドキュメントテーブルを読み込みました。これはワイド（ペイロード、ステータス、数十列）で、レジとドキュメントキーでソートされており、時間順ではありません。

再計算は日付でフィルタリングしましたが、ClickHouse では日付でソートされていないテーブルの日付フィルタリングは、パーティション全体をカットしますが、グラニュールはカットしません（グラニュールについては後述）。1回のパスで4,600万行を読み込み、508,000行を使用しました。

古い月 スキップ 現在の月全体、レジ順、次にドキュメント番号順 レジ1 レジ2 レジ3 レジ4 レジ5 レジ6 新しい順 日付フィルタ 0 グラニュール読み込み 6/6 グラニュール読み込み 全て、各グラニュールの最新の数行のみ

模式図。日付は月をまたいでカットしますが、月の中ではすべてのグラニュールを通過します。

本番環境では、パスがクエリごとのメモリ制限に達し始め、繰り返し失敗しました。

3. すべてのキーを記憶する

3番目のバージョンは、挿入時の合計に戻り、重複を不可能にしようとしました。レシートを追加する前に、そのキーが以前に見られたかどうかを確認します。キー検索は、最近のキーのテーブルに対する ClickHouse ディクショナリとして実装されました。

ディクショナリはメモリ内に存在し、キーは小さくありません。テストクラスターでは161バイトです。各レジの1ヶ月分のキーは、本番環境のメモリに収まりませんでした。ディクショナリのロードに失敗しました。その後、すべての挿入が失敗しました。

1ヶ月分のキーがメモリに大きすぎる ディクショナリのロードに失敗 挿入はその行を書き込み、失敗する コンシューマーが同じバッチを再度試行する たびに レシート1234 ストレージ内 コピー1 コピー2 コピー3 コピー4 そしてカウントアップ

リトライごとに行が書き込まれてから失敗したため、各リトライはさらに1つのコピーを保存しました。

4. 何も保存しない

4番目のバージョンは、保存された集計値自体をすべて諦めました。読み取り時にドキュメントからすべてのレポートを計算し、ドキュメントキーでの GROUP BY で重複を折りたたみます。同期が外れる状態はなく、再配信や遅延ドキュメントは無料で処理されます。

それは正確でしたが、チューニングでは修正できないほど遅かったです。600シフトにわたるレポートは、約35億行を読み込みました。テストクラスターでは、99パーセンタイルで次のようになりました。

失敗に共通していたこと

3つの本番環境の失敗は、集計値を保存したことによって引き起こされたものではありません。

集計値を保存する 合計は修正できない 過剰な読み取り キーをすべて記憶する 1. 挿入時に合計する 2. ワイドテーブルから再計算する 3. すべてのキーを記憶する 4. 何も保存しない 私たちが望んでいたこと

各本番環境の失敗は独自の列にあり、最初の列にはありません。最後の行は、探していた設計です。

試行4はストレージを削除し、すべての読み取りでその代償を払ったため、試行2と同じ失敗につながりました。

したがって、問題は次のようになりました。集計値を保存し、キーを記憶せずに重複を乗り越え、ドキュメントテーブル全体を読み取らずに再計算することは可能か？

短い寄り道: グラニュール

読み取り量がなぜそれほど重要なのかを理解するには、ClickHouse がどのように読み取るかを知ることが役立ちます。

MergeTree テーブルはパーツに分割され、各パーツはデフォルトで8,192行のグラニュールに分割されます。プライマリインデックスはスパースです。各グラニュールのキーを格納しますが、行ごとではありません。

スパースプライマリインデックス: 各グラニュールの最初のキー A, 0001 A, 5230 B, 0410 B, 8812 C, 0007 1つのパーツ グラニュール1 (8192行) グラニュール2 (8192行) グラニュール3 (8192行) グラニュール4 (8192行) グラニュール5 (8192行) WHERE register = 'B': グラニュール2がBで終わる可能性があるため、2、3、4を読み込む

インデックスは各グラニュールがどこで始まるかを知っていますが、その中身は知りません。

クエリがプライマリキーでフィルタリングすると、ClickHouse は一致する行を含む可能性のあるグラニュールを見つけて、それらをまとめて読み込みます。スキップインデックス（例えば、日付列の minmax）は、グラニュール内の値が互いに近い場合にのみ、より多くのグラニュールを破棄できます。

したがって、クエリが読み取るものは、行のレイアウト方法に、必要な行数よりもはるかに大きく依存します。必要な行がテーブル全体に散らばっている場合、それらの周りのグラニュールを読み込みます。

時間順にソート: 必要な行はどこにでもある 8/8 グラニュール読み込み レジスタ順にソート: 同じ行がまとまっている 2/8 グラニュール読み込み

両方のレイアウトで同じ12行。ソート順のみが異なります。

当社の読み取り時計算の試行では、狭い小売テーブルは時間順にソートされていました。1時間以内では、数千のレジのレシートがインターリーブされていたため、150レジのレポートは1ヶ月のほぼすべてのグラニュールに触れました。

クエリ形状で満たすことが不可能な「読み取られた行数」の制限という、独自の受け入れ基準さえ書き直す必要がありました。なぜなら、境界グラニュールには常に他人の行が含まれているからです。

逆もまた真なり。1つの作業単位の行が隣接している場合、それらを読み取るコストは少数のグラニュールで済みます。最終的な設計はこのことに依存しています。

採用した設計では、集計値は挿入の実行中の合計ではなく、ドキュメントの関数です。

最小限の有用な集計単位であるセルを考えます。

case class CellKey(register: RegisterId, shift: Int, hour: Instant) // hour in UTC

各ドキュメントは正確に1つのセルに属し、そのリンクはどこにも保存されていません。これはドキュメントの3つの列から計算されます。

key(d) = ( register(d), shift(d), hour(t(d)) ) ドキュメントが属するセル。t(d) はドキュメント自身の時間、hour() はそれを時間に切り捨てる。
D(k) = { d : key(d) = k } セル k のすべてのドキュメント。保存されたリンクではなく、ルールによって見つけられる。
L(k) = { argmaxv ∈ D(k), id(v) = id(d) w(v) : d ∈ D(k) } 各ドキュメントについて、最新の書き込み時刻 w を持つバージョン。再配信されたドキュメントはここで折りたたまれる。
V(k) = Σd ∈ L(k) m(d) 各メジャー。最初と最後の数値および日付は min と max を取る。

コードでも同様です。

def key(d: Document): CellKey =
  CellKey(d.register, d.shift, d.date.truncatedTo(HOURS))

def docs(k: CellKey): Seq[Document] =
  allDocuments.filter(d => key(d) == k)

def value(k: CellKey): Measures =
  docs(k)
    .groupBy(_.id)
    .values
    .map(_.maxBy(_.writtenAt))        // a re-delivered document collapses here
    .foldLeft(Measures.empty)(_ + _)  // sums, counts, min, max

セルの値はいつでも再計算できます。なぜなら、ドキュメントはまだ存在し、ルールは同じだからです。新しい計算は新しい行として書き込まれ、再計算時刻によってバージョン付けされ、ReplacingMergeTree で古いものを置き換えます。

これにより3つの特性が得られます。

• 再配信されたドキュメントは何も変更しない。 再計算中、1つのドキュメントの行はドキュメントキー（書き込み時刻による argMax）で折りたたまれます。2回の配信は1行になり、セルの値は同じままです。ディクショナリもキーテーブルも、見たものを記憶する必要もありません。
• 2回再計算しても無害。 新しいドキュメントがないセルを再計算しても、同じ値が生成されます。1つのノードで、同時に実行される2つの再計算は両方ともバージョンを書き込み、後から開始した方が少なくとも多くを見ており、勝者となります。レプリカは別の話です（「コスト」を参照）。
• 遅延ドキュメントは失われない。 1ヶ月遅れのレシートは、その月のセルを「ダーティ」としてマークし、そのセルは次のパスで再計算されます。

セルのメジャーはセル間でマージされます。セル内のすべてのメジャーは合計、カウント、min、または max です。各ドキュメントは正確に1つのセルに属します。したがって、任意のセルのセットに対するレポートは、重複カウントなしで、それらの値の組み合わせにすぎません。

11:00 12:00 13:00 14:00 レジスタB シフト1 2 70 110 90 130 レジスタA シフト7 75 120 80 200 150 時間14:00 店舗 130 + 150 = 280 シフト75 レジスタA 120 + 80 + 200 + 150 = 550 日 24時間 月 毎日 合計とカウントは加算されます。minとmaxは最初と最後のドキュメント番号と日付を保持します。

同じセルが異なる軸で合計されます。週、四半期、または任意の店舗セットも同様の加算になります。

これらのいずれも独自のテーブルを必要としません。新しいレポートは、同じセルに対する新しいクエリです。タイムゾーンでさえ、UTCからのオフセットが固定された整数時間であれば機能するはずです。なぜなら、ローカルの日の境界線は依然として時間の境界線だからです。

これは退屈な方法で確認しました。セルから組み立てられた時間、日、シフトは、ドキュメントから直接計算されたレポートと同じレポートと一致しました。209のすべてのメジャーで一致しました。

レシートだけではない

このパターンは、レジやレシートに限定されません。

これには3つのものが必要です。各イベントは、そのセルのキーを計算するために必要なすべてを運び、イベントが再度配信されたときにそのキーが変わらず、メジャーが合計される（少なくともマージされる）こと。それらが当てはまる場合、集計値は実行中の合計ではなく、イベントの関数になります。

ClickHouse での実現

作業のほとんどは ClickHouse のメカニズムにありました。

Kafka 少なくとも1回 コンシューマー バッチごとに1つの挿入 レジスタのシャード上のドキュメント レジスタごとのドキュメントの絞り込み ダーティセルジャーナル 1回の挿入で書き込まれたセル、いつから、いつまでマーク 再計算、30秒ごと セル レジスタ、シフト、時間 30秒ごと セルからシフト レポート セルとシフトを読み取る

ドキュメント、その絞り込みコピー、およびそのダーティマークは、1回の挿入によって書き込まれます。それ以降のすべては再計算です。

正しい順序の絞り込みテーブル

再計算は、ワイドなドキュメントテーブルを読み込むことはありません。マテリアライズドビューは、各ドキュメント行を、メジャーに必要な列のみを含む狭いテーブルにコピーし、(register, document number) でソートします。

そのキーに時間列はありません。必要ありません。レジスタは発行順にドキュメントを番号付けするため、1つのレジスタの1時間分のドキュメントは、各パーツ内で隣接します。セルのドキュメントを見つけるのは、短い範囲のスキャンです。当社のテスト履歴で最も密度の高いセル（約5,000ドキュメント）は、20グラニュールを読み込み、7ミリ秒で完了します。ワイドテーブルから同じ1分間のトラフィックを読み取るのと比較して、狭いテーブルは30〜37倍少ない行を読み込みます。

同じ挿入で書き込まれるジャーナル

同じ挿入に対する2番目のマテリアライズドビューは、タッチされた各セルにダーティマークを書き込みます。セルキーとマークの時刻です。合計はなく、「このセルを再計算する必要がある」というだけです。

両方のビューはドキュメント自体と同じ挿入の一部として実行されるため、当社のコードには「ドキュメントが保存された」と「セルがマークされた」の間に別個のステップはありません。ただし、これはトランザクションではありません。ClickHouse はソーステーブルとそのビューを順番に書き込み、ドキュメントが保存された後にビューが失敗した場合、挿入はエラーを報告し、ドキュメントはすでに配置されています。当社のコンシューマーはバッチを再試行します。通常、これはマークを再度書き込み、重複ドキュメントはここでは無害です。リトライがレプリケートされたテーブルの挿入重複排除とどのように連携するかは確認していません。重複ブロックがビューの実行前にドロップされた場合、マークは失われ、セルは再計算されません。

ドキュメントのステータス更新は日付とシフトなしの別個の行として到着し、ビューはそれらをスキップするため、ステータスが再計算をトリガーすることはありません。セル内のどのメジャーもステータスに依存しません。

ジャーナルはセルでキー付けされた ReplacingMergeTree であるため、1つのセルの重複マークは最新の時刻を持つ1行に折りたたまれます。小さな挿入では、セルあたり約14マーク/時間でしたが、折りたたみ後は1.16になり、メインの再計算パスは5倍安価になりました。

「再計算済み」はデータ内に存在する

更新可能なマテリアライズドビューは30秒ごとに実行され、必要なセルを再計算します。進捗を追跡する一般的な方法はカーソル、「時間 T まで処理済み」です。これを使用しませんでした。

代わりに、各パスはデータ自体から取得した2つの時刻を比較します。

M(k) = max { t : (k, t) ∈ journal } セル k の最新マーク
R(k) = max { t : (k, t) ∈ cells } セル k の最新再計算、または0（まだ計算されていない場合）
dirty = { k : M(k) > R(k) − 60 s } 最新の再計算後にマークされた、60秒のオーバーラップ付き
pass = { (k, V(k), now) : k ∈ oldest(dirty, 50 000) } セルごとの新しいバージョン

コードでも同様です。

def lastMark(k: CellKey): Instant =
  journal.marks(k).max

def lastRecompute(k: CellKey): Instant =
  cells.versions(k).maxOption.getOrElse(Instant.EPOCH) // never computed yet

def dirty(k: CellKey): Boolean =
  lastMark(k).isAfter(lastRecompute(k).minusSeconds(60))

def pass(): Seq[Cell] =
  journal.keys
    .filter(dirty)
    .sortBy(lastMark)
    .take(50_000)
    .map(k => Cell(k, value(k), recomputedAt = Instant.now()))

まだ計算されていないセルはバージョンがないため、エポックに計算されたと見なされ、最初のマークでダーティになります。

カーソルは書き込みとアトミックに移動する必要があり、リトライ、並列実行、再起動で破損します。比較はこれらのいずれにも影響されません。最大1日間の停止後、次のパスは最後の再計算後にマークされたすべてのセルを見つけます。60秒のオーバーラップは、1つの挿入の一部がわずかに異なる瞬間に表示されるという事実をカバーしており、マークがドキュメントの直前に表示される可能性があります。代償は、時折追加の再計算です。

パスは、再計算するセルのドキュメントのみを読み込みます。

重なってはならない2つのウィンドウ

メインパスは過去2時間のマークを見ます。2番目のキャッチアップビューは10分ごとに実行され、2時間から1日までのマークを見ます。これは2時間以上の停止用です。

ウィンドウは重なってはなりません。初期バージョンでは重なっており、停止後、両方のビューが同じセルを同時に取得しました。1ノードあたり26秒と2 x 2.8 GB のメモリを消費し、本来1回で済む作業でした。

スナップショット時刻によるバージョン付け

セルの行のバージョンは、ドキュメントの最新の書き込み時刻ではなく、再計算クエリが開始した時刻です。最初にこれを試しました。同じ秒に書き込まれた多くのドキュメントと、密接に実行される再計算により、バージョンの順序が未定義になりました。後続のスナップショットは、前のスナップショットよりも少なくとも多くのドキュメントを見るため、スナップショット時刻は常に正しいバージョンです。

「少なくとも多く」は、同じノードで取得されたスナップショットに当てはまります。レプリカ間では当てはまらず、これが設計全体の最も弱い点です。

ドキュメントではなくセルからシフトを組み立てる

シフトは、2番目の更新可能なビューによってセルから組み立てられます。シフトの各セルの最新行を取得し、メジャーを合計し、数値と日付の min と max を取得します。忙しいレジスタはシフトあたり142,000ドキュメントを持つことがあり、一部のシフトは数ヶ月間開いたままです。新しいレシートごとにシフトをドキュメントから再構築すると、すべてを再読み込みすることになります。セルからは、シフトの1時間あたり1行を読み込みます。

FINALなしでの読み取り

リーダーは、キーごとに最新の行を LIMIT 1 BY キーで取得し、再計算時刻でソートし、各シャードのローカルテーブルに対してそのサブクエリを実行します。1つのレジスタ（ドキュメント、マーク、セル、シフト）に属するすべては同じシャードに存在するため、「最新の行」はローカルで正しく決定され、バックグラウンドマージを待つ必要はありません。

つまずいた点

バックフィルがシフトビューを氾濫させる

77日間の履歴のセルを一度に埋めたとき、埋められた各セルはシフトビューにとって「最近再計算された」ように見えました。その後、数百万のセルを再グループ化するために2時間費やし、何も新しいものを書き込みませんでした。

最初のバックフィル バックフィルは77日分のセルを書き込む recomputed_at = now シフトビューはそれらを再計算済みとして認識 レジスタごとのセルを再グループ化 88M 行、0.5 コア/パス バックフィル修正済み バックフィルは77日分のセルを書き込む recomputed_at = now - 2 days シフトビューはそれらを2日前と認識 スキップする 4M 行、CPU はほとんど使用しない

バックフィルされた行は現在、2日前の再計算時刻を取得し、両方のウィンドウの外側にあります。シフトビューは、パスあたり8800万行とコア半分から、400万行とほとんど何も使用しないようになりました。

挿入ビュー内のサブクエリでのフィルタリング

ClickHouse 26.3 で、挿入ビューが列値をシフトして書き込むのを確認しました。3つの要因が組み合わさりました。ソース列名と一致する出力エイリアス、同じクエリでのフィルタリング、およびドキュメントとステータス行が混在するブロックです。

フィルタをサブクエリに移動することで修正され、それに対するテストがあります。

-- 値がシフトして出力された
CREATE MATERIALIZED VIEW docs_mv TO docs AS
SELECT register_id, doc_number, ifNull(total, 0) AS total, ...
FROM transactions
WHERE type IS NOT NULL;

-- 修正済み
CREATE MATERIALIZED VIEW docs_mv TO docs AS
SELECT register_id, doc_number, ifNull(total, 0) AS total, ...
FROM (SELECT * FROM transactions WHERE type IS NOT NULL);

ワイド行ではグラニュールサイズが重要

セルには約250列があり、小売レポートは189列を読み取ります。デフォルトのグラニュールサイズ8,192行で、150レジスタのクエリは22,000セルを使用するために約1.1 GB を展開しました。

セルテーブルのグラニュールと圧縮ブロックを小さくすると:

SETTINGS index_granularity = 1024,
         min_compress_block_size = 8192,
         max_compress_block_size = 65536

同じクエリは約0.3 GB を展開し、CPU はディスク使用量が9%増加した代わりに約30%減少しました。

ドキュメントごとではなく、集計値ごとに1つの状態

各列ごとに個別の argMax でドキュメントを折りたたむと、ドキュメントごとに多数の集計状態が構築されます。タプル列に対する1つの argMax は1つを構築します。

-- 列ごとに1つの状態
SELECT doc_key,
       argMax(total, updated_at),
       argMax(cash, updated_at),
       argMax(card, updated_at),
       ...
FROM docs GROUP BY doc_key;

-- ドキュメントごとに1つの状態
SELECT doc_key,
       argMax((total, cash, card, ...), updated_at) AS doc
FROM docs GROUP BY doc_key;

数値

テストクラスターは小さいです。2つのシャードを1台のマシンで実行し、6つの物理コア、ClickHouse ノードあたり5 CPU の制限、数万のレジスタ、77日間の履歴があります。レポートレイテンシ、99パーセンタイル:

読み取り時にドキュメントから計算されたセル 30秒 レポート予算 1クライアント 4クライアント 600シフトごとのキー 時間ごとの小売、150レジスタ 日ごとの小売、150レジスタ フィールドごとの収益、50レジスタ 600シフトごとのキー、クライアント1台: セル 2.1秒 2.1 600シフトごとのキー、クライアント1台: ドキュメントから 23.4秒 23.4 時間ごとの小売、クライアント1台: セル 2.5秒 2.5 時間ごとの小売、クライアント1台: ドキュメントから 17.0秒 17.0 日ごとの小売、クライアント1台: セル 1.3秒 1.3 日ごとの小売、クライアント1台: ドキュメントから 14.3秒 14.3 フィールドごとの収益、クライアント1台: セル 0.6秒 0.6 フィールドごとの収益、クライアント1台: ドキュメントから 7.9秒 7.9 600シフトごとのキー、クライアント4台: セル 2.7秒 2.7 600シフトごとのキー、クライアント4台: ドキュメントから 119秒 119 時間ごとの小売、クライアント4台: セル 6.1秒 6.1 時間ごとの小売、クライアント4台: ドキュメントから メモリと時間制限で失敗 メモリと時間制限で失敗 日ごとの小売、クライアント4台: セル 3.7秒 3.7 日ごとの小売、クライアント4台: ドキュメントから、すべての呼び出しで180秒でタイムアウト 180秒でタイムアウト フィールドごとの収益、クライアント4台: セル 1.6秒 1.6 フィールドごとの収益、クライアント4台: ドキュメントから 100秒 100

p99応答時間、ログスケール。空のマーク: 回答なし。

セルから生成されたすべてのレポートは予算線の左側にあり、負荷がかかっても同様です。ドキュメントから生成された場合、クライアント4台で十分な負荷がかかり、すべてのレポートが予算を超えました。

同じ数値をテーブルで表示

600シフトレポートは、35億行ではなく最大36万行を読み込みます。セルに対するすべてのレポート呼び出しは、必要な行の理論上のグラニュール境界の2倍以内に収まります。

正確性は、独立した参照に対してチェックされました。1,000レジスタの各日、シフト、時間、月の期待値は、サービスなしでロードジェネレーターによって計算されました。

負荷を段階的に増やした3時間のライブトラフィックの後、最後の負荷は最初の3倍でしたが、31回のチェックでゼロの不一致がありました。

コスト

これらは設計上のトレードオフと、私たちが知っているギャップです。

単独で処理される 手助けが必要 75-115秒以内に停止なし 2時間未満のダウンタイム メインビューがキャッチアップ 2時間から1日 キャッチアップビュー 1日から7日 7日以上の手動パス マークが期限切れ 2時間 1日 7日 再計算が停止していた期間

ウィンドウは停止期間の長さを制限しますが、ドキュメントの遅延時間を制限するわけではありません。

• ラグ。 レポートは、通常75〜115秒後に、1〜2回のパス後に新しいドキュメントを確認します。読み取り時に保留中のテールを計算しないことにしました。
• 長時間の停止には手助けが必要。 1日以上前のマークは自動的に拾われません。ジャーナルは7日間マークを保持するため、手動パスを実行する時間があります。
• レプリカは独自に再計算し、それが穴です。 更新可能なビューは各シャードのレプリカで実行され、各レプリカはドキュメントとジャーナルの独自のコピーを参照します。これらは別々にレプリケートされます。レプリカは、ドキュメントよりも前にマークを確認し、そのドキュメントなしでセルを再計算し、他のレプリカからの正しいバージョンよりも後の時刻で結果にスタンプを付ける可能性があります。後のスタンプが勝ちます。ギャップが60秒のオーバーラップよりも長くなった場合、次のドキュメントまでセルを再度マークするものはありません。遅延ドキュメントの場合、これは決して起こらない可能性があります。当社のテストクラスターにはシャードごとに1つのレプリカがあったため、そこでは表示されませんでした。紙の上で、この投稿を書いている間に発見しました。修正策として、シャードごとに1つのレプリカに再計算させる、バージョンをクロックではなくドキュメントから導出する、またはスタンプに関係なく毎日昨日のセルをスイープする、などが考えられます。
• 再試行された挿入はマークを失う可能性があります。 ビューがドキュメント保存後に失敗した場合、バッチは再試行され、レプリケートされたテーブルでは挿入重複排除がビューの実行前に重複ブロックをドロップする可能性があります。その後、次のドキュメントまでセルをマークするものはありません。これはまだ確認していません。
• マージ可能なメジャーのみ。 合計、カウント、min、max はセル間でマージされます。正確なユニークカウントと正確な中央値は、単純な数値としては合計されません。ClickHouse は、数値の代わりにセルにマージ可能な集計状態を保持できます。uniqState と quantileState は、uniqMerge と quantileMerge と組み合わせてセル間で（近似的に）結合され、比較的少ないストレージで済みます。正確なバリアントもマージされますが、すべての値を保持します。当社のレポートは今日これらを必要としませんが、もし必要になった場合、セルはこのような状態を保持できます。
• バックフィルは手順です。 既存の履歴のセルは、約1時間半かかる別のスクリプトによって構築されます（当社の77日間のテスト履歴の場合）。

締めくくり

各試行は前の失敗を修正し、次の問題に遭遇しました。重複、散らばった読み取り、重複排除のためのメモリ、そして最終的にはすべてのリクエストで読み取るコストです。

これらはどれも新しいものではなく、もっと早く知ることができたはずです。データベースでは、これを増分ビューメンテナンスと呼びます。変更が触れたマテリアライズド結果の部分を記録し、それらの部分のみを再計算し、古い値を置き換えます。Oracle のパーティション変更追跡は、マテリアライズドビューに対してまさにこれを行います。そして、1995年の調査ではすでに手法がカタログ化されていました。私たち自身の部分は、セルの選択、そしてマーク、バージョン、および「再計算済み」フラグを ClickHouse テーブル自体内に保持することだけです。

最終的に機能したのは新しい ClickHouse 機能ではなく、集計値の異なる意味でした。集計値が挿入の合計である限り、すべての重複とすべての遅延ドキュメントは、覚えておく必要がある修正です。それがドキュメントの関数である場合、重複または遅延ドキュメントは修正を必要としません。セルは再度計算されます。