Внедрил в PersMarket гибридный поиск. Занятная штука. Ведь как раньше было? Скажем, вы ищете вакансию (ну или товар в WB) через текстовую строку "тестировщик". На сервере БД выполняет SQL-запрос с условием

WHERE description LIKE '%тестировщик%'

Это легко программируется, просто ищется, нативно подхватывается многостраничность. Но есть в таком подходе минус: вы искали слово "тестировщик" - вы только его и найдете. Это может быть приемлемо, например, для тегов, имен собственных и аббревиатур - "Docker", "DDD", "CRM". Но для обычного текста даст очень грубые результаты. Я использую PostgreSQL, в нем есть особый тип поля - tsvector, для более продвинутого подхода. В него можно собрать векторное представление текстовых данных для полнотекстового поиска. Это дает сразу кучу ништяков: ▪️разные формы слова ("бежал", "бежит") станут одной лексемой ▪️меньше лишних слов типа предлогов, которые для поиска не важны ▪️специальный индекс, который заметно ускоряет поиск Выглядит это так:

'python':134A 'rabbitmq':118A 'redi':112A 'review':81A 'saa':15A 'schedul':106A 'servic':145A 'throughput':71A 'авторизац':62A 'архитектур':27A,50A,83A 'асинхрон':54A 'аутентификац':60A 'ваканс':5A 'взаимодейств':55A 'влиян':25A 'внутрен':44A 'высоконагружен':39A,99A

Но и этого уже мало. С появлением нейросетей появилась еще одно интересное развитие темы - поиск по смыслу. Снаружи выглядит как магия ✨ Каждый текст с помощью ИИ превращается в векторное представление, так называемый embedding. Это многомерный вектор, отражающий смысл текста. В PostgreSQL для этого тоже есть свой тип данных - vector. В нем много цифр:

[3.0517578e-05,0.041046143,-0.036010742,-0.022735596,0.018463135,-0.0036640167,0.014862061,0.0010919571,0.00969696,-0.006175995,0.012413025,-0.05609131,0.023406982,-0.006580353,0.041656494,0.032470703,-0.0869751,0.0071144104,0.011909485,0.034179688,0.02305603,0.027496338]

Алгоритм такой: ▪️текст вакансии (название + описание) через ИИ превращаем в эмбеддинг ▪️поисковый запрос тоже через ИИ превращаем в эмбеддинг ▪️сам поиск измеряет косинусное расстояние между этими эмбеддингами и сортирует по "векторной близости" Генерацию эмбеддингов можно делать через API, например, в том же OpenAI через модель text-embedding-3-small, либо даже через локальную опенсорсную модель типа intfloat/multilingual-e5-small, которая, по слухам, даже без GPU работает. Что еще можно делать с эмбеддингами? Можно их использовать в RAG-системах. Типичный пример - заставить ИИ-чат-бота давать ответы по базе знаний вашего продукта. Все статьи базы знаний превращаем в эмбеддинги и добавляем из при запросах к ИИ. Модель ищет ответ не где-то в интернете, а конкретно в ваших статьях. Полезно для автоматической поддержки. Но у поиска по смыслу тоже есть минус - они может пропустить точные совпадения слов, например, аббревиатур. Поэтому на PersMarket сейчас работает гибридный поиск по алгоритму Reciprocal Rank Fusion (RRF). Такой поиск совмещает две выборки - семантическую и смысловую, а результаты ранжирует по их позициям в выборках. В общем, поиск заиграл новыми красками. Заодно теперь в каждой вакансии есть "похожие вакансии". И по таким же принципам можно будет строить рекомендательную систему для индивидуального подбора. Но это тема отдельной диссертации. #database #ai #persmarket

“Тантор Лабс”, входящая в “Группу Астра”, закрыла сделку с ООО “МТ-Интеграция” [входит в холдинг “Инвестмир”, бывший владелец “МаксимаТелеком”]. Компания выкупила исключительные права на результаты интеллектуальной деятельности, связанные с отечественной СУБД “Персей”. Сумма покупки не раскрывается. Команда разработки продукта, в которую входит порядка 50 специалистов, присоединится к “Тантор Лабс” и продолжит развитие решения уже в составе компании. СУБД “Персей”, основанная на PostgreSQL [СУБД с открытым исходным кодом], предназначена для построения корпоративных информационных систем с повышенными требованиями к безопасности и надежности. Продукт включает механизмы защиты на уровне ядра, сертифицирован ФСТЭК России по четвертому уровню доверия и обладает развитыми средствами обеспечения высокой доступности, включая кластер “Атлант”. Решения на базе “Персея” используют организации промышленного, государственного и финансового сектора. @rusven

Кто-то только что переписал 40 лет PostgreSQL с нуля на Rust. И он уже проходит 100% официальных тестов Postgres. Проект называется pgrust. Это не форк, а полная реализация с нуля, которая уже проходит все 46 066 запросов из официального тестового набора PostgreSQL 18.3. Postgres разрабатывается уже 40 лет, и некоторые архитектурные решения из 80-х до сих пор приводят к сбоям: - один поток на соединение, фактически отдельный OS-процесс на пользователя - 350+ параметров настройки, которыми нужно управлять вручную - один только VACUUM стал причиной тысяч инцидентов pgrust выбрасывает всё это и начинает заново. Что уже работает: - проходит 96% regression suite PostgreSQL - psql подключается из коробки, есть совместимость с wire protocol - query planner, buffer cache, storage engine, B-tree индексы - JSON/JSONB, window functions, foreign keys, EXPLAIN ANALYZE, regex - тот же движок компилируется в WebAssembly и запускается прямо в браузере на pgrust.com 100% open source. https://github.com/malisper/pgrust

PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря В PostgreSQL уже хранятся пользователи, заказы и платежи, а потом стек начинает расти сам собой, когда рядом появляются Redis для очереди задач, отдельный Python-скрипт для дедупликации событий, Go-цикл, который считает интервалы между статусами заказа, свой поисковик вместо простого поиска по тексту и самодельная таблица locks для координации воркеров. Большая часть этой инфраструктуры дублирует то, что PostgreSQL умеет делать сам, причём атомарно, транзакционно и с индексами, без лишней сетевой болтовни между приложением и базой. Механизм, который снимает необходимость в отдельном брокере задач, живёт в PostgreSQL ещё с версии 9.5, просто про него редко вспоминают. Та же история с оконными функциями, полнотекстовым поиском и блокировками на уровне базы, где задачи, ради которых обычно поднимают отдельный сервис, часто закрываются прямо в таблице. Обсудим, сколько из этой цепочки сервисов держится просто на привычке.