질의 최적화 전략

Welcome to Query Optimization Strategies! In this lesson, we'll dive into techniques to make your Elasticsearch searches faster and more efficient.

Optimized queries mean quicker response times for your users and less strain on your cluster's resources. Let's learn how to write smarter queries!

One of the most crucial concepts for query performance is understanding the difference between Query Context and Filter Context.

• Query Context: Used for full-text search. It determines if a document matches the query AND calculates a relevancy _score.
• Filter Context: Only determines if a document matches the query. It does NOT calculate a _score. Filtered results are often cached, making them very fast.

Use filter context whenever you don't need a relevancy score!

The best way to leverage filter context is by using the filter clause within a bool query. This tells Elasticsearch to treat the enclosed queries as filters, without scoring.

Here's an example. We search for 'laptop' (scored) AND filter by 'category': 'electronics' (not scored):

Choosing the right query type for your needs is vital:

• term query: Searches for an exact value. It expects the exact term to be present in the inverted index. Best for keyword fields (e.g., product IDs, categories). Very fast as it skips analysis.
• match query: Performs full-text search. It analyzes the query string using the field's analyzer before searching. Best for text fields (e.g., product descriptions). Slower due to analysis and scoring.

Always use term when you need an exact match on an unanalyzed field!

Sometimes you just need to check if a field exists in a document, regardless of its value. The exists query is perfect for this, and it runs in filter context by default, making it very efficient.

This query finds all products that have a 'price' field:

What if you want to use a complex query (like match or range) but don't need the relevancy score? You can wrap it in a constant_score query.

This makes the wrapped query execute in filter context, assigning a constant _score to all matching documents, thus improving performance by avoiding score calculation.

Queries like wildcard (e.g., *term or term*) can be very inefficient, especially with a leading wildcard.

• Leading wildcards prevent Elasticsearch from using its inverted index efficiently, often requiring it to scan many terms.
• This can lead to high CPU and memory usage, especially on large datasets.

For 'starts with' scenarios, consider alternatives like match_phrase_prefix or edge_ngram token filters in your mapping.

For displaying search results across many pages, the standard from and size parameters work well for the first few pages.

However, for deep pagination (e.g., beyond page 100), from and size become inefficient. Elasticsearch has to retrieve and sort all documents up to from + size before discarding the first from documents.

Use search_after for efficient deep pagination. It uses the sort values from the last document on the previous page to find the next set of results, acting like a 'live cursor'.

Which of the following strategies are generally recommended for improving Elasticsearch query performance?

You've learned key strategies to optimize your Elasticsearch queries:

• Distinguish between Query Context (scoring) and Filter Context (no scoring, cached).
• Use the filter clause in bool queries for non-scoring criteria.
• Choose wisely between term (exact match) and match (full-text) queries.
• Leverage exists for efficient field presence checks.
• Wrap queries in constant_score when you don't need a score.
• Avoid leading wildcard queries due to their high cost.
• Implement search_after for scalable deep pagination.

By applying these techniques, your Elasticsearch applications will be faster and more responsive!