TL;DR
Dla prostych zapytań (np. „znajdź po nazwie”) wystarczy wyszukiwanie w bazie (LIKE, PostgreSQL FTS). Gdy potrzebujesz pełnotekstowego wyszukiwania, fuzzy match, filtrów (facety), sortowania po relevance lub milionów dokumentów – warto wdrożyć silnik typu Elasticsearch lub OpenSearch. Wymaga to indeksowania danych i utrzymania dodatkowej infrastruktury.
Dla kogo to jest
- Deweloperów budujących katalogi, sklepy, panele z zaawansowanym wyszukiwaniem
- Architektów systemów z dużymi zbiorami danych do przeszukiwania
- Osób szukających alternatywy dla LIKE / prostego FTS w bazie
Fraza (SEO)
elasticsearch wyszukiwarka, full-text search, wyszukiwarka full-text, elasticsearch kiedy używać
Kiedy wystarczy baza danych?
- Proste wyszukiwanie – jedno pole, dokładne lub prefix (np.
WHERE name ILIKE 'Jan%') - PostgreSQL FTS – do kilkuset tysięcy rekordów, językowe stemming, ranking; bez faceting i zaawansowanej analityki
- Mały wolumen – do ~100–500 tys. dokumentów FTS w Postgres często wystarczy
Kiedy rozważyć Elasticsearch / OpenSearch?
- Duży wolumen – miliony dokumentów, szybkie odpowiedzi (< 100 ms)
- Fuzzy search – literówki, „Jan Kowalski” vs „Kowalski Jan”
- Facety i filtry – cena, kategoria, data – bez spowalniania zapytania
- Wyszukiwanie w wielu polach – tytuł, opis, tagi z różnymi wagami
- Highlighting – podświetlanie fragmentów w wynikach
- Agregacje – statystyki, rekomendacje „podobne”, autocomplete (sugestie)
Elasticsearch vs OpenSearch
- Elasticsearch – dojrzały ekosystem, część Elastic Stack (Kibana, Beats). Od wersji 8.x licencja zmieniona – sprawdź warunki.
- OpenSearch – fork ES 7.10, open-source (Apache 2.0), kompatybilny API. Często wybierany przy obawach o licencję i koszty.
Oba nadają się do full-text search; wybór zależy od polityki licencyjnej, hostingu (np. AWS OpenSearch) i znajomości zespołu.
Jak to działa w skrócie?
- Indeks – dane są analizowane (tokenizacja, stemming, synonimy) i zapisywane w strukturze zoptymalizowanej pod wyszukiwanie.
- Zapytanie – użytkownik wpisuje frazę → analizator tokenizuje → zapytanie do indeksu (match, bool, filter) → ranking → wyniki.
- Synchronizacja – dane z bazy (Postgres, MySQL) muszą trafiać do indeksu: przy zapisie (event, trigger) lub batch job. Opóźnienie zależy od strategii (realtime vs okresowy sync).
Przykład prostego zapytania (Elasticsearch)
GET /products/_search
{
"query": {
"bool": {
"must": [
{ "multi_match": { "query": "laptop", "fields": ["name^2", "description"] } }
],
"filter": [
{ "term": { "category": "electronics" } },
{ "range": { "price": { "gte": 1000, "lte": 5000 } } }
]
}
},
"highlight": { "fields": { "name": {}, "description": {} } }
}
Alternatywy
- PostgreSQL FTS –
to_tsvector,to_tsquery, GIN index; bez dodatkowej infrastruktury - Meilisearch, Typesense – lżejsze, łatwe wdrożenie, dobra jakość wyszukiwania dla średnich zbiorów
- Algolia – SaaS, świetny UX (instant search), koszt przy dużym wolumenie
- Wyszukiwarka w CMS – np. Strapi, Contentful – często wystarczy do treści strony
Checklista przed wdrożeniem
- Określ wymagania: wolumen, fuzzy, facety, języki
- Oceń czy FTS w bazie nie wystarczy
- Wybór silnika: Elasticsearch / OpenSearch / Meilisearch / SaaS
- Strategia indeksowania i synchronizacji z główną bazą
- Hosting i koszt (self-hosted vs managed)
- Plan backupu i odzyskiwania indeksu
FAQ
Czy Elasticsearch zastępuje bazę danych?
Nie. Zazwyczaj baza (Postgres, MySQL) pozostaje źródłem prawdy; Elasticsearch to warstwa wyszukiwania. Dane replikujesz do indeksu.
Jak często aktualizować indeks?
Zależy od przypadku: krytyczne dane (ceny, dostępność) – przy każdej zmianie (event-driven). Mniej krytyczne – co kilka minut lub godzin (batch). Ważne: obsługa opóźnień w UI („wyniki mogą być z ostatnich 5 min”).
Meilisearch zamiast Elasticsearch?
Tak, jeśli nie potrzebujesz zaawansowanych agregacji i skomplikowanych mapowań. Meilisearch jest prostszy w instalacji i utrzymaniu, dobra jakość wyszukiwania out of the box.