概要
ClickHouseとOLTPデータベースにおけるデータ更新の違い
データの更新処理に関して、ClickHouseとOLTPデータベースはその基盤となる設計哲学とターゲットユースケースにより大きく異なります。例えば、行指向でACID準拠のリレーショナルデータベースであるPostgreSQLは、強力でトランザクションをサポートする更新および削除操作をサポートし、Multi-Version Concurrency Control (MVCC)といったメカニズムを通じてデータの整合性と完全性を確保します。これにより、高い競合環境でも安全で信頼性の高い変更が可能になります。
それに対して、ClickHouseは読み取り重視の分析と高スループットの追加専用操作に最適化された列指向データベースです。ClickHouseはネイティブにインプレースでの更新と削除をサポートしていますが、これらは高いI/Oを避けるために注意して使用する必要があります。また、テーブルを再構築して、削除と更新を追加操作に変換することで、非同期で処理されるか、または読み取り時にのみ適用されるようにすることができます。これにより、リアルタイムのデータ操作よりも高スループットなデータ取り込みと効率的なクエリパフォーマンスにフォーカスしています。
ClickHouseでのデータ更新方法
ClickHouseではデータを更新するためのいくつかの方法があり、それぞれに利点とパフォーマンス特性があります。利用するデータモデルと更新するデータ量に応じて適切な方法を選択する必要があります。
両方の操作において、提出された変更の数が特定の時間間隔において処理される変更数を常に上回る場合、適用される非物質化された変更のキューは成長し続けます。これは最終的にSELECTクエリのパフォーマンス低下を引き起こします。
要約すると、更新操作は注意して発行すべきであり、system.mutationsテーブルを使用して変更キューを厳密に追跡する必要があります。OLTPデータベースのように頻繁に更新を発行しないでください。頻繁な更新の要件がある場合は、ReplacingMergeTreeを参照してください。
| 方法 | 構文 | 使用するタイミング |
|---|---|---|
| Update mutation | ALTER TABLE [table] UPDATE | データをすぐにディスクに更新する必要がある場合に使用します（例：コンプライアンスのため）。SELECTパフォーマンスに悪影響を及ぼします。 |
| Lightweight update | ALTER TABLE [table] UPDATE | SET apply_mutations_on_fly = 1;を有効にします。データの小規模な更新に使用します。行はすぐに更新データとともにすべての後続のSELECTクエリに返されますが、最初はディスク上では内部的にのみ更新としてマークされます。 |
| ReplacingMergeTree | ENGINE = ReplacingMergeTree | 大量のデータを更新する場合に使用します。このテーブルエンジンはマージ時のデータ重複除去に最適化されています。 |
| CollapsingMergeTree | ENGINE = CollapsingMergeTree(Sign) | 個々の行を頻繁に更新する場合、または時間とともに変化するオブジェクトの最新状態を維持する必要があるシナリオに使用します。例えば、ユーザーのアクティビティや記事の統計を追跡する場合です。 |
ClickHouseでのデータ更新のさまざまな方法を要約します。
更新ミューテーション
更新ミューテーションはALTER TABLE ... UPDATEコマンドを通じて発行できます。例えば：
