高カーディナリティのフィールド
カーディナリティは、フィールド内の個別の値の数です。あ status フィールドには 3 つの値を指定できます。ある request_id 行ごとに異なる値を持つ可能性があります。高いカーディナリティは本質的に間違っているわけではありませんが、フィールドのクエリと視覚化の方法が変わります。
有用な高基数フィールド
リクエスト、トレース、ジョブ、アカウント、およびユーザーの識別子は、調査中に重要になる場合があります。これらを使用すると、関連するイベントを見つけたり、誰が影響を受けたかを特定したりできます。特定の検索または結合の使用例があり、識別子を安全に保存できる場合は、それらを保持します。
一意の識別子をグラフのデフォルトのグループ化ディメンションとして使用しないでください。 100,000 個のリクエスト ID を含む棒グラフは読みにくく、効率的でもありません。特定の識別子にフィルターをかけるか、境界のあるカテゴリごとにグループ化し、その識別子を詳細テーブルに保持します。
偶発的なカーディナリティ
未処理の URL、例外メッセージ、SQL テキスト、ユーザー エージェント、および自由形式のラベルにより、意図せずカーディナリティが作成されることがよくあります。正規化 /projects/abc123 に route_template など /projects/:id。例外を制御対象にマップする error_type 詳細な診断を適切なログ システムに保存しながら。コンテキストを保持するためだけにシークレットや生のユーザー コンテンツをイベントに入れないでください。
パーティション列には特に注意が必要です。フィルタリングに役立つフィールドが、自動的に適切なパーティションになるわけではありません。過度に個別のパーティションを作成すると、小さなファイルが作成され、計画のオーバーヘッドが発生します。代表的なクエリを測定した後でのみ、安定した、頻繁にフィルタリングされるディメンションを選択してください。参照 パーティション列の選択.
クエリパターン
時間制限を設定して集計を開始し、制御されたディメンションごとにグループ化し、パーセンテージをランク付けする前に最小量ルールを課します。調査の場合は、カーディナリティの高い識別子で直接フィルターし、狭い列セットを要求します。
SELECT timestamp_utc, status, error_type, latency_ms
FROM api_requests
WHERE request_id = 'req_example'
ORDER BY timestamp_utc;