索引の理解

ログの取込み中に、パーサー、ログ・ソース、フィールドおよび拡張フィールドを使用してログ・レコードが解析され、ラベルが抽出されます。これらの値はすべて、問合せ効率のよい索引に格納されます。また、ログ・レコード全体のキーワードも索引付けされます。索引を使用する問合せは、索引を使用しない問合せよりも数倍高速です。大量のデータを問い合せる場合は、索引が使用されていることを確認する必要があります。

索引が使用されないのはいつですか。

問合せでワイルドカードが使用されている場合、または文字列処理関数のいずれかを使用してフィールドが操作されている場合、索引は使用されません。次に、いくつかの例を示します。

• 問合せでワイルドカードを使用しない

  一般的なユース・ケースは、次のようにフィールド内の特定のパターンを検索することです。

  'Error Text' like '%NullPointerException%'

  前述の問合せでは、ワイルドカードが使用されているため索引は使用されません。「エラー・テキスト」フィールドに大量のデータがある場合、または問合せが多数のレコードにわたって実行される場合は、最終的にタイムアウトになります。これを回避するには、このパターンを検出してフィールドを設定する条件をログ・ソースに追加します。その後、そのフィールドをクエリーで直接使用できます。

  たとえば、様々な条件に基づいて「エラー・タイプ」という名前のフィールドをログ・ソースに移入し、このフィールドを使用するように問合せを更新できます。

  'Error Type' = NullPointerException

  ログ・ソースにパターンを追加できない場合は、次のようにキーワード検索に変更することもできます。

  NullPointerException

  これにより、RAWログ・レコードを表す「元のログ・コンテンツ」フィールドでNullPointerExceptionという語が検索されます。この問合せは、ワイルド・カードを使用する前の問合せよりも数倍高速であるため、完全一致が不要な場合に便利です。

  ノート
  
  大量のフィールドを格納するフィールドに対してワイルドカードを使用すると、小さいフィールドよりもパフォーマンスが低下します。ただし、関連するログ・レコードの数が多い場合、小さいフィールドに対するワイルド・カードも遅くなります。

• 高価な文字列演算子を使用しない

  索引は、substr()、extract、jsonExtractなどの文字列操作を使用して生成されたフィールドでは使用されません。次に、索引がスキップされる例を示します。

  * | eval Prefix = substr('Host Name (Server)', 1, 3) | where Prefix = DBC
  
  * | where indexOf('Host Name (Server)', 'DBC') != -1

  文字列演算子を頻繁に使用する必要がある場合は、パーサーまたはログ・ソースにこれらを移動し、個別のフィールドを作成することを検討する必要があります。

長い時間範囲

長期間にわたる大量のデータの問合せもコストがかかります。時間範囲を短縮するか、検索基準をさらに追加して、処理するデータの量を減らします。

複数のログ・セットの使用

テナンシでログ・パーティション化が有効になっている場合は、ログ・セットを使用してログ・データの一部を選択します。ログ・セットは、システムの負荷を軽減するために最適化されます。単一のログ・セットに対して問合せを行うと、問合せはより小さなサーバー・セットに保持されます。ただし、多数のログ・セットに対する問合せでは、より多くのサービスに対するデータ転送および問合せが行われます。これにより、クエリーが大幅に遅くなる可能性があります。

最適なパフォーマンスを得るために、問合せで5つ以上のログ・セットを使用しないでください。

その他の高価な操作

次に、大量のデータに対する問合せの速度を低下させる可能性があるその他のコストの高い操作の一部を示します。

• sort
• headまたはtailコマンド
• カーディナリティの高いフィールドを含むstatsまたはtimestatsコマンド。これらは、多数の個別値を持つフィールドです。このようなフィールドの例として、トランザクションID、ECIDなどがあります。