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. I wszystko to - w 50 milisekund.
Baza danych relacyjna tutaj zawiedzie. Potrafi WHERE body LIKE '%kawa%' - ale to pełne przeszukiwanie wierszy, bez rozumienia języka, bez rankingowania, bez odporności na błędy w pisowni. Na milionie rekordów zajmie to sekundy. Na 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ą klasteryzacji.
Jak to działa wewnątrz
Podstawą jest koncepcja indeksu odwróconego. Zamiast przechowywać tekst każdego dokumentu i przeszukiwać go, system buduje słownik: „jakie słowo - w jakich 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 wszystkim Elasticsearch dodaje:
- Analizatory - potoki przetwarzania tekstu: tokenizacja, usuwanie słów kluczowych, stemming (redukcja do rdzenia), transliteracja.
- 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 wspiera indeksy geoprzetwarzania natywnie.
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 wkładu z powrotem. Elastic postanowił zamknąć tę lukę.
Społeczność open-source przyjęła to ambiwalentnie. SSPL jest odrzucany 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 (ostatnią wersję 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 żadnych. API były zgodne w 95%. Z czasem się rozeszły:
Kiedy wybierać OpenSearch?
- Jeśli już jesteś na AWS i korzystasz z zarządzanej usługi
- Jeśli ważna jest czystość licencyjna (Apache 2.0)
- Jeśli potrzebujesz wbudowanych funkcji bezpieczeństwa 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 na błędy pisowni z pudełka - „kafe” znajdzie „kawę”, „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, mniejszy 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:
- Niezwykle prosty REST API
- Wyszukiwanie w czasie rzeczywistym (instant search) z pudełka
- Filtry, fasety, sortowanie
- Wsparcie dla wielu języków
- 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 niezłe.
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 wspiera 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 na błędy pisowni 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 całkiem 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 (embeddingi).
- 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 jest analityka logów (stos ELK)
- Skala - dziesiątki milionów dokumentów i więcej
- Potrzebne są skomplikowane agregacje i pulpity Kibana
- Zespół jest gotów zainwestować czas w konfigurację
Wybierz OpenSearch jeśli:
- Jesteś na AWS lub ważna jest licencja Apache 2.0
- Potrzebujesz tej samej funkcjonalności co Elasticsearch
Wybierz Typesense lub Meilisearch jeśli:
- Startup lub średni projekt
- Priorytet - szybki start i doświadczenie dewelopera
- Potrzebna tolerancja na błędy pisowni bez skomplikowanej konfiguracji
Pozostań przy PostgreSQL FTS jeśli:
- Mniej niż milion dokumentów
- Nie chcesz dodatkowej infrastruktury
- Podstawowa jakość wyszukiwania jest wystarczająca
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 doskonale 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 licencyjnie czysty bliźniak.
Jednak lata 2024–2026 pokazują: konkurencja jest żywa. Typesense i Meilisearch zyskują 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 to rozumieć, co budujesz, i nie strzelać z armaty do wróbli.
Podoba ci się?Zareaguj
🧵
Ten post nie ma jeszcze żadnych dodatków od autora.
