๊ฐ€์ž… ํ›„ ์ดˆ๋Œ€ ๋งํฌ๋ฅผ ๊ณต์œ ํ•˜๋ฉด ๋™์˜์ƒ ์žฌ์ƒ ๋ฐ ์ดˆ๋Œ€ ๋ณด์ƒ์„ ๋ฐ›์„ ์ˆ˜ ์žˆ์Šต๋‹ˆ๋‹ค.

cv usk
@cv_usk
AI / Software Research Notes AI Agent, LLMOps, MLOps, Software Architecture ๆŠ•็จฟใฏๅ€‹ไบบใฎๆ„่ฆ‹ใงใ™ใ€‚
๊ฐ€์ž… May 2026
258 ํŒ”๋กœ์ž‰ ์ค‘    228 ํŒฌ
# Elasticsearch Features and Practical Usage ๐Ÿงฉ Express "a keyword plus many filters" in a single JSON document. Query DSL and its `bool` query are the de facto standard for search backends, and how you use the filter clause decides your performance. ๐Ÿท๏ธ Title: Query DSL (JSON query language) ๐Ÿ”— URL: ๐Ÿ“˜ Overview Query DSL is a JSON-style query language used through the `_search` API. It expresses searching, filtering, and aggregations, with queries built as an abstract syntax tree of interconnected clauses. It is the de facto foundation of search backend implementations. โš™๏ธ How It Works Two distinctions are key. ใƒปClause types: standalone "leaf queries" (`match`, `term`, `range`, and so on) and "compound queries" (`bool`, `dis_max`) that wrap them. ใƒปContext: query context asks "how well does this match?" and computes `_score`. Filter context asks a binary "does this match?", skips scoring, runs faster, and is automatically cached. The central `bool` query has four clauses: `must` (must match, scored), `should` (optional, boosts score, governed by `minimum_should_match`), `filter` (must match, unscored, cached), and `must_not` (excludes, filter context). ๐Ÿ› ๏ธ Practical Usage For a job search, put the keyword query in `must` and the refinements in `filter`. ``` { "query": { "bool": { "must": [ { "multi_match": { "query": "backend engineer", "fields": ["title", "description"] } } ], "filter": [ { "term": { "location": "tokyo" } }, { "terms": { "employment_type": ["fulltime", "contract"] } }, { "range": { "salary": { "gte": 5000000 } } } ] } } } ``` The keyword should influence the score, so it goes in `must`; location, employment type, and salary need no scoring, so they go in `filter`. Filter clauses get cached, making repeated queries fast. ๐Ÿ’ก Use Cases This pattern fits any search app with "full-text plus many structured filters", such as e-commerce, jobs, or real estate. Splitting conditions between `must` (rank by relevance) and `filter` (plain match/no-match) gives you both relevance ranking and strict narrowing in one request. โš ๏ธ Caveats The biggest pitfall is confusing `term` and `match`. `term` matches exactly without analysis, so using it on an analyzed `text` field usually returns zero results. Use `match` for `text`, and `term` for `keyword` and structured fields like status or dates. Always put non-scoring conditions in `filter` to benefit from caching and reduced CPU. #Elasticsearch# #QueryDSL#
๋” ๋ณด๊ธฐ