Wyszukiwanie może odpowiadać szybko, a mimo to działać nieprawidłowo: wyświetlać usunięty rekord, pomijać niedawną modyfikację lub ujawniać treść, do której użytkownik nie ma już dostępu. Wyzwanie polega nie tylko na znajdowaniu tekstu, lecz także na zachowaniu zgodności wyników z aktualnymi danymi i uprawnieniami, nawet w przypadku opóźnień lub awarii.
Aby zaprojektować niezawodne wyszukiwanie tekstowe w PHP, warto najpierw ustalić, czego użytkownik ma szukać i jakie opóźnienie jest akceptowalne. Następnie należy wybrać miejsce wykonywania zapytań oraz sposób utrzymywania każdego indeksu pochodnego. Baza danych powinna pozostać źródłem prawdy; indeks wyszukiwania jest możliwą do odtworzenia reprezentacją danych, a nie kolejnym miejscem ich edycji.
Zacznij od wymagań dotyczących wyszukiwania
Opisz rzeczywiste zapytania, zanim wybierzesz technologię. Czy wyszukujesz słowa w tytułach i opisach, frazy, prefiksy czy wartości w wielu polach? Czy stosujesz filtry według statusu, kategorii, daty, języka lub właściciela? Czy ważne są tolerancja błędów, synonimy, trafność albo sortowanie według daty?
Określ także cele operacyjne: akceptowalne opóźnienie, częstotliwość aktualizacji, przewidywaną skalę oraz zachowanie systemu, gdy wyszukiwanie jest niedostępne. „Aktualne” może oznaczać, że zmiana pojawia się natychmiast albo po kilku sekundach. Ta różnica wpływa na architekturę i powinna zostać jasno określona.
Do testowania jakości używaj reprezentatywnych zapytań. Uwzględnij popularne i rzadkie terminy, rekordy z pustymi polami, znaki diakrytyczne, różne języki oraz użytkowników o różnych uprawnieniach. Sprawdzaj nie tylko, czy pojawia się oczekiwany wynik, lecz także czy kolejność i filtry są sensowne.
Zdecyduj, czy wystarczy SQL
Zapytanie SQL może wystarczyć, gdy zbiór danych i zapytania są możliwe do obsłużenia, filtry są proste, a możliwości wyszukiwania w bazie danych odpowiadają wymaganiom. Istotne są silnik i jego konfiguracja: wyszukiwanie pełnotekstowe, normalizacja i trafność nie działają identycznie we wszystkich systemach. Sprawdź ich ograniczenia na rzeczywistych danych i zapytaniach.
SQL ma praktyczną zaletę: dane i wyszukiwanie mogą uczestniczyć w tym samym modelu spójności. Pozwala też uniknąć początkowej konieczności obsługi dodatkowej usługi i synchronizowania osobnego indeksu. Nie oznacza to, że każde zapytanie powinno wyszukiwać częściowe dopasowania w kolumnach bez odpowiedniej strategii; przeanalizuj plan wykonania, dostępne indeksy i koszt filtrów.
Rozważ wyspecjalizowany indeks, gdy zapytania wymagają możliwości, których SQL nie obsługuje dobrze, gdy opóźnienia lub obciążenie związane z wyszukiwaniem zakłócają podstawowe operacje albo gdy trafność, facety i analiza tekstu muszą rozwijać się niezależnie. To decyzja architektoniczna, a nie konieczność wynikająca z samego faktu, że aplikacja jest usługą SaaS lub zawiera wiele rekordów.
Zachowaj źródło prawdy i zdefiniuj indeks
Transakcyjna baza danych powinna być źródłem nadrzędnym dla tworzenia, modyfikowania i usuwania rekordów oraz zarządzania uprawnieniami. Udokumentuj, które encje i pola są indeksowane, jak są przekształcane oraz jaki identyfikator pozwala odnaleźć oryginalny rekord. Indeks może zawierać znormalizowany tekst i pola przeznaczone do filtrowania, ale nie powinien stać się edytowalną kopią danych bez jasno określonego procesu uzgadniania.
Uprawnienia wymagają szczególnej uwagi. Zdecyduj, czy indeks przechowuje pola służące do autoryzacji, czy aplikacja weryfikuje każdy wynik względem źródła prawdy. W żadnym z tych podejść wyszukiwanie nie może przyznawać dostępu tylko dlatego, że dokument nadal znajduje się w indeksie. Stosuj filtry dostępu po stronie serwera, a zmiany właściciela, widoczności lub roli traktuj jako zmiany, które również trzeba propagować.
Jeśli wymagana jest maksymalna ochrona przed opóźnieniami w aktualizacji uprawnień, ponownie sprawdzaj autoryzację podczas pobierania wyników, nawet jeśli oznacza to odrzucenie części z nich. Strategia powinna uwzględniać także to, co się stanie, jeśli taka weryfikacja się nie powiedzie: nie należy wówczas zwracać niezweryfikowanych wyników jako rozwiązania zastępczego.
Zapewnij możliwość odzyskiwania propagowanych zmian
Niezależna aktualizacja bazy danych, a następnie wysłanie wiadomości do kolejki, stwarza ryzyko utraty zmiany: pierwsza operacja może zostać zatwierdzona, a druga zakończyć się błędem. Często stosowanym wzorcem, który pozwala tego uniknąć, jest transakcyjna kolejka wyjściowa, czyli skrzynka nadawcza: transakcja zapisuje zmianę biznesową i oczekujące zdarzenie w tej samej bazie danych. Osobny proces publikuje lub przetwarza te zdarzenia i oznacza postęp.
Konsument aktualizuje indeks asynchronicznie. Powoduje to okres nieaktualności danych, dla którego należy określić i mierzyć jawny cel. Jeśli wymagany jest natychmiastowy odczyt po zapisie, zapewnij odpowiednią strategię, na przykład zwracanie świeżo zapisanego rekordu w odpowiedzi albo tymczasowe odpytywanie źródła prawdy. Nie obiecuj natychmiastowej spójności, jeśli przepływ jest asynchroniczny.
Zaprojektuj przetwarzanie tak, aby było idempotentne: dwukrotne odebranie tego samego zdarzenia nie może powodować duplikowania dokumentów ani przywracania starszych danych. Uwzględnij stabilny identyfikator rekordu oraz, w razie potrzeby, wersję lub numer sekwencyjny zmiany. Jeśli zdarzenia mogą docierać poza kolejnością, nie dopuść, by starsza wersja nadpisała nowszą. Ponawianie prób musi być bezpieczne, a komunikaty, których nie da się przetworzyć, powinny być widoczne do zbadania, a nie znikać bez śladu.
Traktuj usuwanie i odbudowę jako typowe przypadki
Usunięcie musi być jawnie propagowane. Jeśli system fizycznie usuwa rekord, zanim worker zdąży go odczytać, zdarzenie powinno zawierać dane potrzebne do usunięcia jego dokumentu. W przepływach obarczonych opóźnieniami lub ponawianiem prób znacznik usunięcia — tombstone — albo wersja usunięcia może zapobiec ponownemu utworzeniu wyniku przez starsze zdarzenie.
W przypadku zmian schematu lub uszkodzonych indeksów odbuduj indeks ze źródła prawdy w ograniczonych partiach. Zapisuj punkt postępu, monitoruj błędy i ograniczaj obciążenie bazy danych. Podczas zapełniania nowego indeksu nadal propaguj zmiany wprowadzane w tym czasie; w przeciwnym razie indeks może stać się nieaktualny, zanim zostanie aktywowany.
Gdy nowy indeks będzie gotowy i zweryfikowany, przełącz odczyty w kontrolowany sposób, na przykład za pomocą konfiguracji lub aliasu zgodnego z wybraną technologią. Zachowaj możliwość powrotu podczas sprawdzania wyników. Stopniowe włączanie to decyzja operacyjna; nie jest równoznaczne z niekontrolowanym ujawnianiem użytkownikom zmian w produkcie.
Mierz spójność i przygotuj się do obsługi systemu
Monitoruj opóźnienie między zatwierdzeniem zmiany a jej dostępnością w wyszukiwaniu, a także oczekujące zdarzenia, błędy, ponowienia prób i trwałe niepowodzenia. Pozornie aktywna kolejka może ukrywać zablokowane zdarzenie. Ustal progi alertów odpowiednie do celu dotyczącego aktualności danych oraz procedurę ponawiania prób lub naprawiania dokumentów.
Zaplanuj uzgadnianie danych: porównuj próbkę albo — jeśli to wykonalne — całe zbiory rekordów, które powinny być indeksowane, z istniejącymi dokumentami. Pozwala to wykryć utracone wiadomości, wadliwe przekształcenia i usunięcia, które nie zostały propagowane. Rozbieżność powinna prowadzić do udokumentowanego działania, takiego jak ponowne indeksowanie rekordu lub odbudowa indeksu.
Lista kontrolna przed wdrożeniem na produkcję
- Czy zapytania i kryteria trafności zostały zweryfikowane na reprezentatywnych przypadkach?
- Czy udokumentowano źródło prawdy, indeksowane pola i sposób ich przekształcania?
- Czy zmiany i usunięcia docierają do indeksu również po częściowej awarii?
- Czy przetwarzanie toleruje powtarzające się wiadomości i wiadomości docierające poza kolejnością?
- Czy uprawnienia są stosowane podczas wyszukiwania i aktualizowane po zmianach?
- Czy mierzone jest opóźnienie i istnieje procedura uzgadniania danych oraz odbudowy indeksu?
- Czy istnieje plan weryfikacji nowego indeksu i powrotu do poprzedniego rozwiązania, jeśli wyniki się pogorszą?
Niezawodne wyszukiwanie tekstowe w PHP zależy mniej od wyboru modnej technologii, a bardziej od zdefiniowania spójności, uprawnień i możliwości odzyskiwania. Zacznij od najprostszego rozwiązania, które spełnia zmierzone wymagania. Jeśli SQL przestanie obsługiwać wymagane zapytania lub zapewniać potrzebną wydajność, zastosuj wyspecjalizowany indeks z jawnym, monitorowalnym i możliwym do odtworzenia procesem synchronizacji.
