パーティションによる検索の最適化

パーティションとは?

パーティションは、クエリ時により少数のメッセージに対して検索を実行して、検索のパフォーマンスを向上させるカスタム インデックスです。デフォルトでは、すべてのデータが一般的なインデックスに保存されます。ただし、データ セット全体ではなく必要なパーティションのみが検索でスキャンされるように追加パーティションを作成して、検索を高速化できます。組織のすべてのメンバーは、クエリの実行時にこのパーティション構造を利用できます。

次の例は、環境ごとにデータを分離するために 3 つの追加パーティションを作成した顧客を示しています。

次のクエリを考えます。

• クエリ 1。カスタム パーティションは作成されておらず、デフォルト インデックスのみがあり、100% のデータがスキャンされて、運用環境のすべてのログ メッセージから Snort セキュリティ アプリケーションが検索されます。
• クエリ 2。パーティションが存在しており、_index=prod によってクエリの範囲が制限され、約 40% のデータのみがスキャンされて、クエリ 1 と同じ結果になります。ただし、冗長で
• クエリ 3。既存のクエリを書き換えることなくパーティションを利用できます。Sumo Logic のバックグラウンドの Query Rewriting はスマートであるため、検索対象の範囲が _index=prod 内に含まれていることを理解できます。そのため、実行時にクエリをクエリ 2 のように書き換えます。
• クエリ 4。カスタム パーティションに含まれるデータと、デフォルト インデックスに存在するデータを検索したいと考えています。ただし、Query Rewriting では、インデックスの OR 操作を同時に実行できません。  代わりに、別のバックグラウンド機能 Inverse View Rewriting が開始されます。DEV および QA インデックスにはデータがないことがわかっているのでそれらはスキップされます。  このクエリでは、Prod インデックスとデフォルト インデックスのみがスキャンされます。

Query Rewriting とは?

ユーザのクエリは、パフォーマンスの向上のためにできるだけ書き換えられます。次の例では、既存のパーティションを利用してクエリが書き換えられます。

つまり、

_sourceCategory=prod/security/snort

は、次のように書き換えられます。

_index=prod AND _sourceCategory=prod/security/snort

これが可能な理由は、次のとおりです。

1. この例の環境では、堅牢な _SourceCategory の命名規則が使用されている

2. パーティションは _sourceCategory を使用して範囲設定されている

3. 検索で _sourceCategory が使用されているため、パーティションに簡単にマップできる

4. この検索の範囲 (_sourceCategory=prod/security/snort) は、パーティションの範囲 (_sourceCategory=prod/*) の範囲に含まれる

そのため、広いパーティションの範囲 (_sourceCategory=prod/* など) を定義して _sourceCategory を使用して検索すれば、Query Rewriting を利用でき、手動で既存のクエリを書き換える必要がなくなる可能性があります。

パーティションを作成する

管理者は、ルーティング式を指定してパーティションを作成します。Query Rewriting を最大限に活用するために、_sourceCategeory を使用してルーティング式を定義することをお勧めします。

次の例は、3 つのカスタム パーティションのルーティング式を示しています。

次に、Dev パーティションを作成する簡単なステップを示します。

チームでパーティションを使用する方法は?

作成されたパーティションは、組織の全員が使用できます。このパーティションにより、検索の範囲が絞り込まれ、すべてのユーザのパフォーマンスが向上します。上記のクエリ 2 では、新規作成されたパーティションを利用して、40% のデータのみをスキャンします。前述したように、クエリ 3 も Query Rewriting によってクエリ 2 と同じ結果が生成されるため優れた方法です。この方法では、パーティションの用意ができていれば、すべてのクエリを編集する必要がなくなる可能性があります。

次に、Prod パーティションを使用して検索範囲を絞り込む検索の例を示します。

パーティションを使用する場合のベスト プラクティス

断片化を回避するためにパーティションを作成しすぎないようにする。パーティションは 20 個までにすることをお勧めします。これにより、インデックスの断片化とデータ管理の両方の問題を回避できます。この作業には、使用するパーティションやパーティション間の重複をユーザに伝えることも含まれます。

最適なパーティション サイズは取り込みの合計の 1% ～ 30%。パーティションが小さすぎると、インデックスが断片化し、検索のパフォーマンスが低下する可能性があります。悪影響を与えることなく 30% より大きいパーティションを作成することはできますが、パフォーマンスの向上は減少します。

重複するパーティションを作成しない。パーティションが重複していると、データが重複 (請求対象の取り込みレートが増加) し、パフォーマンスが低下します。Sumo Logic は、重複する結果を返しませんが、重複排除の処理は時間がかかり、クエリの期間が長くなります。

パーティション定義で NOT operator を使用しない。NOT operator を使用すると、パーティションに含まれるべきデータが除外されやすくなり、書き換えられるクエリでパーティションが再利用される可能性が低くなります。

パーティションを定義するために sourceHost を使用しない。sourceHost を使用すると、パーティションの OR 操作を同時に実行せずに水平検索することができなくなる可能性があります。

直感的な命名体系を使用する。これにより、ユーザは使用すべき適切なパーティションを簡単に識別できるようになります。

パーティション定義で sourceCategory を使用し、キーワードを避けて、広範囲なパーティションを維持する。検索の範囲は、パーティションを照会するときにいつでも絞り込むことができます。

類似するデータをグループ化する。すべての Prod データを検索することが最も多くなるため、上記の例では prod/QA/Dev 環境を使用しました。複数の環境を検索する必要がある場合、2 つ以上のパーティションの OR 操作を実行できます。

優れたパーティションのその他の情報はどこで入手できますか?

[Manage Partitions (パーティションの管理)] ページにアクセスしてください。