Spis treściKliknij link, aby przejść do wybranego miejsca
Elasticsearch: standard de factoJak to działa wewnątrzCo Elasticsearch robi dobrzeCiemna strona: dramat licencyjnyOpenSearch: fork od AmazonJakie są różnice między OpenSearch a Elasticsearch?Kiedy wybierać OpenSearch?Alternatywy: kiedy Elasticsearch to za dużoTypesenseMeilisearchSolrPostgreSQL Full-Text SearchSQLite FTS5Qdrant, Weaviate, Pinecone - bazy danych wektoroweTabela porównawcza
Elasticsearch
OpenSearch
Typesense
Meilisearch
PG FTS
Ліцензія
Elastic/AGPL
Apache 2.0
GPL-3
MIT
PostgreSQL
Мова
Java
Java
C++
Rust
C
Typo tolerance
Так (fuzzy)
Так
Відмінна
Відмінна
Ні
Агрегації
Розширені
Розширені
Базові
Базові
Обмежені
Складність
Висока
Висока
Низька
Низька
-
RAM (мін.)
1–2 GB
1–2 GB
256 MB
256 MB
-
Векторний пошук
Так (8.x+)
Так
Так
Так
pgvector
Ідеально для
Enterprise, logs
AWS, відкритість
Продукти, docs
Стартапи
Малі проєкти
Jak wybierać?Rzeczywiste przypadki z praktyki
Ta treść została automatycznie przetłumaczona z ukraińskiego.
Wyobraź sobie, że masz milion dokumentów. Chcesz znaleźć wszystkie, w których występuje słowo „kawa”, ale tylko te, w których jest używane w kontekście „przygotowania”, a nie „sklepu”. I posortować je według trafności. A wszystko to - w 50 milisekund.
Baza danych relacyjnych tutaj się załamie. Potrafi WHERE body LIKE '%kawa%' - ale to pełne przeszukiwanie wierszy, bez zrozumienia języka, bez rankingowania, bez odporności na błędy w pisowni. Przy milionie rekordów zajmie to sekundy. Przy miliardzie - minuty.
Dlatego istnieją silniki wyszukiwania - wyspecjalizowane systemy zbudowane wokół jednej idei: uczynić wyszukiwanie w dużych zbiorach tekstu szybkim, elastycznym i inteligentnym.
Elasticsearch: standard de facto
Elasticsearch to rozproszony silnik wyszukiwania i platforma analityczna zbudowana na Apache Lucene. Lucene to biblioteka Java, która istnieje od 1999 roku i implementuje klasyczne algorytmy wyszukiwania informacji. Elasticsearch pojawił się w 2010 roku jako wygodna nakładka HTTP na Lucene z obsługą klastrowania.
Jak to działa wewnątrz
U podstaw leży koncepcja indeksu odwróconego. Zamiast przechowywać tekst każdego dokumentu i wyszukiwać w nim, system buduje słownik: „które słowo - w których dokumentach występuje”. To przypomina indeks rzeczowy w książce.
"kawa" → [doc_3, doc_7, doc_42, doc_100] "przygotowanie" → [doc_7, doc_15, doc_42]
Przy zapytaniu „przygotowanie kawy” system znajduje przecięcie zbiorów w milisekundy - niezależnie od rozmiaru kolekcji.
Na tym Elasticsearch dodaje:
- Analizatory - potoki przetwarzania tekstu: tokenizacja, usuwanie słów kluczowych, stemming (redukcja do rdzenia), transkrypcja.
- Scoring - algorytm BM25 (wcześniej TF-IDF) przypisuje każdemu wynikowi numeryczną ocenę trafności.
- Shard i repliki - indeks dzieli się na części (shardy), które są rozdzielane po węzłach klastra. Repliki zapewniają odporność na awarie.
- REST API - cała interakcja odbywa się przez JSON po HTTP. Żadne specyficzne protokoły klienckie.
Co Elasticsearch robi dobrze
Wyszukiwanie pełnotekstowe - to oczywiste. Ale oprócz tego:
Agragacje - analityka w czasie rzeczywistym. „Ile zamówień w każdym mieście w ciągu ostatnich 7 dni, podzielonych na godziny?” - jedno zapytanie, natychmiastowa odpowiedź.
Geo-wyszukiwanie - „znajdź wszystkie kawiarnie w promieniu 2 km od współrzędnych”. Elasticsearch natywnie obsługuje indeksy geoprzeestrzenne.
Wyszukiwanie wektorowe (kNN) - od wersji 8.x wsparcie dla gęstych wektorów pozwala na realizację wyszukiwania semantycznego opartego na embeddingach. To znaczy, że można znaleźć dokumenty według treści, a nie według dokładnego dopasowania słów.
Stos obserwowalności (ELK) - Elasticsearch + Logstash + Kibana. Klasyczne połączenie do zbierania i analizy logów. Tysiące firm uruchamiają to do monitorowania infrastruktury.
Ciemna strona: dramat licencyjny
W 2021 roku Elastic NV zmienił licencję Elasticsearch i Kibana z Apache 2.0 na SSPL (Server Side Public License) oraz Elastic License 2.0. Obie licencje zabraniają udostępniania Elasticsearch jako usługi w chmurze bez umowy komercyjnej z Elastic.
Powód: Amazon Web Services uruchomił Amazon Elasticsearch Service (później przemianowany na OpenSearch) i faktycznie zarabiał na cudzym kodzie open-source, nie wnosząc nic w zamian. Elastic postanowił zamknąć tę lukę.
Społeczność open-source przyjęła to ambiwalentnie. SSPL jest odrzucane przez większość definicji open-source, w tym OSI. Dla wielu oznaczało to: Elasticsearch nie jest już naprawdę otwarty.
OpenSearch: fork od Amazon
W odpowiedzi na zmianę licencji AWS w 2021 roku forkował Elasticsearch 7.10 (ostatnia wersja pod Apache 2.0) i stworzył OpenSearch. Jednocześnie forkowano Kibana → OpenSearch Dashboards.
OpenSearch pozostaje pod Apache License 2.0. Amazon nadal oferuje go jako zarządzaną usługę - Amazon OpenSearch Service.
Jakie są różnice między OpenSearch a Elasticsearch?
W momencie forka - praktycznie żadna. API były zgodne w 95%. Z czasem się rozeszły:
Kiedy wybierać OpenSearch?
- Jeśli jesteś już na AWS i korzystasz z zarządzanej usługi
- Jeśli ważna jest czystość licencyjna (Apache 2.0)
- Jeśli potrzebujesz wbudowanych funkcji zabezpieczeń za darmo
- Jeśli twoja drużyna nie chce być zależna od firmy komercyjnej
Alternatywy: kiedy Elasticsearch to za dużo
Elasticsearch jest potężny, ale także ciężki. Minimalny klaster to co najmniej 3 węzły, kilka gigabajtów RAM, skomplikowana konfiguracja. Dla małych i średnich projektów często jest to overkill.
Typesense
Typesense to nowoczesny silnik wyszukiwania napisany w C++, skoncentrowany na prostocie i szybkości.
Kluczowe cechy:
- Natychmiastowa konfiguracja: jeden plik binarny, konfiguracja z 5 wierszy
- Tolerancja błędów z pudełka - „kawiarnia” znajdzie „kawiarnia”, „café”, „кафэ”
- Wyszukiwanie wektorowe i hybrydowe (tekst + wektory)
- Wbudowane wsparcie dla wyszukiwania facetu
- Licencja: GPL-3.0 (self-hosted), dostępny jest chmurowy SaaS
Typesense doskonale nadaje się do wyszukiwania produktów, artykułów, dokumentacji.
Ograniczenia: nie nadaje się do analityki logów, brak agregacji na poziomie Elasticsearch, mniejsza ekosystem.
Meilisearch
Meilisearch to open-source (MIT) silnik wyszukiwania napisany w Rust, z naciskiem na doświadczenie dewelopera.
# Uruchomienie w 10 sekund
docker run -p 7700:7700 getmeili/meilisearch
curl -X POST 'http://localhost:7700/indexes/movies/documents' \
-d '[{"id": 1, "title": "Gwiezdne wojny"}]'
Funkcje:
- Ekstremalnie prosty REST API
- Wyszukiwanie w czasie rzeczywistym (instant search) z pudełka
- Filtry, facety, sortowanie
- Wsparcie wielojęzyczne
- Wyszukiwanie wektorowe (od wersji 1.3)
Ograniczenia: mniej skalowalny niż Elasticsearch, nie nadaje się do petabajtowych danych, ograniczone możliwości analityczne.
Solr
Apache Solr to „starszy brat” Elasticsearch. Również zbudowany na Lucene, pojawił się w 2004 roku. Przez długi czas był standardem w branży.
Dziś Solr ustępuje Elasticsearch pod względem wygody API, dokumentacji i funkcji cloud-native. Ale są nisze, w których Solr wygrywa: klasyczne wyszukiwanie enterprise, bardzo skomplikowane scenariusze facetingu, integracja z Hadoop.
PostgreSQL Full-Text Search
Tak, twoja ulubiona relacyjna baza danych potrafi wyszukiwanie pełnotekstowe. I jest całkiem dobra.
SELECT title, ts_rank(search_vector, query) AS rank
FROM articles, to_tsquery('polski', 'wyszukiwanie & silnik') query
WHERE search_vector @@ query
ORDER BY rank DESC;
PostgreSQL obsługuje słowniki dla różnych języków (w tym polski przez pl_hunspell), indeksy GIN/GiST dla szybkiego wyszukiwania oraz ranking według trafności.
Kiedy to wystarczy: do kilku milionów dokumentów, jeśli nie potrzebujesz tolerancji błędów i skomplikowanych agregacji, jeśli chcesz zminimalizować infrastrukturę.
Kiedy to za mało: duże zbiory, potrzebne fuzzy search, synonimy, skomplikowane rankingowanie, analityka w czasie rzeczywistym.
SQLite FTS5
Dla bardzo małych projektów lub aplikacji mobilnych - FTS5 moduł SQLite. Wyszukiwanie pełnotekstowe bez żadnych zewnętrznych zależności.
Qdrant, Weaviate, Pinecone - bazy danych wektorowe
To osobna klasa systemów, które zyskują na popularności wraz z rozwojem LLM. Zamiast wyszukiwania według słów kluczowych - wyszukiwanie według bliskości semantycznej przez wektory (embeddings).
- Qdrant (Rust, MIT) - szybki, gotowy do produkcji, self-hosted lub chmurowy.
- Weaviate (Go, BSD-3) - hybrydowe wyszukiwanie + wbudowana integracja z OpenAI/Cohere.
- Pinecone - chmurowy SaaS, najłatwiejszy w konfiguracji.
Te systemy nie zastępują Elasticsearch - one go uzupełniają. Hybrydowe podejście (BM25 + wyszukiwanie wektorowe) często daje najlepsze wyniki.
Tabela porównawcza
Wybierz Elasticsearch jeśli:
- Potrzebna analityka logów (stos ELK)
- Skala - dziesiątki milionów dokumentów i więcej
- Potrzebne skomplikowane agregacje i pulpity Kibana
- Zespół gotowy zainwestować czas w konfigurację
Wybierz OpenSearch jeśli:
- Jesteś na AWS lub ważna jest licencja Apache 2.0
- Potrzebna ta sama funkcjonalność co w Elasticsearch
Wybierz Typesense lub Meilisearch jeśli:
- Startup lub średni projekt
- Priorytet - szybki start i doświadczenie dewelopera
- Potrzebna tolerancja błędów bez skomplikowanej konfiguracji
Pozostań przy PostgreSQL FTS jeśli:
- Mniej niż milion dokumentów
- Nie chcesz dodatkowej infrastruktury
- Podstawowa jakość wyszukiwania wystarcza
Rzeczywiste przypadki z praktyki
GitHub używa Elasticsearch do wyszukiwania w kodzie i repozytoriach - miliardy dokumentów, subsekundowa odpowiedź.
Wikipedia - Elasticsearch do wyszukiwania w artykułach. Około 60 milionów stron, 300+ języków.
Netflix - stos ELK do analizy logów. Petabajty danych.
Shopify - Elasticsearch do wyszukiwania produktów w milionach sklepów.
Jednocześnie tysiące mniejszych produktów świetnie funkcjonują na Meilisearch lub Typesense - i nie potrzebują złożoności Elasticsearch.
Elasticsearch to Photoshop wśród silników wyszukiwania: niezwykle potężny, ale z trudną krzywą uczenia się i poważnymi wymaganiami systemowymi. OpenSearch to jego czysty licencyjnie bliźniak.
Jednak lata 2024–2026 pokazują: konkurencja żyje. Typesense i Meilisearch zdobywają publiczność w średnim segmencie. Bazy danych wektorowe otwierają nowy wymiar wyszukiwania semantycznego. PostgreSQL z pgvector cicho podchodzi od dołu.
Właściwy wybór to nie „najpotężniejsze rozwiązanie”, ale „najprostsze rozwiązanie, które rozwiązuje twój problem”. Czasami to Elasticsearch. Czasami - LIKE '%wyszukiwanie%' w PostgreSQL.
Najważniejsze - zrozumieć, co budujesz, i nie strzelać z armaty do wróbli.
![[Fix] Heroku / SearchBox addon - błąd indeksowania "Klient nie może zweryfikować, że serwer to Elasticsearch"](https://d3kb0xa9zqcv9v.cloudfront.net/mt4y3m9gz57nphovbgtc98vfvtd7)
