圧縮戦略: 本番環境におけるLZ4とZSTD
- ZSTD圧縮により大規模テーブルでストレージを50%削減
- 毎月2 PBのデータ処理能力
- インジェストとクエリへの性能影響は許容可能
- 数百TB規模で大幅なコスト削減
カラムベースの保持戦略
- ClickHouse のテレメトリーを使用してカラムの利用パターンを分析する
- ストレージ使用量が多く、クエリ頻度の低いカラムを特定する
- 選択的な保持ポリシーを実装する
- データに基づく意思決定のためにクエリパターンを監視する
パーティションベースのデータ管理
- データのクリーンアップが容易 (行単位で削除する代わりにパーティションを削除)
- 請求計算の簡素化
- パーティション除外によるクエリパフォーマンスの向上
- 運用管理の簡素化
文字列から整数への変換戦略
weather_answer、sports_answer、factual_answer のような説明用の文字列タグが付与されていました。何十億もの検索クエリが処理される中、これらの文字列値は ClickHouse に繰り返し保存されるため、大量のストレージを消費するうえ、クエリ実行時にはコストの高い文字列比較も必要になっていました。
Microsoft は、別の MySQL データベースを使って、文字列と整数を対応付ける仕組みを実装しました。ClickHouse には実際の文字列を保存せず、整数 ID のみを保存します。UI からクエリを実行して weather_answer のデータを要求すると、クエリオプティマイザーはまず MySQL のマッピングテーブルを参照して対応する整数 ID を取得し、その後、その整数を使うようにクエリを書き換えてから ClickHouse に送信します。
このアーキテクチャにより、ユーザー体験はそのまま維持されます。ユーザーはダッシュボード上で weather_answer のような意味のあるラベルを引き続き確認できる一方で、バックエンドのストレージとクエリ処理は、はるかに効率の高い整数を使って動作します。マッピングシステムがすべての変換を透過的に処理するため、ユーザー インターフェイスやユーザーのワークフローを変更する必要はありません。
主な利点:
- 影響を受けるデータセットでストレージ使用量を 60% 削減
- 整数比較によるクエリ性能の向上
- JOIN や集計におけるメモリ使用量の削減
- 大規模な結果セットでのネットワーク転送コストの低減
これは Microsoft Clarity のデータシナリオに特化した例です。すべてのデータが ClickHouse にある場合、またはデータを ClickHouse に移動することに制約がない場合は、代わりに dictionaries の使用を検討してください。
関連動画
- Microsoft Clarity と ClickHouse - Microsoft Clarity チーム
- Contentsquare における ClickHouse 活用の歩み - Doron Hoffman & Guram Sigua (ContentSquare)