メインコンテンツまでスキップ
メインコンテンツまでスキップ

ReplacingMergeTree

このエンジンは、MergeTreeと異なり、同じソートキー値（ORDER BYテーブルセクション、ではなくPRIMARY KEY）を持つ重複エントリを削除します。

データの重複削除は、マージ中にのみ発生します。マージは不明な時間にバックグラウンドで行われるため、計画を立てることはできません。一部のデータは未処理のまま残ることがあります。OPTIMIZEクエリを使用して非スケジュールのマージを実行することができますが、大量のデータを読み書きするため、これを利用することは期待しないでください。

したがって、ReplacingMergeTreeは、スペースを節約するためにバックグラウンドで重複データをクリアするのに適していますが、重複が存在しないことを保証するものではありません。

注記

ReplacingMergeTreeに関する詳細なガイド、ベストプラクティス、パフォーマンスの最適化方法については、こちらをご覧ください。

テーブルの作成​

リクエストパラメータの説明については、ステートメントの説明を参照してください。

注記

行の一意性は、PRIMARY KEYではなく、ORDER BYテーブルセクションによって決まります。

ReplacingMergeTreeのパラメータ​

ver​

ver — バージョン番号を持つカラム。型はUInt*、Date、DateTimeまたはDateTime64。オプションのパラメータです。

マージ時に、ReplacingMergeTreeは同じソートキーを持つすべての行から1つだけを残します：

  • verが設定されていない場合は、選択内の最後の行が残ります。選択とは、マージに参加するパーツのセット内の行の集合です。最も最近作成されたパート（最後の挿入）が選択内の最後の行になります。したがって、重複削除後は、各ユニークなソートキーに対して、最新の挿入から最後の行が残ります。
  • verが指定されている場合は、最大バージョンの行が残ります。複数の行が同じverを持つ場合、それに対して「verが指定されていない場合」と同じルールが適用されるため、最も最近挿入された行が残ります。

例：

is_deleted​

is_deleted — マージ中に、データがこの行における状態か、削除されるべきかを判定するために使用されるカラムの名前；1は「削除された」行、0は「状態」行です。

カラムのデータ型はUInt8です。

注記

is_deletedは、verが使用されている場合にのみ有効にできます。

データに対する操作に関わらず、バージョンは増加させる必要があります。挿入された2つの行が同じバージョン番号を持つ場合、最後に挿入された行が保持されます。

デフォルトでは、ClickHouseはキーに対して最後の行を保持します。たとえその行が削除行であってもです。今後の低バージョンの行が安全に挿入できるようにし、削除行が適用され続けるからです。

このような削除行を永続的にドロップするには、テーブル設定allow_experimental_replacing_merge_with_cleanupを有効にし、次のいずれかを行います：

  1. テーブル設定enable_replacing_merge_with_cleanup_for_min_age_to_force_merge、min_age_to_force_merge_on_partition_only、およびmin_age_to_force_merge_secondsを設定します。パーティション内のすべてのパーツがmin_age_to_force_merge_secondsよりも古い場合、ClickHouseはそれらをすべて1つのパートにマージし、削除行を取り除きます。

  2. 手動でOPTIMIZE TABLE table [PARTITION partition | PARTITION ID 'partition_id'] FINAL CLEANUPを実行します。

例：

クエリ句​

ReplacingMergeTreeテーブルを作成する際には、MergeTreeテーブルを作成する際と同じ句が必要です。

テーブルを作成するための非推奨の方法
注記

新しいプロジェクトではこの方法を使用せず、可能であれば古いプロジェクトを上記の方法に切り替えてください。

verを除くすべてのパラメータはMergeTreeと同じ意味を持ちます。

  • ver - バージョンを持つカラム。オプションのパラメータです。詳細については、上記のテキストを参照してください。

クエリ時の重複排除とFINAL​

マージ時に、ReplacingMergeTreeは重複した行を識別し、テーブル作成時に使用されたORDER BYカラムの値を一意の識別子として利用し、最高バージョンのみを保持します。しかし、これは最終的に正しい結果を提供するものであり、行が重複しないことを保証するものではなく、これを期待すべきではありません。したがって、クエリは更新および削除行がクエリに考慮されるため、不正確な回答を生成することがあります。

正しい回答を得るには、ユーザーはバックグラウンドのマージを補完し、クエリ時の重複排除と削除処理を行う必要があります。これは、FINAL演算子を使用することで達成できます。たとえば、次の例を考えます：

FINALを使わずにクエリを実行すると、不正確なカウントが生成されます（正確な結果はマージに応じて変わることがあります）：

FINALを追加すると正しい結果が得られます：

FINALの詳細、パフォーマンスの最適化については、ReplacingMergeTreeに関する詳細ガイドをお読みになることをお勧めします。