t1 を MongoDB に作成したとします。
t1 には、次の行が含まれます。
テーブルスキーマ
_id: MongoDB の主キーdoc: JSON データ型としてレプリケートされた MongoDB ドキュメント_peerdb_synced_at: 行が最後に同期された時刻を記録します_peerdb_version: 行のバージョンを追跡します。行が更新または削除されるとインクリメントされます_peerdb_is_deleted: 行が削除済みかどうかを示します
ReplacingMergeTree テーブルエンジン
ReplacingMergeTree テーブルエンジンファミリーを使用して、MongoDB のコレクションを ClickHouse にマッピングします。このエンジンでは、更新は、特定の主キー (_id) に対応する、より新しいバージョン (_peerdb_version) のドキュメントを insert する形で表現されます。これにより、更新、置換、削除をバージョン付き insert として効率的に処理できます。
ReplacingMergeTree は、バックグラウンドで非同期に重複を削除します。同じ行の重複がないことを保証するには、FINAL 修飾子 を使用します。例:
削除の扱い
_peerdb_is_deleted カラムに削除済みの印が付いた新しい行として伝播されます。通常、クエリではこれらを除外します。
JSONデータのクエリ
Query
Result
^ 演算子を必ず追加してください。
Query
Result
Dynamic 型
Dynamic 型になります。Dynamic 型を使うと、ClickHouse は型を事前に把握していなくても、どのような型の値でも格納できます。これは toTypeName 関数で確認できます。
Query
Result
dynamicType 関数を使います。同じフィールド名でも、行によってデータ型が異なる場合がある点に注意してください。
Query
Result
Query
Result
Query
Result
Query
Result
フィールドの型変換
sum 関数を直接使用しようとすると、次のエラーが発生します。
CAST 関数または :: 構文を使って、フィールドを適切な型にキャストします。
Query
Result
Dynamic型から基になるデータ型 (
dynamicType によって決まる型) へのキャストは非常に高速です。これは、ClickHouse が値を内部的にすでにその基の型で保持しているためです。JSONのフラット化
通常のビュー
リフレッシャブルmaterialized view
FINAL キーワードを使用するクエリが更新時に一度だけ実行されることです。これにより、その後に宛先テーブルに対して実行するクエリで FINAL を使う必要がなくなります。
一方で、宛先テーブル内のデータは直近の更新時点の内容に限られるという欠点があります。多くのユースケースでは、更新間隔を数分から数時間に設定することで、データ鮮度とクエリ性能のバランスを適切に取ることができます。
FINAL修飾子を使わずに、テーブル flattened_t1 に直接クエリできるようになりました:
インクリメンタルmaterialized view
FINAL modifier を使用することは推奨されません。代わりに、materialized view の上に通常のビューを作成することで、クエリ時にデータを重複排除できます。
flattened_t1_final に対してクエリを実行できます: