パーツが多すぎる問題

このガイドは、コミュニティミートアップから得られた知見をまとめたコレクションの一部です。より実践的なソリューションやインサイトについては、問題別に閲覧できます。 さらにパフォーマンス最適化のヒントが必要な場合は、パフォーマンス最適化 に関するコミュニティインサイトガイドを参照してください。

問題の理解

ClickHouse は深刻なパフォーマンス低下を防ぐため、「Too many parts」エラーを発生させます。小さな part が多いと、さまざまな問題を引き起こします。クエリ処理時に読み込み・マージすべきファイルが増えることによるクエリパフォーマンスの低下、各 part ごとにメモリ上でメタデータを保持する必要があることによるメモリ使用量の増加、小さなデータブロックは圧縮効率が低いため圧縮率が悪化すること、より多くのファイルハンドルとシーク処理が必要になることによる I/O オーバーヘッドの増加、そしてマージスケジューラの負荷増大によるバックグラウンドマージの低速化です。

関連ドキュメント

• MergeTree エンジン
• Parts
• Parts システムテーブル

問題を早期に把握する

このクエリは、すべてのアクティブなテーブルに対してパーツ数とサイズを分析することで、テーブルのフラグメンテーションを監視します。マージの最適化が必要となる可能性がある、サイズが大きすぎる／小さすぎるパーツを持つテーブルを特定します。クエリパフォーマンスに影響が出る前にフラグメンテーションの問題を検出できるよう、これを定期的に実行してください。

-- 課題: 本番環境では実際のデータベース名とテーブル名に置き換えてください
-- 実験: システムに応じてパート数のしきい値（1000、500、100）を調整してください
SELECT 
    database,
    table,
    count() as total_parts,
    sum(rows) as total_rows,
    round(avg(rows), 0) as avg_rows_per_part,
    min(rows) as min_rows_per_part,
    max(rows) as max_rows_per_part,
    round(sum(bytes_on_disk) / 1024 / 1024, 2) as total_size_mb,
    CASE 
        WHEN count() > 1000 THEN 'CRITICAL - パート数が過剰です (>1000)'
        WHEN count() > 500 THEN 'WARNING - パート数が多くなっています (>500)'
        WHEN count() > 100 THEN 'CAUTION - パート数が増加しています (>100)'
        ELSE 'OK - パート数は適切です'
    END as parts_assessment,
    CASE 
        WHEN avg(rows) < 1000 THEN 'POOR - パートサイズが非常に小さい'
        WHEN avg(rows) < 10000 THEN 'FAIR - パートサイズが小さい'
        WHEN avg(rows) < 100000 THEN 'GOOD - パートサイズは中程度'
        ELSE 'EXCELLENT - パートサイズが大きい'
    END as part_size_assessment
FROM system.parts
WHERE active = 1
  AND database NOT IN ('system', 'information_schema')
GROUP BY database, table
ORDER BY total_parts DESC
LIMIT 20;

動画リソース

• ClickHouse における高速・並列・一貫性のある非同期 INSERT - ClickHouse チームメンバーが非同期 INSERT と「too many parts」問題について解説
• 大規模な本番環境での ClickHouse 運用 - オブザーバビリティプラットフォームにおける実践的なバッチ処理戦略