索引について

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

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

問合せでワイルドカードが使用されている場合、または文字列処理関数の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

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

長い時間範囲

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

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

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

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

その他の高コストの運用

大量のデータに対する問合せを低速化できるその他のコストの高い操作の一部を次に示します。

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