Работаешь дата инженером не первый год, а PostgreSQL всё ещё может удивить 😅 Недавно столкнулся с ситуацией, которая, казалось бы, должна быть довольно распространённой. Нужно переименовать таблицу через ALTER TABLE ... RENAME, но ты не OWNER этой таблицы. Права на переименования раздать тоже нельзя Вроде штука достаточно распространненая должна быть, но раньше я как-то не сталкивался с такой задачей. В итоге решение оказалось довольно интересным — SECURITY DEFINER. Можно создать процедуру, которая будет выполняться с правами своего владельца, и дать пользователю доступ только к её вызову.

CREATE PROCEDURE ...
SECURITY DEFINER

В результате пользователь может выполнить нужное переименование, не получая права OWNER на сами таблицы. Я в такие моменты всегда задаюсь вопросом: "А точно ли я все эти годы чем-то занимаюсь, если мне еще не встречались такие вещи?)" А у вас были подобные моменты, когда внезапно узнаёшь что-то новое в технологии, с которой давно работаешь?

Как мне ИИ помогает в быту. Тесно сотрудничаю с ИИ-помощником в разработке. Он экономит мне кучу времени на рутину, находит неочевидные детали и предлагает оптимальные решения. Вот несколько кейсов только на этой неделе. 🔹Статистика Решил я добавить статистики в PersMarket. Ну, там, просмотры, география, прочее. Обычно для таких целей сразу тащу в проект ClickHouse. Но недавно писал про SereneDB, новую быструю СУБД с PostgreSQL-коннектором. Думаю, надо пробовать. Запустил режим планирования в моем ИИ-коллеге и попросил прикинуть, как реализовать статистику, упомянув обе СУБД выше. Тот пошуршал и выдал план, в основе которого обычный советский PostgreSQL. Про ClickHouse сказал, что рано. Про SereneDB почитал документацию на сайте и сказал, что пока тоже не стоит. Я пытался его убедить, что стильно-модно-молодежно, но тот был непреклонен, настаивал на своем варианте, без всякого вот этого "Вы абсолютно правы". В отчете привел обоснования и примерные оценки. По совокупности факторов я с ним согласился и пока не жалею. А вот если бы принимал решение сам, мог бы внедрить новое и потом увязнуть в настройке-поддержке. Да еще сервер мощнее брать бы пришлось. 🔹Лендинги Умеет мой нейродруг верстать, поэтому я делаю в нем лендинги. Сначала традиционный режим планирования, придумываем экраны, обсуждаем всякие завлекательные и убеждающие фразы, CTA-элементы и вот это все. Я пишу, что мне надо в итоге, он готовит этот поэкранный сценарий. Затем я согласую, и он верстает. По умолчанию получается немного нейрослопно, но есть скиллы, дополняющие его опыт всякими лучшми практиками. Они корректируют типографику и композицию, так что получается вполне прилично для работы на час. Но вот не умеет он генерировать картинки, к сожалению. Вернее, умеет вектор и SVG, умеет диаграммы и графики, а вот фотореализм не умеет. А для лендинга надо. И я прошу его: "У меня есть платное AI API, там есть модельки, умеющие генерировать изображения. Сделай мне скилл для генерации, чтобы недорого и приемлемо." Он сходил на сайт API, почитал документацию, скачал список моделей с расценками, сделал несколько тестовых запросов, выяснил оптимальный вариант и соорудил скилл. Собственно, скилл - это текст с инструкциями + скрипт на Python. И вторым запросом я ему говорю: "А теперь примени этот скилл для нового лендинга". 5 минут - и вуаля! - картинки на месте. Он сам составил запросы с учетом контекста, получил готовые картинки, оценил с точки зрения релевантности, вставил в лендинг и отформатировал. Придраться было не к чему. 🔹Баги На одном из проектов пользователи создают отчеты и прикрепляют к ним фото. И регулярно жаловались, что пропадают загруженные фото. Я не мог понять закономерность и воспроизвести это дело. Функционал делал не я, к тому же там использовалась сторонняя библиотека как ядро платформы. Попросил своего AI-гуру посмотреть, что может быть. Он посмотрел, говорит, что бывают фото большие, и в определенных случаях пользователи загружают их пачками, что не пролезает в лимиты. Давай, говорит, будем их уменьшать прямо на фронте. Ну конечно давай, говорю. Он сделал. Поверил за собой, тесты всякие, туда-сюда. Всё нормально. Кстати, говорит, а ты знаешь, что у тебя фото сохраняются неправлиьно на сервере? Не знаю, говорю. А вот, говорит, та сторонняя библиотека сначала пишет оригинал, а потом в этот же файл пишет уменьшенную копию, не отрезая хвост. Картинки потом отображаются нормально, потому что там все сигнатуры нормальные, но мусорный хвост увеличивает размер файла, иногда в разы. Ну разве я бы такое нашел глазами? Я бы и не искал, файлы без ошибок пишутся и открываются, а кто там на размер смотрит. Ой, мама, сказал я, сделай что-нибудь. Он исправил сохранение и по своей инициативе написал мне консольную утилиту для обрезания хвостов уже загруженных файлов, даже режим dry-run не забыл. Пробую - на каждые три месяца фоток до 500 мб хвостов. А история там за 4 года. В общем, не представляю, как раньше жил без такого покладистого помощника и, главное, быстрого, как электровеник. #ai

Внедрил в 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, просто про него редко вспоминают. Та же история с оконными функциями, полнотекстовым поиском и блокировками на уровне базы, где задачи, ради которых обычно поднимают отдельный сервис, часто закрываются прямо в таблице. Обсудим, сколько из этой цепочки сервисов держится просто на привычке.