ReplacingMergeTree
このエンジンは、同じソートキー値（ORDER BY テーブルセクション、PRIMARY KEY ではない）を持つ重複エントリを削除する点でMergeTreeと異なります。
データの重複排除は、マージ中のみに発生します。マージは、未知の時点でバックグラウンドで行われるため、それを計画することはできません。一部のデータは処理されないまま残る場合があります。OPTIMIZE クエリを使用して、予定外のマージを実行することはできますが、OPTIMIZE クエリは大量のデータを読み書きするため、これを頼りにしないでください。
したがって、ReplacingMergeTree は、スペースを節約するためにバックグラウンドで重複データをクリアするのに適していますが、重複の不在を保証するものではありません。
最適化やベストプラクティスに関する詳細なガイドは、こちらをご覧ください。
テーブルの作成
リクエストパラメータの説明については、ステートメントの説明を参照してください。
行のユニーク性は、ORDER BY テーブルセクションによって決定され、PRIMARY KEY ではありません。
ReplacingMergeTree パラメータ
ver
ver — バージョン番号を持つカラム。型は UInt*、Date、DateTime または DateTime64。オプションのパラメータです。
マージ時に、ReplacingMergeTree は同じソートキーを持つ行の中から一つだけを残します：
verが設定されていない場合、選択内の最後の行が残ります。選択は、マージに参加しているパーツの行のセットです。最も最近作成されたパーツ（最後の挿入）が、選択の中で最後のものになります。したがって、重複排除後には、最も最近の挿入からの行がそれぞれのユニークなソートキーに対して残ります。verが指定されている場合は、最大バージョンのものが残ります。同じバージョンの行が複数ある場合、verが指定されていない場合のルールが適用されるため、最も最近の挿入された行が残ります。
例：
is_deleted
is_deleted — マージ時にこの行のデータが状態を表すか削除されるべきかを判断するために使用されるカラムの名前。1 は「削除された」行、0 は「状態」行を表します。
カラムのデータ型は UInt8 です。
is_deleted は、ver が使用されている場合のみ有効にできます。
行は OPTIMIZE ... FINAL CLEANUP の場合にのみ削除されます。この CLEANUP 特殊キーワードは、allow_experimental_replacing_merge_with_cleanup MergeTree設定が有効になっていない限り、デフォルトでは許可されていません。
データに対する操作にかかわらず、バージョンは増加しなければなりません。同じバージョン番号の挿入された行が2つある場合、最後に挿入された行が保持されます。
例：
クエリ句
ReplacingMergeTree テーブルを作成する際には、MergeTree テーブルを作成する際と同様の句が必要です。
テーブル作成のための廃止された方法
新しいプロジェクトではこの方法を使用せず、可能であれば古いプロジェクトを上記の方法に切り替えてください。
verを除くすべてのパラメータは、MergeTree と同じ意味を持ちます。
ver- バージョンを持つカラム。オプションのパラメータ。詳細は上記のテキストを参照してください。
クエリ時の重複排除 & FINAL
マージ時に、ReplacingMergeTree は重複行を特定し、テーブル作成に使用された ORDER BY カラムの値をユニーク識別子として使用し、最高のバージョンのみを保持します。ただし、これは最終的な正確性のみを提供し、行が確実に重複排除されることは保証されませんので、これを信頼しないでください。したがって、クエリは、更新および削除された行がクエリに考慮されるため、不正確な結果を生成する可能性があります。
正確な結果を得るためには、ユーザーはバックグラウンドマージとクエリ時の重複排除および削除を補完する必要があります。これは、FINAL 演算子を使用することで達成できます。以下の例を考えてみてください：
FINALなしでクエリをすると、不正確なカウントが得られます（正確な結果はマージに依存して変動します）：
FINALを追加すると、正しい結果が得られます：
FINALの詳細や性能を最適化する方法については、当社の詳細ガイドをご覧いただくことをお勧めします。