Elasticsearch
Also Known As
ES
Elastic
inverted index
full-text search engine
TL;DR
A distributed full-text search engine — inverted indexes enable sub-second keyword and relevance-ranked search across millions of documents.
Explanation
Elasticsearch stores documents as JSON in an inverted index — each unique term maps to the documents containing it. Queries: match (full-text), term (exact), bool (combine queries), range (numeric/date ranges), and aggregations (faceted counts). Relevance scoring uses BM25 by default. PHP clients: ruflin/elastica, elastic/elasticsearch-php. Alternatives: Meilisearch (simpler setup, instant search), Typesense (typo-tolerant), OpenSearch (AWS fork). For PHP apps with moderate search needs, Meilisearch is often simpler to operate.
Diagram
flowchart TD
DOC[Document - JSON] --> INDEX[(Index<br/>like a DB table)]
INDEX --> SHARDS[Shards<br/>split for scale]
SHARDS --> REPLICAS[Replica shards<br/>for redundancy]
subgraph Query Flow
SEARCH[Search request] --> COORD[Coordinating node]
COORD --> ALL[Query all shards in parallel]
ALL --> MERGE[Merge and rank results]
MERGE --> TOP[Return top N hits]
end
subgraph Indexing
PHP_DOC[PHP sends doc] --> INVERTED[Build inverted index<br/>token to doc list]
end
style INDEX fill:#6e40c9,color:#fff
style COORD fill:#1f6feb,color:#fff
style TOP fill:#238636,color:#fff
Common Misconception
✗ Elasticsearch is only for large scale — it's a solid choice for any app needing full-text search, faceted filtering, or complex aggregations that a database cannot handle efficiently.
Why It Matters
LIKE '%keyword%' on a million-row table takes seconds; Elasticsearch returns results in milliseconds regardless of corpus size — it transforms search from a bottleneck to a feature.
Common Mistakes
- High-cardinality keyword fields not mapped as 'keyword' type — text fields are analysed and tokenised; exact values need keyword type.
- Storing large binary or irrelevant data in Elasticsearch — only index what needs to be searched, store everything else in the primary database.
- Not defining mappings before indexing — auto-mapping guesses types and often maps numbers as text.
- Querying without a filter context for exact matches — filters are cached and much faster than queries for boolean conditions.
Code Examples
✗ Vulnerable
// Auto-mapping leads to wrong type inferences:
$client->index(['index' => 'products', 'body' => [
'price' => '19.99', // Auto-mapped as text! Cannot range query
'in_stock' => 'true', // Auto-mapped as text! Cannot boolean filter
'description' => 'Great product',
]]);
// Range query: {"range":{"price":{"gte":10}}} — fails silently on text field
✓ Fixed
// Explicit mapping before indexing:
$client->indices()->putMapping(['index' => 'products', 'body' => [
'properties' => [
'name' => ['type' => 'text'], // Analysed for full-text
'name_exact' => ['type' => 'keyword'], // Exact match/aggregation
'price' => ['type' => 'float'], // Numeric range queries
'in_stock' => ['type' => 'boolean'],
'description' => ['type' => 'text'],
'tags' => ['type' => 'keyword'],
]
]]);
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
23
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Amazonbot 7
Perplexity 5
Google 3
Unknown AI 2
Ahrefs 2
Majestic 1
SEMrush 1
Also referenced
How they use it
crawler 19
crawler_json 2
Related categories
⚡
DEV INTEL
Tools & Severity
🟡 Medium
⚙ Fix effort: High
⚡ Quick Fix
Use Elasticsearch for full-text search and faceted filtering — let PHP handle business logic and use Elasticsearch only for search; sync data via queue workers, not inline in HTTP requests
📦 Applies To
PHP 5.0+
web
cli
laravel
🔍 Detection Hints
LIKE '%term%' full-text search on large tables; no faceted filtering; slow search degrading with data growth; MySQL FULLTEXT at its limits
Auto-detectable:
✗ No
laravel-scout
elasticsearch-php
kibana
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: Medium
✗ Manual fix
Fix: High
Context: File
Tests: Update