Wyszukiwarka Elasticsearch w PrestaShop: konfiguracja

Opcje silnika

• Natywny (PrestaShop): brak zewnętrznego silnika i niczego do indeksowania. Moduł wyszukuje i filtruje bezpośrednio w bazie danych PrestaShop. Pozwala uruchomić wyszukiwanie od razu i podłączyć silnik później; sklep nigdy nie zostaje bez działającego wyszukiwania.
• Elasticsearch: obsługuje główne wersje 6, 7, 8 i 9 z automatycznym wykrywaniem wersji.
• OpenSearch: wykrywany automatycznie i obsługiwany jak nowoczesny klaster bez typów, niezależnie od wersji 1.x/2.x/3.x.
• Meilisearch: lekka, łatwa w hostowaniu alternatywa; przeszukiwane pola, fasety, synonimy, słowa pomijane (stop-words) i tolerancja literówek są mapowane na Meilisearch automatycznie.

Ustawienia połączenia

• Host: pełny adres URL silnika (może zawierać prefiks ścieżki, np. https://cluster.provider.com/my-space).
• Base path: opcjonalny prefiks ścieżki dodawany do każdego żądania, dla wynajmowanej przestrzeni wyszukiwania na współdzielonych instancjach.
• Index prefix: przestrzeń nazw izolująca indeksy, dzięki której kilka sklepów może bezpiecznie współdzielić jeden silnik. Nowa instalacja otrzymuje własny losowy prefiks (ps_cll_ i sześć znaków); instalacja zaktualizowana z wcześniejszej wersji zachowuje swój.
• Authentication: dla Elasticsearch/OpenSearch: HTTP Basic lub klucz API; dla Meilisearch: klucz główny lub zakresowy typu Bearer. Po zapisaniu hasło i klucz API nie są już nigdy wyświetlane na stronie: pozostawienie pustego pola zachowuje je (dla tego samego serwera), wpisanie nowej wartości je zastępuje, a zaznaczenie pola wyboru je usuwa.
• Test connection: sprawdza, czy silnik jest osiągalny, i podaje wykrytą wersję.

Ile kosztuje pozostanie w trybie „Natywny” przy dużej skali, na naszych własnych liczbach

Tryb „Natywny” pozwala natychmiast uruchomić sklep, ale przy dużym katalogu natywny silnik PrestaShop ma realny koszt, który warto poznać, zanim wyjdzie na jaw na produkcji. Najczęstszą przyczyną nie jest „wolna baza danych”: te same obliczenia (które produkty pasują do bieżącego wyszukiwania) są wykonywane od zera dla każdego filtra, zamiast raz i z ponownym użyciem wyniku, więc koszt przestaje być proporcjonalny do liczby produktów, a staje się proporcjonalny do liczby produktów pomnożonej przez liczbę filtrów.

W syntetycznym katalogu liczącym 200 000 produktów, przy użyciu samego natywnego silnika, strona wyników wyszukiwania ładowała się 28 sekund, a strona dużej kategorii 30 sekund przed skoncentrowaną rundą optymalizacji; po niej ta sama strona ładuje się od 2 do 6 sekund. Nadal sekundy, a nie milisekundy: to praktyczny powód, dla którego po przekroczeniu pewnej wielkości katalogu podłączenie Elasticsearch, OpenSearch lub Meilisearch przestaje być luksusem i staje się warunkiem sprawnego działania strony.

Przejęcie wyszukiwania w sklepie

Po włączeniu opcji Take over site search każde wyszukiwanie i każda lista kategorii jest obsługiwana przez silnik za pośrednictwem natywnego dostawcy produktów PrestaShop, bez zmian w motywie. Jeśli silnik stanie się kiedykolwiek niedostępny albo odpowie na listę błędem, moduł automatycznie wraca do wyszukiwania natywnego, więc sklep nigdy nie pokazuje błędu. Silnik, który przestaje odpowiadać, jest pomijany przez 30 sekund, a potem jedno szybkie sprawdzenie decyduje, czy wrócił, więc wolny lub zablokowany silnik nigdy nie spowalnia stron sklepu; zmiany produktów, których w tym czasie nie otrzymał, wysyła następne wywołanie crona. Jeśli moduł ps_facetedsearch jest nadal aktywny, strona konfiguracji modułu ostrzega o tym (z przyciskiem „Nie pokazuj tego ponownie” dla sklepu, który celowo go zostawia), ponieważ zwykle powinien działać tylko jeden moduł fasetowy.

Grupy klientów, ukryte ceny i dokładne kody

Produkty i kategorie zarezerwowane dla niektórych grup klientów pozostają zarezerwowane: moduł stosuje regułę PrestaShop (produkt jest widoczny tylko wtedy, gdy jedna z jego aktywnych kategorii jest otwarta dla jednej z grup klienta) do wyników wyszukiwania, filtrów i ich liczników, autouzupełniania, skrótów do kategorii, wyróżnionych produktów i strony bez wyników. Ceny również działają jak w PrestaShop: podpowiedź pokazuje cenę, a filtr ceny się pojawia, tylko wtedy, gdy sam PrestaShop pokazałby ceny temu klientowi. Wyszukiwanie, które jest dokładnie indeksem produktu, kodem EAN-13, UPC lub MPN, wyświetla tylko produkty z tym kodem.

Trafność i dostrajanie

Panel ustawień wyszukiwania pozwala kształtować trafność wyników bez dotykania kodu:

• Field weights: jak bardzo nazwa, indeks, opis itd. wpływają na wynik.
• Match type & operator: strategia multi_match oraz to, czy słowa są łączone operatorem AND czy OR.
• Fuzziness & minimum-should-match: jak łagodna jest tolerancja literówek i ile słów musi pasować.
• Minimum word length i zakres przeszukiwanych pól dla każdego typu dokumentu. Krótszy termin nie jest ignorowany: dwuliterowe terminy, takie jak „tv”, są wyszukiwane dokładnie, bez tolerancji literówek.
• Language analysis: synonimy, słowa pomijane (stop-words), stemmer dla każdego języka (z wyjątkami), elizja, małe litery i dopasowanie infiksowe (n-gram) dla fragmentów słów.

Jak naprawdę działa tolerancja literówek

Za przełącznikiem „Fuzziness” kryją się dwa naprawdę różne mechanizmy o różnych kosztach. W Elasticsearch i OpenSearch dopasowanie rozmyte działa w czasie zapytania: silnik porównuje wyszukiwany termin z już zaindeksowanymi terminami, używając odległości edycyjnej (ile podstawień, wstawień lub usunięć zamienia jedno słowo w drugie), bez konieczności wcześniejszego poznania istniejących błędów pisowni. W silniku natywnym, który nie ma wbudowanego dopasowania rozmytego, moduł korzysta zamiast tego ze słownika trigramów zbudowanego z nazw produktów i marek z własnego katalogu: terminy są indeksowane według trzyliterowych fragmentów, co zawęża listę prawdopodobnych kandydatów, zanim zostanie obliczona dokładna odległość edycyjna na znacznie mniejszym zbiorze.

Szczegół, który sprawia, że słownik jest tani, zamiast spowalniać każde wyszukiwanie, to moment jego uruchomienia: dopiero wtedy, gdy dokładne wyszukiwanie zwróciło już zero wyników. Poprawnie wpisane zapytanie nigdy go nie dotyka. Na rzeczywistym katalogu poprawne zapytanie i zapytanie z błędem, które uruchamia słownik, zajęły w obu przypadkach tyle samo, niewiele czasu (od 0,16 do 0,19 sekundy w tej konfiguracji). Słownik jest też odbudowywany według harmonogramu (na przykład co tydzień, plus doraźne uzupełnienie za każdym razem, gdy wyszukiwanie bez wyników trafi na nieznane jeszcze słowo), dzięki czemu pozostaje zgodny z katalogiem w miarę jego zmian.

Nowoczesny modalny panel filtrów

• Nad siatką produktów znajdują się przycisk „Filters”, bieżąca liczba wyników oraz usuwalne chipy dla każdej zastosowanej wartości („Clear all” usuwa je wszystkie).
• Kliknięcie Filters otwiera modal dwupanelowy: nazwy filtrów po lewej (ze znaczkiem, gdy filtr jest używany), wartości wybranego filtra po prawej oraz przycisk „Show N results” z liczbą wyników na żywo w stopce.
• Filtry z wieloma wartościami są grupowane A→Z i mają pole „search within this filter”; kolory wyświetlane są jako próbki; cena pokazuje pola min/maks oraz suwak z dwoma uchwytami.
• Na urządzeniach mobilnych modal zajmuje cały ekran: dotknięcie nazwy filtra przechodzi do jego wartości, strzałka wstecz wraca, a potwierdzenie następuje na stałym dolnym pasku „Show N results”.
• Wszystko aktualizuje się przez AJAX z adresami URL, które można udostępniać (działa przycisk wstecz/dalej), a dzięki temu, że każdy element sterujący jest prawdziwym elementem formularza, istnieje tryb zapasowy bez JavaScript.

Konfiguracja każdej fasety

Dla każdej fasety można ustawić: włączenie/wyłączenie, kolejność, etykietę dla każdego języka, typ wyświetlania (pole wyboru, przycisk opcji, lista rozwijana, próbka koloru dla grup kolorów albo suwak dla ceny, wymiarów i cech liczbowych), tryb AND/OR, czy pokazywać liczniki, stan zwinięcia, limit wartości z opcją „show more” oraz ukrywanie, gdy pusta. Dostępne źródła: kategorie, marki, cechy, atrybuty, cena, dostępność, nowości, promocje i stan produktu. Fasety mogą być wyświetlane także na stronie wyników wyszukiwania oraz, po włączeniu jednego przełącznika, na stronach marki, dostawcy, nowości, promocji i bestsellerów, nie tylko w kategoriach. W Elasticsearch i OpenSearch każda grupa cech lub atrybutów jest liczona z uwzględnieniem wyborów w pozostałych grupach, więc wybór koloru aktualizuje też liczby przy rozmiarach (w silniku natywnym i w Meilisearch każda grupa jest nadal liczona osobno).

Facets: włączanie, kolejność, etykieta i styl każdego filtra (pole wyboru, przycisk opcji, lista rozwijana, próbka, suwak) z trybem AND/OR, licznikami i limitami

Szablony filtrów dla poszczególnych kategorii Filters Pro

Szablon filtrów to nazwana, wielokrotnego użytku konfiguracja faset, którą można przypisać do jednej lub kilku kategorii, aby różne kategorie udostępniały inny, inaczej uporządkowany zestaw filtrów. Na karcie Filter templates szablon tworzy się w tym samym edytorze faset co konfigurację globalną, z dodatkiem drzewa kategorii i opcji „also apply to subcategories”. Globalna konfiguracja Facets jest szablonem domyślnym (Default template): rozwiązaniem zapasowym dla każdej kategorii bez własnego szablonu oraz dla strony wyszukiwania.

Filter templates: przypisanie innego, inaczej uporządkowanego zestawu filtrów wybranym kategoriom; wiersz Default to globalne rozwiązanie zapasowe

Dlaczego wyłączenie liczników się opłaca przy dużych katalogach

Opcja „show counts” każdej fasety (powyżej) ma koszt zależny od silnika. W przypadku silnika zewnętrznego licznik jest darmowy, jako produkt uboczny tego samego zapytania, które oblicza wyniki: to własny mechanizm agregacji silnika, a nie dodatkowe zapytanie dla każdej wartości. W przypadku silnika natywnego każda pojedyncza wartość filtra może wymagać własnego zapytania zliczającego. W katalogu liczącym 200 000 produktów z około 2000 aktywnych grup faset wyłączenie dokładnych liczników skróciło ładowanie strony kategorii z 43 sekund do 12 sekund; w przypadku samych faset cech i atrybutów z 6,8 i 5,4 sekundy do 15 i 19 milisekund. W katalogu liczącym kilka tysięcy produktów liczniki prawie zawsze warte są swojego kosztu; w katalogu liczącym setki tysięcy produktów z wieloma cechami mogą być najdroższą pojedynczą częścią strony, a ich wyłączenie to często jedno pole wyboru, a nie przepisywanie kodu.

Poprawne liczniki także przy filtrach wielokrotnego wyboru

Licznik obiecujący „Red (12)”, po którym lista pokazuje 8 lub 15 produktów, to nie kosmetyczny szczegół: to znak, że licznik i kliknięcie odpowiadają na dwa różne pytania. Typowy przypadek to filtr z kilkoma wartościami zgrupowanymi pod jedną etykietą (na przykład „Red” obejmujące warianty Crimson, Scarlet i Burgundy): jeśli licznik sumuje, ile razy pojawia się każdy wariant, a kliknięcie stosuje warunek „musi mieć wszystkie naraz” zamiast „musi mieć co najmniej jeden”, wyświetlana liczba i liczba uzyskana nigdy się nie zgadzają. Poprawka, sprawdzona zarówno na sterowniku natywnym, jak i na Elasticsearch, polega na traktowaniu grupy od początku jako jednego zbioru (jedno zliczenie różnych produktów mających co najmniej jedną z wartości, a nie suma), tak aby licznik i kliknięcie opierały się dokładnie na tej samej logice. W przypadku Meilisearch, gdy takiego licznika nie można zagwarantować jako dokładnego, moduł woli nie pokazywać żadnej liczby, niż pokazać błędną: filtr bez licznika jest zawsze lepszy niż filtr, który kłamie.

Ukryty koszt: obliczenia w pamięci aplikacji zamiast w silniku

Inny błąd, znaleziony podczas wewnętrznego przeglądu kodu, dotyczył zakresu fasety ceny: obliczania minimum i maksimum przez załadowanie wszystkich pasujących wartości do pamięci aplikacji, zamiast zlecenia tego bazie danych lub silnikowi wyszukiwania. W katalogu, w którym oznaczało to około dwóch milionów wierszy, ten jeden krok kosztował 11 sekund i 965 MB pamięci na żądanie, co wystarczało, by wyczerpać limit pamięci hostingu współdzielonego i zwrócić stronę błędu zamiast suwaka. Przeniesienie tego samego obliczenia do agregacji w bazie danych lub silniku wyszukiwania przywróciło normalne, szybkie zapytanie: to dokładnie ten rodzaj obliczeń, do którego te systemy są stworzone, wykonywany jednym przejściem po już zaindeksowanych danych, a nie w kodzie aplikacji po fakcie. Błąd został naprawiony i dlatego w module każde minimum/maksimum i każdy licznik jest zawsze obliczany przez silnik lub bazę danych, nigdy przez pętlę PHP po wierszach.

Poprawne ceny dla grupy i waluty

Cena widoczna dla klienta to zawsze natywna cena PrestaShop. Ceny są indeksowane według grupy klientów × waluty, uwzględniają specific_price oraz podatek obowiązujący w danym kraju, a właściwa wartość jest wybierana w czasie zapytania. Dzięki temu opcjonalna faseta ceny i sortowanie po cenie są dokładne dla każdego kupującego: grupa hurtowa i grupa detaliczna widzą i sortują według własnych cen.

Ceny indywidualne dla B2B Advanced

Na karcie Advanced można włączyć ceny indywidualne. W przypadku klientów B2B, którzy mają własny cennik (specific_price przypisany do klienta), sortowanie i filtrowanie po cenie może wykorzystywać ich dokładną cenę indywidualną, a nie cenę grupową. Konfigurowalny limit (stały lub automatyczny, oparty na wolnym miejscu na dysku silnika) ogranicza liczbę klientów, dla których ceny są wstępnie obliczane, a dla tych kupujących można wyświetlać opcjonalne powiadomienie w każdym języku.

Advanced: włączanie cen indywidualnych (dla klienta) do sortowania i filtrowania B2B, z konfigurowalnym limitem

Aktualizacja stanów magazynowych bez spowalniania realizacji zamówienia

W przypadku silnika zewnętrznego każdy produkt istnieje podwójnie: jako wiersz w bazie danych PrestaShop i jako dokument w indeksie silnika. Gdy klient zmienia ilość w koszyku lub zamówienie zostaje potwierdzone, dostępność tego produktu musi zostać zaktualizowana także w indeksie. Najkosztowniejszy sposób to odbudowa całego dokumentu od zera przy każdej zmianie, nawet gdy zmieniają się tylko trzy liczby (ilość, dostępność, kolejność sortowania zależna od dostępności). Pomiary na PrestaShop 9.0.0 z dwoma sklepami podłączonymi do Elasticsearch pokazały, że pięciopozycyjne zamówienie z odbudową pełnego dokumentu dla każdej pozycji kosztowało 243 zapytania do bazy danych i 229 milisekund, tylko po to, by przenieść trzy liczby do indeksu. Dzięki dedykowanej ścieżce, która aktualizuje tylko faktycznie zmienione pola, zamiast odbudowywać cały dokument, to samo zamówienie spadło do 9 zapytań i 16-47 milisekund. Dlatego moduł oddziela aktualizacje stanów magazynowych (w czasie rzeczywistym, celowane) od reindeksacji strukturalnej (gdy faktycznie zmieniają się nazwa, cena lub kategorie): zmiana ilości w koszyku nigdy nie powinna ponosić kosztu pełnej reindeksacji.

Multisklep

Ustawienia połączenia i silnika są przypisane do sklepu. W kontekście „wszystkie sklepy” są zapisywane globalnie; w kontekście pojedynczego sklepu są zapisywane dla tego sklepu, z globalnym rozwiązaniem zapasowym. Oznacza to, że różne sklepy mogą wskazywać różne silniki lub klastry, a instalacja z jednym sklepem działa dokładnie tak jak dotychczas.

Hosting współdzielony / wynajmowana przestrzeń wyszukiwania

Nie jest potrzebny własny, dedykowany klaster. Wystarczy wskazać w polu Host współdzielony punkt końcowy z prefiksem ścieżki, ustawić Base path i Index prefix (przestrzeń nazw) oraz dodać klucz API dostawcy. Każde żądanie jest ograniczone do prefiksu, więc dane pozostają odizolowane na współdzielonej instancji, a całość działa tak samo w Elasticsearch, OpenSearch i Meilisearch.