索引について

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

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

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

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

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

  '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などがあります。