Wyszukiwanie wektorowe w Laravel wspiera teraz MariaDB

Laravel 13 umożliwia programistom wykonywanie natywnych zapytań o wyszukiwanie wektorowe w MariaDB, dodając możliwości wyszukiwania semantycznego do ekosystemu Laravel bez konieczności przechodzenia na PostgreSQL.

Nowe wsparcie zastępuje wcześniejszą implementację ograniczoną wyłącznie do PostgreSQL, dzięki czemu znana metoda whereVectorSimilarTo działa teraz bezpośrednio z połączeniem MariaDB. Jeśli budujesz silniki rekomendacyjne, narzędzia do podobieństwa dokumentów lub dowolną funkcję opartą na logice „najbliższego sąsiada” (nearest-neighbor), ta zmiana eliminuje istotną barierę.

Dlaczego ta zmiana jest ważna

Query builder w Laravelu wykrywał wcześniej potrzeby wyszukiwania wektorowego za pomocą testu instanceof, który rozpoznawał jedynie połączenia PostgreSQL. Takie podejście wiązało tę funkcję z pojedynczym sterownikiem i zaśmiecało kod bazowy warunkami specyficznymi dla danej bazy danych.

Wydanie 13 przenosi tę logikę do warstwy gramatyki (grammar layer) i dodaje dwie metody specyficzne dla sterownika:

  • supportsVectorDistance() – informuje Laravel, czy aktualne połączenie potrafi obliczać odległości wektorowe.
  • compileVectorDistanceExpression() – buduje fragment SQL wykonujący obliczenia.

Przypisując te odpowiedzialności do każdego sterownika, framework rezygnuje z „hacka” polegającego na sprawdzaniu typów i toruje drogę do przyszłych rozszerzeń. Dodanie wsparcia dla innej bazy danych oznacza teraz zaimplementowanie kilku metod sterownika zamiast rozpraszania bloków warunkowych.

MariaDB otrzymuje natywne funkcje, MySQL nie

MariaDB posiada natywne funkcje wektorowe. Standardowy MySQL ich nie posiada, chyba że korzystasz ze specjalistycznej oferty chmurowej oferującej rozszerzenia AI.

Laravel celowo unika obliczania podobieństwa po stronie PHP. Obliczanie wektorów w PHP zepsułoby paginację i spowolniło aplikację bez ostrzeżenia. Wyświetlenie błędu w sytuacji, gdy sterownik nie może obsłużyć operacji, zapewnia bezpieczniejszy tryb awaryjny.

Co mogą teraz zrobić użytkownicy MySQL

Jeśli Twój stos technologiczny opiera się na zwykłym MySQL, masz trzy realne ścieżki:

  1. Migracja do MariaDB – bezpośredni zamiennik dla większości obciążeń MySQL, który zapewnia natywne wsparcie wektorowe przy zachowaniu tego samego ekosystemu.
  2. Dodanie dedykowanej usługi wyszukiwania – uruchomienie lekkiej instancji PostgreSQL obok MySQL wyłącznie do zapytań o podobieństwo.
  3. Rezygnacja z tej funkcji – wyszukiwanie semantyczne jest opcjonalne dla wielu aplikacji; jeśli korzyści nie przewyższają kosztów operacyjnych, pozostanie przy MySQL może być pragmatycznym wyborem.

Każda opcja wiąże się z kompromisami w zakresie złożoności operacyjnej, opóźnień i kosztów utrzymania. Decyzja zależy od tego, jak kluczowe dla propozycji wartości Twojego produktu jest wyszukiwanie wektorowe.

Lekcje dla projektowania API

Zmiana w Laravelu ilustruje szerszą zasadę projektowania: unikaj rozpraszania sprawdzeń specyficznych dla bazy danych w logice rdzenia. Gdy funkcja zależy od możliwości konkretnego silnika, należy ukryć tę zależność za interfejsem sterownika. Nowe podejście oparte na gramatyce robi właśnie to, przygotowując framework do przyszłych rozszerzeń bez konieczności modyfikowania głównego query buildera.

Programiści tworzący własne pakiety powinni zwrócić na to uwagę. Jeśli znajdziesz sprawdzenia instanceof typu bazy danych w warstwie usług (service layer), przenieś tę odpowiedzialność do sterownika lub dedykowanego adaptera. Pozwoli to zachować czyste publiczne API i zapewni przyszłościowość kodu.