メインコンテンツへスキップ
メインコンテンツへスキップ

ClickHouse の運用: コミュニティによるデバッグインサイト

このガイドは、コミュニティミートアップから得られた知見を集約したコレクションの一部です。より多くの実運用に基づく解決策や知見については、特定の問題別に閲覧できます。 高い運用コストにお悩みですか？コスト最適化に関するコミュニティのインサイトガイドを参照してください。

重要なシステムテーブル​

これらのシステムテーブルは、本番環境でのデバッグに不可欠です。

system.errors​

ClickHouse インスタンス内で現在発生しているすべてのエラーを表示します。

SELECT name, value, changed 
FROM system.errors 
WHERE value > 0 
ORDER BY value DESC;

system.replicas​

クラスターの健全性を監視するためのレプリケーション遅延およびステータス情報を含みます。

SELECT database, table, replica_name, absolute_delay, queue_size, inserts_in_queue
FROM system.replicas 
WHERE absolute_delay > 60
ORDER BY absolute_delay DESC;

system.replication_queue​

レプリケーション関連の問題の診断に役立つ詳細情報を提供します。

SELECT database, table, replica_name, position, type, create_time, last_exception
FROM system.replication_queue 
WHERE last_exception != ''
ORDER BY create_time DESC;

system.merges​

現在実行中のマージ処理を表示し、ハングしているプロセスを特定できます。

SELECT database, table, elapsed, progress, is_mutation, total_size_bytes_compressed
FROM system.merges 
ORDER BY elapsed DESC;

system.parts​

パーツ数の監視や断片化の問題を特定するうえで不可欠です。

SELECT database, table, count() as part_count
FROM system.parts 
WHERE active = 1
GROUP BY database, table
ORDER BY count() DESC;

本番環境でよく起きる問題​

ディスク容量の問題​

レプリケーション構成でディスク容量が枯渇すると、連鎖的な問題が発生します。あるノードの空き容量がなくなると、他のノードは同期を続けようとするため、ネットワークトラフィックのスパイクや原因が分かりにくい症状が発生します。コミュニティメンバーの一人は、単なるディスク容量不足だった問題の調査に 4 時間費やしました。特定のクラスター上のディスクストレージを監視するには、この クエリ を参照してください。

AWS ユーザーは、デフォルトの汎用 EBS ボリュームには 16TB の上限があることに注意してください。

too many parts エラー​

小さなデータを高頻度で挿入すると、パフォーマンス問題が発生します。コミュニティでは、1 秒あたり 10 回を超える挿入レートでは、多くの場合 ClickHouse がパーツを十分な速度でマージできないために「too many parts」エラーが発生することが確認されています。

解決策:

  • 30 秒または 200MB をしきい値としてデータをバッチ処理する
  • 自動バッチ処理のために async_insert を有効にする
  • サーバー側でのバッチ処理に buffer テーブルを使用する
  • バッチサイズを制御するために Kafka を構成する

公式推奨: 挿入 1 回あたり最小 1,000 行、理想的には 10,000 ～ 100,000 行。

不正なタイムスタンプの問題​

任意のタイムスタンプを付与してデータを送信するアプリケーションは、パーティションの問題を引き起こします。その結果、1998 年や 2050 年のような非現実的な日時のデータを含むパーティションが作成され、予期しないストレージの挙動につながります。

ALTER 操作のリスク​

マルチテラバイトのテーブルに対する大規模な ALTER 操作は、多くのリソースを消費し、データベースをロックする可能性があります。コミュニティの事例では、14TB のデータ上で Integer 型を Float 型に変更したところ、データベース全体がロックされ、バックアップからの再構築が必要になりました。

高コストな mutation の監視:

SELECT database, table, mutation_id, command, parts_to_do, is_done
FROM system.mutations 
WHERE is_done = 0;

まずは小規模なデータセットでスキーマ変更を検証してください。

メモリとパフォーマンス​

外部集約​

メモリ使用量の大きい処理に対しては、外部集約を有効化してください。ディスクへのスピルが発生するため処理は遅くなりますが、メモリ不足によるクラッシュを防止できます。これは max_bytes_before_external_group_by を設定することで有効化できます。これにより、大規模な GROUP BY 処理時のメモリ不足によるクラッシュを防ぐのに役立ちます。この設定の詳細はこちらを参照してください。

SELECT 
    column1,
    column2,
    COUNT(*) as count,
    SUM(value) as total
FROM large_table
GROUP BY column1, column2
SETTINGS max_bytes_before_external_group_by = 1000000000; -- 1GBしきい値

非同期インサートの詳細​

非同期インサートは、小さなインサートをサーバー側で自動的にバッチ化してパフォーマンスを向上させます。ディスクへの書き込み完了を待ってから応答を返すかどうかを設定できます。即時に返す方が高速ですが、永続性は低くなります。最近のバージョンでは、バッチ内の重複データを処理するための重複排除もサポートされています。

関連ドキュメント

Distributed テーブルの設定​

デフォルトでは、Distributed テーブルは単一スレッドでインサートを実行します。並列処理とシャードへの即時データ送信のために insert_distributed_sync を有効にします。

Distributed テーブルを使用する場合は、一時データの蓄積を監視してください。

パフォーマンス監視のしきい値​

コミュニティ推奨の監視しきい値:

  • パーティションあたりのパーツ数: 望ましくは 100 未満
  • 遅延インサート: 0 を維持すること
  • インサートレート: 最適なパフォーマンスのため、おおよそ 1 秒あたり 1 回に制限する

関連ドキュメント

クイックリファレンス​

課題検知解決策
ディスク容量system.parts の合計バイト数を確認使用量を監視し、スケーリングを計画
パーツ数過多テーブルごとのパーツ数をカウントバッチ挿入を行い、async_insert を有効化
レプリケーション遅延system.replicas の遅延を確認ネットワークを監視し、レプリカを再起動
不正データパーティションの日付を検証タイムスタンプ検証を実装
ミューテーションが進まないsystem.mutations のステータスを確認まずは小さなデータでテスト

動画資料​