システムテーブルの概要
はじめに
システムテーブルは、以下に関する情報を提供します：
- サーバーの状態、プロセス、環境。
- サーバーの内部プロセス。
- ClickHouse バイナリがビルドされた際に使用されたオプション。
システムテーブルの特徴：
systemデータベースに存在します。- データの読み取り専用です。
- ドロップや変更はできませんが、ディタッチは可能です。
ほとんどのシステムテーブルは、RAMにデータを保存します。ClickHouseサーバーは起動時にこのようなシステムテーブルを作成します。
他のシステムテーブルとは異なり、システムログテーブル metric_log、query_log、query_thread_log、trace_log、part_log、crash_log、text_log および backup_log は MergeTree テーブルエンジンによって処理され、デフォルトではファイルシステムにデータを保存します。ファイルシステムからテーブルを削除すると、ClickHouseサーバーは次回のデータ書き込み時に再度空のテーブルを作成します。新しいリリースでシステムテーブルのスキーマが変更された場合、ClickHouseは現在のテーブルの名前を変更し、新しいテーブルを作成します。
システムログテーブルは、/etc/clickhouse-server/config.d/ にテーブルと同じ名前の設定ファイルを作成するか、/etc/clickhouse-server/config.xml に対応する要素を設定することでカスタマイズできます。カスタマイズできる要素は以下の通りです：
database: システムログテーブルが所属するデータベース。このオプションは現在非推奨です。すべてのシステムログテーブルはデータベースsystemの下に存在します。table: データを挿入するテーブル。partition_by: PARTITION BY 式を指定します。ttl: テーブルの TTL 式を指定します。flush_interval_milliseconds: データをディスクにフラッシュする間隔。engine: パラメータ付きの完全なエンジン式 (ENGINE =で始まる) を提供します。このオプションはpartition_byとttlと競合します。両方を設定する場合、サーバーは例外を発生させて終了します。
例：
デフォルトでは、テーブルの成長に制限はありません。テーブルのサイズを制御するには、古くなったログレコードを削除するために TTL 設定を使用できます。また、MergeTree エンジンテーブルのパーティショニング機能を使用することもできます。
システムメトリックのソース
システムメトリックの収集のために、ClickHouseサーバーは以下を使用します：
CAP_NET_ADMIN権限。- procfs (Linux のみ)。
procfs
ClickHouseサーバーが CAP_NET_ADMIN 権限を持っていない場合、ProcfsMetricsProvider にフォールバックしようとします。ProcfsMetricsProvider は、CPUとI/Oのためのクエリごとのシステムメトリックを収集することを可能にします。
procfs がシステムでサポートされ、有効になっている場合、ClickHouseサーバーは以下のメトリックを収集します：
OSCPUVirtualTimeMicrosecondsOSCPUWaitMicrosecondsOSIOWaitMicrosecondsOSReadCharsOSWriteCharsOSReadBytesOSWriteBytes
OSIOWaitMicroseconds は、Linux カーネル 5.14.x 以降ではデフォルトで無効になっています。
sudo sysctl kernel.task_delayacct=1 を実行するか、/etc/sysctl.d/ 内に kernel.task_delayacct = 1 の .conf ファイルを作成することで有効化できます。
ClickHouse Cloud のシステムテーブル
ClickHouse Cloud では、システムテーブルがサービスの状態とパフォーマンスに関する重要な洞察を提供します。これはセルフマネージドデプロイメントと同様です。いくつかのシステムテーブルはクラスタ全体のレベルで操作され、特に分散メタデータを管理する Keeper ノードからデータを取得します。これらのテーブルはクラスタの集合的な状態を反映し、個々のノードでクエリされたときに一貫性を保つべきです。たとえば、parts は、クエリを実行されるノードに関係なく、一貫性を持つべきです：
対照的に、他のシステムテーブルはノード固有であり、例えばインメモリまたは MergeTree テーブルエンジンを使用してデータを永続化しています。これは、ログやメトリクスなどのデータに一般的です。この永続性により、歴史的データが分析のために利用可能なままとなります。しかし、これらのノード固有のテーブルは、それぞれのノードに固有です。
クラスタ全体を包括的に表示するには、ユーザーは clusterAllReplicas 関数を活用できます。この関数は、"default" クラスタ内のすべてのレプリカにわたってシステムテーブルをクエリし、ノード固有のデータを統合された結果にまとめます。このアプローチは、クラスタ全体の操作を監視およびデバッグするために特に価値があり、ユーザーが ClickHouse Cloud デプロイメントの健康状態とパフォーマンスを効果的に分析できるようにします。
ClickHouse Cloud は冗長性とフェイルオーバーのための複数レプリカのクラスタを提供しています。これにより、動的オートスケーリングやゼロダウンタイムのアップグレードなどの機能が可能になります。特定の時間に、新しいノードがクラスタに追加されるプロセス中であったり、クラスタから削除されるプロセス中である可能性があります。これらのノードをスキップするには、clusterAllReplicas を使用するクエリに SETTINGS skip_unavailable_shards = 1 を追加してください。
たとえば、分析にしばしば重要な query_log テーブルをクエリする際の違いを考えてみましょう。
一般に、システムテーブルがノード固有であるかどうかを判断する際に次のルールを適用できます：
_logサフィックスを持つシステムテーブル。- メトリックを公開するシステムテーブル：
metrics、asynchronous_metrics、events。 - 進行中のプロセスを公開するシステムテーブル：
processes、merges。