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

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;

一般的なプロダクションの問題​

ディスクスペースの問題​

レプリケーションセットアップにおけるディスクスペースの枯渇は、 cascadingな問題を引き起こします。一つのノードがスペース不足になると、他のノードはそれと同期し続け、ネットワークトラフィックの急増と混乱した症状を引き起こします。あるコミュニティのメンバーは、単にディスクスペースが低いために4時間デバッグに費やしました。特定のクラスタでのディスクストレージを監視するためのこのクエリをチェックしてください。

AWSのユーザーは、デフォルトの一般目的EBSボリュームには16TBの制限があることを理解しておく必要があります。

パーツが多すぎるエラー​

小さい頻繁な挿入はパフォーマンスの問題を引き起こします。コミュニティは、1秒あたり10以上の挿入レートがあると「パーツが多すぎる」エラーを引き起こすことが多いことを特定しました。これはClickHouseがパーツを十分に早くマージできないためです。

解決策:

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

公式推奨: 挿入ごとに最低1,000行、理想は10,000から100,000。

無効なタイムスタンプの問題​

任意のタイムスタンプでデータを送信するアプリケーションは、パーティションの問題を引き起こします。これにより、現実的でない日付（例えば1998年や2050年）のデータを含むパーティションが生成され、予期しないストレージ動作を引き起こします。

ALTER操作のリスク​

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

高価な変異を監視する:

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

スキーマ変更は、最初に小さなデータセットでテストしてください。

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

外部集約​

メモリ集約性が高い操作には外部集約を有効にします。遅いですが、スピルしてディスクに書き出すことで、メモリ不足によるクラッシュを防ぎます。max_bytes_before_external_group_byを使用することで、 largeな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 threshold

非同期挿入の詳細​

非同期挿入は、小さな挿入をサーバー側で自動的にバッチ処理してパフォーマンスを向上させます。データがディスクに書き込まれるのを待ってから確認を返すかどうかを設定できます - 即時の返却は速いですが、耐久性が低下します。最新のバージョンでは、バッチ内の重複データを処理するための重複排除をサポートしています。

関連ドキュメント

分散テーブルの構成​

デフォルトでは、分散テーブルはシングルスレッドで挿入を行います。並列処理とシャードへの即時データ送信のためにinsert_distributed_syncを有効にしてください。

分散テーブルを使用する際の一時データの蓄積を監視してください。

パフォーマンスモニタリングのしきい値​

コミュニティ推奨のモニタリングしきい値:

  • パーティションごとのパーツ数: できれば100未満
  • 遅延挿入: ゼロのままにするべき
  • 挿入レート: 最適なパフォーマンスのために約1秒あたり1に制限する

関連ドキュメント

クイックリファレンス​

問題検出解決策
ディスクスペースsystem.partsの合計バイトをチェック使用状況の監視、スケーリング計画
パーツが多すぎるテーブルごとのパーツ数をカウント挿入をバッチ処理、async_insertを有効にする
レプリケーションの遅延system.replicasの遅延をチェックネットワークを監視、レプリカを再起動
悪いデータパーティションの日付を検証タイムスタンプの検証を実装
ストック変異system.mutationsのステータスをチェックまず小さなデータでテスト

ビデオソース​