PlanetScale представила TIN — полнотекстовый поиск для PostgreSQL

Компания PlanetScale объявила о выходе TIN — расширения полнотекстового поиска для PostgreSQL. Название расшифровывается как «Text INdex», и, по словам авторов, именно этим оно и занимается. Расширение доступно сразу в статусе общей доступности для всех баз Postgres и Neki, а подключается привычным CREATE INDEX ... USING tin(...) с поиском через оператор ==>.

По утверждению разработчиков, хороший текстовый индекс должен поддерживать булевы выражения, фразовые и span-запросы, нечёткий поиск, шаблоны и регулярные выражения, свёртку регистра и диакритики, подсчёт COUNT(*) и ранжирование top-k по BM25 — и при этом корректно работать с джойнами, репликацией, резервным копированием и видимостью транзакций. Существующие расширения, говорят в PlanetScale, каждое по отдельности эти требования не закрывают.

Почему это быстро

Главная идея TIN — отказ от собственной последовательной нумерации документов. Обычные поисковые движки дробят индекс на сегменты и внутри каждого присваивают документам номера от 1 до n, из-за чего один и тот же номер в разных сегментах указывает на разные документы, а при слиянии сегментов приходится всё перенумеровывать и переписывать. ParadeDB и pg_textsearch вынуждены держать отдельную структуру для перевода своих идентификаторов обратно в ctid — физический адрес строки в куче Postgres.

TIN использует ctid напрямую. Это 48-битное значение вида «(номер страницы, смещение)», дающее мгновенный доступ к строке. Поскольку на 8-килобайтную страницу помещается не более 291 кортежа, TIN кодирует списки постингов двухуровневыми битовыми картами: одна на страницы, другая — на смещения внутри страницы. Такие карты идеально ложатся в векторные регистры AVX2/AVX-512, так что пересечение и объединение запросов сводятся к инструкциям AND/OR, а подсчёт совпадений — к POPCNT. При слиянии сегментов ничего перенумеровывать не нужно: битовые карты просто переходят к новому сегменту без перекодирования, что резко снижает write-amplification.

Цифры

Авторы честно оговаривают, что бенчмарки — их собственные. Тесты гоняли на инстансе AWS i7i.8xlarge с Postgres 18.6 в контейнере на 8 vCPU и 32 ГБ памяти против ParadeDB, pg_textsearch и встроенного GIN. Из конкурентов все сценарии смог пройти только ParadeDB; GIN спотыкался на дизъюнктивных запросах из-за нехватки памяти, а pg_textsearch умеет лишь дизъюнкцию.

В разных сценариях TIN показал пропускную способность как минимум в 8 раз выше, а на отдельных задачах отрыв достигал десятков и сотен раз при кратно меньших задержках p99. Особенно эффектен подсчёт совпадений по Википедии, целиком помещающейся в буферах: свыше 10 тысяч запросов в секунду против сотен у ParadeDB. Заодно TIN читает с диска существенно меньше данных на запрос, что бережёт кэш и оставляет ресурсы другим запросам на том же сервере.

Источник: Lobsters