gik|iewicz

PlanetScale wydała 16 września TIN (Text INdex) – rozszerzenie pełnotekstowego wyszukiwania działające bezpośrednio w Postgresie, od razu w wersji ogólnnej. Zamiast dodawać osobną wyszukiwarkę obok bazy, firma przeniosła ranking BM25 do środka samego silnika. Benchmarki producenta pokazują około 227 qps wobec 26 qps dla ParadeDB i 1 qps dla natywnego GIN.

TL;DR: PlanetScale udostępniła 16 września TIN (Text INdex) – rozszerzenie pełnotekstowego wyszukiwania dla Postgresa, dostępne od razu w wersji ogólnnej. TIN wprowadza ranking BM25, zachowuje poprawną widoczność transakcji, współpracuje z replikacją, kopiami zapasowymi oraz złożonymi klauzulami WHERE. Według benchmarków producenta osiąga około 227 qps, podczas gdy ParadeDB notuje 26 qps, a natywny indeks GIN jedynie 1 qps.

Czym jest TIN i dlaczego PlanetScale go wydała?

TIN (Text INdex) to rozszerzenie pełnotekstowego wyszukiwania dla Postgresa, które PlanetScale wydała 16 września i które od razu otrzymało status wersji ogólnnej. Zamiast wymuszać na zespołach utrzymanie osobnej usługi wyszukiwania obok bazy danych, TIN realizuje wyszukiwanie wewnątrz samego Postgresa. Producent opisuje je jako potężne i niezawodne narzędzie, które radzi sobie ze złożonymi klauzulami WHERE oraz zachowuje prawidłową widoczność transakcji. Motywacja firmy wynika z ogłoszenia: zespoły utrzymujące aplikacje na Postgresie dotychczas potrzebowały dodatkowej infrastruktury, by zbudować pełnotekstowe wyszukiwanie. TIN ma to uprościć – indeks powstaje tam, gdzie dane, więc nie trzeba synchronizować dwóch osobnych systemów.

Jak czytamy w ogłoszeniu na profilu PlanetScale, rozszerzenie współpracuje również z replikacją i kopiami zapasowymi, a jego wydajność określono jako imponującą. Na przykład zespoły, które dziś utrzymują osobną wyszukiwarkę wyłącznie dla jednej funkcji aplikacji, mogą w rezultacie rozważyć redukcję tej dodatkowej warstwy. Najważniejsze jest jednak to, że wydanie nastąpiło bez etapu beta – TIN od pierwszego dnia jest oznaczone jako ogólnie dostępne, co w świecie rozszerzeń bazodanowych zdarza się rzadko.

Dlaczego wyszukiwanie pełnotekstowe w Postgresie dotychczas wymagało dodatkowych narzędzi?

Natywny Postgres oferuje indeksowanie GIN, ale według pomiarów opublikowanych przez PlanetScale osiąga ono około 1 zapytania na sekundę w ich benchmarku – to wynik praktycznie uniemożliwiający zastosowanie w produkcyjnym wyszukiwaniu. Dlatego zespoły przez lata sięgały po rozwiązania zewnętrzne: osobne silniki wyszukiwania, sidecary lub rozszerzenia takie jak ParadeDB. Każde z tych podejść oznacza dodatkowy system do utrzymania, synchronizacji danych oraz monitorowania.

Artykuł na byteiota podkreśla wprost w tytule brak sidecara – właśnie ta eliminacja dodatkowego procesu jest głównym argumentem sprzedażowym TIN. Ponadto przy każdej architekturze z zewnętrzną wyszukiwarką pojawia się problem spójności: indeks bywa nieaktualny względem bazy. TIN, działając wewnątrz Postgresa, ma ten problem zniknąć, ponieważ widoczność transakcji jest utrzymywana poprawnie przez samo rozszerzenie. Wobec tego wyszukiwanie podąża za tym, co faktycznie zapisano w bazie, a nie za tym, co zdążyła zaindeksować osobna usługa.

Jak TIN radzi sobie z transakcjami i replikacją?

TIN zachowuje poprawną widoczność transakcji oraz współpracuje z replikacją i kopiami zapasowymi – to trzy obszary, które PlanetScale wymienia jako pełnoprawnie obsługiwane. W praktyce oznacza to, że zapytanie pełnotekstowe zwróci wyłącznie dane widoczne dla danej transakcji, a nie te, które dopiero czekają na zatwierdzenie lub zostały wycofane. Dla aplikacji bankowych, sklepów czy systemów rezerwacyjnych ta poprawność jest warunkiem koniecznym, nie dodatkiem.

Współpraca z replikacją z kolei oznacza, że indeks nie jest przeszkodą przy skalowaniu odczytu – awansowanie replik czy przywracanie z kopii zapasowej nie wymaga przebudowy wyszukiwania z zewnątrz. Producent nie opublikował jednak szczegółów technicznych mechanizmu MVCC ani dokładnej dokumentacji zachowania indeksu podczas awansu repliki, dlatego tych detali nie da się potwierdzić na podstawie dostępnych źródeł. Znane jest natomiast stwierdzenie z ogłoszenia, że TIN działa ze złożonymi klauzulami WHERE – na przykład można łączyć warunki pełnotekstowe z filtrami po kolumnach w jednym zapytaniu, bez przekazywania danych do osobnej usługi.

Co oznacza BM25 w kontekście TIN?

BM25 to algorytm rankingu stosowany w wyszukiwaniu pełnotekstowym – ocenia dopasowanie dokumentu do zapytania, biorąc pod uwagę m.in. częstość terminów. W TIN służy on do porządkowania wyników, dzięki czemu użytkownik otrzymuje listę posortowaną według istotności, a nie jedynie zbiór pasujących wierszy. Z źródeł wynika, że BM25 jest jednym z filarów rozszerzenia, obok zoptymalizowanej obsługi MVCC.

Serwis GeekNews opisuje TIN jako rozwiązanie przenoszące wyszukiwanie do Postgresa właśnie dzięki BM25, zoptymalizowanemu MVCC oraz wydajności wyraźnie przewyższającej alternatywy w benchmarkach PlanetScale. Ponadto runtimewire zauważa, że wyniki opierają się na benchmarkach producenta oraz na celowo wolnym rozszerzeniu testowym open source – to istotne zastrzeżenie, ponieważ pomiary zlecone przez twórcę narzędzia zawsze wymagają samodzielnej weryfikacji na własnych danych.

Na benchmarku przedstawionym przez PlanetScale TIN utrzymuje się w zakresie około 200-290 zapytań na sekundę przez 10 minut testu, podczas gdy ParadeDB oscyluje wokół 20-30 qps, a natywny GIN pozostaje blisko zera. Przed zastosowaniem w produkcji warto sprawdzić te wyniki na własnym zbiorze danych – choćby ze względu na to, że charakterystyka obciążenia każdego systemu jest inna.

Powyższe liczby pochodzą z materiałów PlanetScale i opisują jeden konkretny scenariusz testowy, a nie uniwersalną gwarancję wydajności. Mimo to rozstrzał między wynikami jest na tyle wyraźny, że TIN zasługuje na włączenie do krótkiej listy opcji przy projektowaniu wyszukiwania w aplikacjach opartych na Postgresie.

Jak szybki jest TIN w benchmarkach PlanetScale?

Według benchmarku opublikowanego przez PlanetScale TIN utrzymuje się w zakresie około 200-290 zapytań na sekundę przez pełne 10 minut testu, a w punkcie z tooltipem osiąga około 227 qps. To wynik o rząd wielkości wyższy niż konkurencja w tym samym teście. Dane pochodzą od producenta, więc ich zastosowanie w praktyce wymaga weryfikacji na własnych danych.

Wizualizacja wyników pozwala przełączać widok między opóźnieniem a przepustowością oraz między percentylami P50, P90, P95 i P99, przy czym domyślnie widoczny jest P99. Skala osi Y sięga 350 zapytań na sekundę, a linia TIN przez cały czas trwania testu pozostaje wyraźnie powyżej pozostałych serii. Ponadto sama możliwość wyboru percentyla sugeruje, że producent koncentruje się na zachowaniu spójności wyników pod obciążeniem, a nie tylko na jednym szczęśliwym pomiarze. Mimo to benchmark opisuje jeden konkretny scenariusz, a nie uniwersalną gwarancję dla każdego obciążenia produkcyjnego.

Jak TIN wypada na tle ParadeDB i natywnego GIN?

W tym samym benchmarku ParadeDB oscyluje wokół 20-30 qps, natomiast natywny indeks Postgresa z GIN pozostaje blisko zera, w zakresie 0-5 zapytań na sekundę. TIN z wynikiem około 227 qps wyprzedza więc zarówno rozszerzenie zewnętrzne, jak i natywne rozwiązanie. To jednak dane producenta, zestawione w bezpośrednim porównaniu trzech technologii.

Warto rozumieć, co ta tabela oznacza w praktyce:

• TIN utrzymuje wysoką przepustowość przez cały 10-minutowy przebieg testu, a nie tylko w krótkim piku.
• ParadeDB pozostaje o rzędy wielkości wolniejsze w tym samym scenariuszu, choć wciąż używalne.
• Natywny GIN osiąga wynik praktycznie uniemożliwiający użycie w produkcyjnym wyszukiwaniu.
• Porównanie obejmuje jeden wybrany scenariusz testowy i wybrany percentyl opóźnienia, więc nie wyczerpuje wszystkich przypadków użycia.

Z tego powodu relacja na runtimewire zaznacza, że wyniki opierają się na benchmarkach producenta oraz na celowo wolnym rozszerzeniu testowym open source. Takie zestawienia zawsze wymagają samodzielnej weryfikacji, choćby dlatego, że charakterystyka danych i zapytań w każdym systemie jest inna.

Co przyniosło ogólne udostępnienie rozszerzenia 16 września?

TIN został wydany 16 września od razu w statusie ogólnej dostępności, bez etapu beta. Dla zespołów oznacza to, że producent uznaje rozszerzenie za gotowe do wdrożeń produkcyjnych od pierwszego dnia. W świecie rozszerzeń bazodanowych pominięcie fazy beta jest rzadkością i świadczy o dość dużej pewności siebie twórców.

Co więcej, ogólna dostępność wiąże się z pełnym zestawem deklarowanych możliwości: współpracą ze złożonymi klauzulami WHERE, replikacją oraz kopiami zapasowymi, przy zachowaniu poprawnej widoczności transakcji. Na przykład zespół planujący wdrożenie nie musi czekać na stabilizację API ani spodziewać się łamiących zmian w krótkim okresie. Producent opisał rozszerzenie z kolei jako potężne i niezawodne, a jego wydajność określił mianem imponującej. Jednakże takie sformułowania marketingowe zawsze należy zestawiać z rzeczywistymi wymaganiami własnego systemu.

Czy TIN jest open source i jak można go testować?

TIN sam w sobie nie został opisany w źródłach jako projekt open source. Jednakże runtimewire informuje, że PlanetScale udostępniła celowo spowolnione rozszerzenie testowe open source, które pozwala odtworzyć scenariusz benchmarku i porównać wydajność na własnych danych. To istotny gest w stronę weryfikowalności publikowanych wyników.

Dzięki temu zespoły mogą przeprowadzić własne pomiary zamiast polegać wyłącznie na liczbach producenta. Przebieg takiej weryfikacji obejmuje z grubsza następujące kroki:

• Przygotowanie zbioru danych odzwierciedlającego rzeczywiste obciążenie aplikacji.
• Uruchomienie rozszerzenia testowego open source udostępnionego przez PlanetScale.
• Odtworzenie scenariusza benchmarku, w tym wybranego percentyla opóźnienia.
• Porównanie wyników TIN, ParadeDB oraz natywnego GIN w tym samym środowisku.
• Interpretacja rezultatów w kontekście własnych wzorców zapytań.

Szczegółów licencji samego TIN oraz warunków jego dystrybucji źródła nie precyzują, więc tych informacji nie da się potwierdzić na podstawie dostępnych materiałów.

Dla kogo TIN może być realną alternatywą?

TIN kierowany jest do zespołów, które utrzymują aplikacje na Postgresie i potrzebują pełnotekstowego wyszukiwania bez dodatkowej infrastruktury. Jeśli dziś wyszukiwarka działa jako osobna usługa wyłącznie dla jednej funkcji aplikacji, eliminacja tej warstwy może uprościć architekturę. W ogłoszeniu na profilu PlanetScale podkreślono współpracę ze złożonymi klauzulami WHERE, replikacją, kopiami zapasowymi oraz poprawną widocznością transakcji.

Ponadto opis na GeekNews wskazuje na BM25 i zoptymalizowane MVCC jako filary rozwiązania, co czyni je atrakcyjnym tam, gdzie liczy się ranking wyników według istotności. Wobec tego kandydatami są na przykład:

• Aplikacje e-commerce z wyszukiwarką produktów opartą na rankingu BM25.
• Systemy treści, gdzie wyniki muszą sortować się według istotności, a nie chronologicznie.
• Zespoły zmagające się z niespójnością danych między bazą a zewnętrznym silnikiem wyszukiwania.
• Organizacje chcące zredukować liczbę usług do utrzymania i monitorowania.
• Projekty, w których natywny GIN okazał się zbyt wolny w praktyce.

Jednakże firmy z bardzo zaawansowanymi potrzebami wyszukiwania mogą nadal preferować dedykowane silniki, a źródła nie rozstrzygają tych przypadków wprost.

Często zadawane pytania

Kiedy TIN stał się ogólnie dostępny?

PlanetScale wydała TIN (Text INdex) 16 września i rozszerzenie od razu trafiło do ogólnej dostępności, bez etapu beta. Oznacza to, że można je wdrażać produkcyjnie od pierwszego dnia.

Czy TIN obsługuje złożone zapytania?

Tak. Według ogłoszenia PlanetScale TIN współpracuje ze skomplikowanymi klauzulami WHERE, a dodatkowo zachowuje poprawną widoczność transakcyjną. Rozszerzenie działa też z replikacją i kopiami zapasowymi.

Czym TIN różni się od natywnego indeksu GIN?

W benchmarkach opublikowanych przez PlanetScale natywny Postgres z GIN osiągał około 1 zapytania na sekundę w wybranym scenariuszu, podczas gdy TIN utrzymywał poziom około 227 qps. To dane dostawcy, więc traktować je należy z ostrożnością. TIN dodaje ponadto ranking BM25, którego natywne GIN nie realizuje w ten sposób.

Czy istnieje open source’owy sposób na porównanie TIN?

Źródła wskazują, że PlanetScale udostępniła celowo spowolnione rozszerzenie testowe open source, które pozwala na własne porównanie wydajności. Dzięki temu wyniki można zweryfikować poza benchmarkami producenta, na własnym zbiorze danych.

Podsumowanie

Wnioski z tej premiery można ująć w kilku punktach:

• TIN przenosi pełnotekstowe wyszukiwanie z rankingiem BM25 do wnętrza Postgresa, eliminując potrzebę osobnej usługi czy sidecara.
• Rozszerzenie od 16 września jest ogólnie dostępne, bez etapu beta.
• Benchmarki producenta pokazują około 227 qps wobec 26 qps dla ParadeDB i 1 qps dla natywnego GIN, choć pomiary wymagają samodzielnej weryfikacji.
• Poprawna widoczność transakcji oraz współpraca z replikacją i kopiami zapasowymi czynią TIN poważnym kandydatem do wdrożeń produkcyjnych.

Jeśli utrzymujesz aplikację na Postgresie i rozważasz uproszczenie architektury wyszukiwania, sprawdź udostępnione rozszerzenie testowe i powtórz benchmark na własnych danych. Tylko taki pomiar powie, czy TIN rozwiąże realny problem Twojego zespołu. Tematyka wyszukiwania i przetwarzania danych wraca też w innych kontekstach – zobacz jak Google aktualizuje wyszukiwanie AI, dodając cytaty z Reddita i innych źródeł.