Lesson 2 — Text search #

How text actually matches: analysis, exact terms, phrases, and the error-tolerant family. Everything below runs live on the logs collection (150 documents with message, level, host, url.path).

The use case #

The search box in front of users — application logs, product descriptions, support tickets. Users type in one casing, with typos, and your data is cased differently; the craft is choosing the right amount of looseness per question:

• “Exactly this level / status / tag, nothing else” — term on a keyword field: exact, fast, predictable.
• “Documents that talk about search” — match: the analyzer absorbs casing and word forms.
• “The words HTTP/1.1 200 together, in order” — phrase.
• “The user typed serch” — fuzzy tolerates the typo.
• “Every host named web-0 … web-9” — wildcard / regexp.
• “Why did my query match nothing?” — analysis: the analyzer decides what matches, and this lesson shows it in numbers.

Exact terms vs analyzed text #

A term query matches the stored value exactly — no tokenization, no casing help. A match query runs the field’s analyzer first, so casing and punctuation stop mattering:

Compare with a term on the keyword field level — exact, and therefore fast and predictable:

25 of the 150 log lines are errors. If you had written "ERROR" the count would be 0 — that is the analyzer difference in one number.

Both rows of that table have a SQL spelling — MATCH is the analyzed full-text lane, = is the exact lane (the SQL reference maps every construct):

SCORE() in the ORDER BY ranks by relevance — same as sorting on _score in the DSL.

Phrases #

phrase (alias match_phrase) requires the tokens in order, with slop budget for gaps. The dataset’s known answer — HTTP/1.1 200 appears in 75 documents — shows why analysis matters: the tokenizer folds HTTP/1.1 into one token, and the phrase matches it exactly:

MATCH_PHRASE is the SQL spelling — same tokenizer, same ordering rule:

The error-tolerant family #

Typos ( fuzzy), prefixes ( prefix), patterns ( wildcard and regexp), and endings ( suffix). The fuzzy query below misspells search as serch — one dropped letter — and still finds the same 25 GET /search requests the exact match at the top of this page found:

The typo survives the SQL spelling too — FUZZY with an explicit fuzziness (AUTO lets the engine pick by term length):

One string, full mini-language #

query_string packs booleans, fields, ranges and wildcards into one expression:

Combining with bool #

bool is the workhorse — must for scoring clauses, filter for cheap yes/no:

SQL composes the same way — AND chains a scoring clause with an exact one:

What you learned #

• term = exact value, match = analyzed text.
• Phrases order tokens; slop buys distance.
• Fuzzy/prefix/wildcard/regexp/suffix cover the typo and pattern cases.
• bool composes everything, with filter for scoring-free clauses.
• The SQL lane covers the same ground: MATCH/MATCH_PHRASE for analyzed text and phrases, FUZZY for typos, AND/NOT for composition — see the SQL syntax page.

Next: Lesson 3 — structure and numbers, or read the analysis API to inspect what any analyzer does to a string.