JOIN - крайне популярная операция в SQL, о которой еще и спрашивают на 99% собеседований на программиста. Но когда начинаешь впервые разбираться с ней, то постоянно путаешься, какие таблицы соединять и когда именно.
В этой статье простыми словами и с великолепной графикой расскажу, что такое JOIN в SQL, что такое Foreign Key, какой тип JOIN когда использовать - INNER или OUTER - и зачем вообще.
Последнее время я всё чаще встречаю одну и ту же мысль: бизнес никогда не даст ИИ‑агенту доступ к базе клиентов, заявкам, платежам, CRM или внутренним документам. На первый взгляд звучит логично. Если агент ошибётся, перепутает контекст или выполнит не то действие, ущерб может быть вполне реальным. Но мне кажется, что здесь часто путают две разные вещи.
Давать агенту прямой доступ к базе действительно нельзя. А вот давать ему возможность работать через ограниченный, проверяемый и журналируемый контур действий вполне можно. Примерно так же мы не даём пользователю прямой доступ к PostgreSQL, но разрешаем ему нажимать кнопки в интерфейсе, которые вызывают заранее описанную бизнес‑логику.
В этой статье я хочу как раз таки разобрать, как может выглядеть такой контур на практике: без магии, без «агент всё сам решит», без сырого SQL от модели и без веры в то, что хороший prompt заменяет нормальную архитектуру.
У меня, как и у любого программиста (особенно бэкэндера), чешутся руки что-то сделать, но всегда не хватает интересных идея. Поэтому я придумал стартап по генерации идей для стартапов и решил навайбкодить его за выходные. Читайте далее, что из этого вышло))
Автономная диагностика СУБД требует от LLM-агента не просто генерации текста, а точной последовательности действий: сбора телеметрии, анализа планов запросов и блокировок. Мы провели эксперимент по оптимизации окружения ИИ-агента (Virtual DBA) для Postgres. Использовав механизм записи и ускоренного воспроизведения реальной нагрузки (record/replay), мы запустили эволюционный поиск по пространству параметров среды — от изменения промптов до перекомпоновки шагов анализа и MCP-инструментов. Результаты показывают, как автоматический выбор конфигурации влияет на качество диагностических выводов и почему избыток доступных инструментов может ухудшить итоговый вердикт.
Наверное не существует в мире технической поддержки, которая бы среди прочего не занималась спасением данных клиентов. Не минула участь сия и нас в Postgres Professional. Однако особенность спасения битых данных в СУБД заключается в том, что сломаться может сразу на двух уровнях: физическом и логическом. Первое, это когда что-то случилось с физическим файлом внутри которого лежат данные, а второе это когда файл цел, но внутри него каша без смысла. Поэтому сегодня мы поговорим о том как понять что в вашей базе что-то пошло не так, как понять почему, как оценить ущерб и минимизировать его. А в конце, бонусом, обсудим как не стать героем подобных статей.
PostgreSQL: PostgreSQL 19 Beta 1
Официальный релиз запланировали на сентябрь/октябрь. Вот что старейшины решили выделить в описании релиза 19-й версии:
Производительность
PostgreSQL 19 усовершенствует асинхронную подсистему ввода-вывода, представленную в PostgreSQL 18: io_method=worker теперь автоматически масштабирует количество рабочих процессов ввода-вывода на основе новых параметров io_min_workers и io_max_workers.
Расширение pg_plan_advice позволяет пользователям стабилизировать и контролировать решения планировщика, а pg_stash_advice - автоматически применять рекомендации, используя идентификаторы запросов.
Autovacuum теперь может использовать параллельные рабочие процессы, которые можно настраивать с помощью нового параметра autovacuum_max_parallel_workers, а новая система оценки autovacuum помогает расставлять приоритеты таблиц при их вакуумировании. Кроме того теперь PostgreSQL помечает страницы как видимые, когда их запрашивают.
Enterprise-разработка рано или поздно сталкивается с классической задачей: нужно выдать доступ к БД аналитикам, тестировщикам или саппорту в проде, но при этом необходимо скрыть персональные данные или коммерческую тайну. Статическое маскирование отлично подходит для случаев, когда таблица копируется полностью, но что если “замаскировать” нужно просто результат какого-либо запроса? Здесь пригодится маскирование динамическое, и в этой статье мы рассказываем об инструменте transp_anon, который входит в новый релиз СУБД Tantor Postgres 18.
Есть устойчивое поверье: интеграционные тесты медленные, потому что ходят в настоящую базу. «Подними SQLite в памяти», «замокай репозитории», «не гоняй Postgres в CI» — стандартный набор советов. Мокать я не люблю, но крыть упрёк «настоящая база — это медленно» было нечем. Поэтому я сел, спрофилировал и померил: 3316 интеграционных тестов, прогон 30 минут. После трёх правок инфраструктуры — 109 секунд. База оказалась ни при чём, а совет «чисти базу через TRUNCATE, это быстрее DELETE» у меня работал ровно наоборот — обидно вдвойне, потому что эта рекомендация уже лежала в черновике моей следующей статьи.
IWANT - наш собственный fashion-магазин. Несколько лет он жил на InSales: на старте это правильный выбор: быстро, без разработки, всё из коробки. Но в какой-то момент мы уперлись в потолок платформы: каждый нужный модуль - это либо платное приложение, либо «так нельзя». Мы посчитали и решили перевезти магазин на собственный движок.
Это не история «платформы плохие, пишите своё». Это разбор конкретного переезда: что переносили, как устроен ETL из выгрузок InSales, на каком стеке собрали и почему именно на нём, какие модули пришлось писать самим, как прошёл катаут без простоя и кому такой переезд реально нужен, а кому нет.
Когда говорят «генератор миграций», обычно в голове сразу появляется что-то вроде:
Генератор миграций начинается не с CREATE TABLE, а с вопроса: как представить текущую схему базы в коде?
В первой статье серии разбираем PostgreSQL-first introspector: читаем таблицы, колонки, constraints и индексы, где хватает information_schema, а где приходится идти в pg_catalog, и собираем детерминированный snapshot схемы. Миграции пока не генерируем — строим фундамент, из которого потом можно будет сделать diff и получить DDL.
Статья будет полезна тем, кто пишет инструменты вокруг баз данных, интересуется PostgreSQL internals или хочет понять, почему автомигратор — это не просто набор ALTER TABLE.
В свободное время я периодически захожу на Upwork, чтобы посмотреть, какие проекты там сейчас появляются и как устроен рынок изнутри.
Если убрать фильтры и посмотреть общий поток вакансий, довольно быстро становится видно типичную картину: большое количество разработчиков конкурируют за очень стандартные и недорогие задачи. В таких условиях основная проблема смещается не на поиск интересных проектов, а на скорость их обработки и подачи предложений. Это особенно заметно в сегменте разработчиков, которые работают на массовом рынке: важно быстро отсекать нерелевантные предложения и экономить connects.
Именно это стало отправной точкой для идеи Chrome-расширения, которое добавляет слой аналитики поверх списка проектов Upwork и позволяет быстрее принимать решение, стоит ли откликаться на вакансию.
В предыдущей части цикла разобрали 13 таблиц REDB: как устроены objects, values, structures, как RTTI-хранение значений отличается от старого EAV-паттерна, зачем нужен scheme_metadata_cache. Если не читали — начните с неё, без понимания схемы дальше тяжело.
В этой статье — то, что обычно идёт следующим вопросом: «А индексы где? У вас же значения всех полей лежат в одной таблице. Любой WHERE — это Seq Scan по миллионам строк».
Это статья 1.1, а не 2 — потому что она прямое продолжение разговора про физическое хранение. Глубокое погружение в C# — это статьи 3-5 цикла: Code-first схемы (SyncSchemeAsync<T>), CRUD (SaveAsync/LoadAsync), LINQ-транслятор. Здесь разговор остаётся в плоскости БД и DDL.
Цифры, на которые опираемся, — с реального прода: TSUM, логистическая система, обслуживает движение грузовиков и заказов через РЦ.
На связи Денис из команды платформы данных в Yandex Cloud. Мы занимаемся разработкой системы SPQR, которая помогает легко реализовать горизонтальное масштабирование PostgreSQL с помощью шардирования. И это не теоретическая задача на два шарда и десять таблиц. Необходимо сделать систему, которая в пределе хранит петабайты данных и выдерживает сотни тысяч запросов в секунду.
В прошлой статье мы показывали SPQR со стороны пользователя: как выбрать ключ шардирования, как разложить таблицы на распределённые (distributed) и справочные (reference), как создать распределения и определить диапазоны ключей, а затем перевезти монолит на несколько шардов. Эта статья будет про инженерный путь: архитектуру, компромиссы и грабли, которые встретились по дороге.
Планы выполнения запроса формируются на основе текста самого запроса, статистик и параметров конфигурации. Для сбора статистики нужны данные в таблицах. В PostgreSQL 18 версии появились функции pg_restore_relation_stats и pg_restore_attribute_stats, которые могут записать статистики в системный каталог. Вместе с возможностью выгрузки статистики параметром утилиты pg_dump --statistics-only, статистику стало возможым переносить между базами данных.
Функционал переноса статистики был создан для обновления кластера баз данных на новые версии. До 18 версии статистика не выгружалась, собиралась после обновления. Сбор статистики по большому числу таблиц довольно долгий. Начиная с 18 версии, утилита pg_upgrade, по умолчанию, сохраняет статистику.
Этот же функционал можно использовать для переноса статистики с промышленных на тестовые базы данных. В статье рассматривается как это сделать.
Шесть лет назад, в начале 2020 года, группа разработчиков оглянулась на Firebase и подумала: «А давайте сделаем то же самое, но открытым кодом и на SQL!» Так родился Supabase: проект с искренней целью дать разработчикам контроль над данными и избавить от проприетарных заморочек.
А с распространением Vibe Coding, когда нейросети удобнее работать с API, а не писать логику для СУБД, взлёт Supabase пошел по экспоненте.
varchar(255) выглядит как аккуратное ограничение и часто воспринимается как способ сэкономить место.
Но в PostgreSQL это не так: база хранит фактическую строку, а не заранее выделяет память под весь лимит.
Разбираемся, что на самом деле делает VARCHAR(N), чем он отличается от text, когда ограничение полезно, а когда просто превращается в число, которое притворяется архитектурой.
Каждый бэкенд-разработчик, который хоть раз готовился к собеседованию, слышал про аббревиатуру ACID. Какая-то часть из слышавших сможет её расшифровать. Какая-то часть из расшифровавших — объяснить, почему важен каждый из принципов, скрытых за этими четырьмя буквами. И уж точно каждый из этих замечательных разработчиков знает цену букве «I» — isolation, изоляции транзакций.
Те, кого заинтересовал заголовок, скорее всего, относятся к одной из трех категорий читателей:
Первые знакомы с этими понятиями в теории, но не имели шанса решать их на практике. Вам — обещание: когда вы столкнётесь с этими загадочными на первый взгляд явлениями в бою, вы уже будете к ним готовы. А если прочитаете статью до конца и вникнете во все примеры — сможете блеснуть на собеседовании знанием тонкостей борьбы с гонками в реальных highload-приложениях, даже не имея такой практики.
Вторые решали такие проблемы «на ощупь», не до конца понимая механику. Вам — собрать разрозненный опыт в систему: увидеть полную карту способов и понять, какой из них и почему обходится дороже.
Третьи сталкивались с этими проблемами и знают, как их решать. Вам — наглядная демонстрация цены тех решений, которые вам уже приходилось имплементировать: конкретные цифры, во сколько на самом деле обходится каждый подход.
В этом материале систематизируем способы бороться с race conditions в Postgres и считаем, во сколько обходится каждый.
В 18 версию СУБД Tantor Postgres включено расширение pg_ilm, реализующее функционал управления жизненным циклом данных (Information Lifeсycle Management. Расширение, с нашей точки зрения, интересно тем, что оно не просто отслеживает «температуру» данных (горячие → остывающие → холодные), но и частично автоматизирует их перенос в колоночное хранилище или на более дешёвый носитель согласно заданным правилам, а не «как повезёт». Такой подход упрощает контроль за жизненным циклом данных, снижает конкуренцию за быстрое хранилище и позволяет экономить до 80% затрат на носители.
Чат-боты в ресторанном бизнесе чаще всего начинают с простой задачи: снять часть нагрузки с менеджеров и отвечать гостям на типовые вопросы. На практике многие такие решения быстро упираются в ограничения. Бот отвечает шаблонно, не понимает свободный текст, не учитывает контекст гостя, не видит актуальные данные ресторана и при нестандартном запросе просит переформулировать вопрос или вручную переключает диалог на сотрудника.
В проекте для ресторанной сети задача была другой: сделать не справочного бота, а AI-метрдотеля, который работает как цифровой сотрудник. Он должен понимать свободный текст, учитывать историю гостя, работать с бронированиями, обращаться к меню и базе знаний, проверять актуальные данные в ресторанных системах, принимать платежи, собирать отзывы и передавать диалог менеджеру в сценариях, где требуется участие человека.
Такой продукт требует не только языковой модели. В основе должны быть база знаний, профиль гостя, интеграции с операционными системами ресторана, RAG, сценарная маршрутизация, контроль доступа, логирование и техническая архитектура, рассчитанная на работу с реальными бронями, оплатами и персональными данными.
Если вы работаете с базами данных и используете ORM, вы, вероятно, сталкивались с той же проблемой, что и я. ORM отлично подходят для отображения таблиц на объекты. Но они начинают мешать, когда запрос становится сложным: агрегации, тщательно продуманные JOIN’ы, формы отчетов, которые не соответствуют одной модели на таблицу. Вы боретесь с ORM, переходите на сырой SQL, а затем вручную пишете связующий код (маппинг).
Не каждый SELECT возвращает то, что подходит под одну ORM-модель. SQL - это лучший язык для доступа к данным. Лучшие ORM, которые я использовал, такие как Drizzle, побеждают, потому что они остаются близки к SQL. Я хотел пойти дальше: хранить SQL в системе контроля версий и генерировать из него типизированный Python.
Именно поэтому я создал nORM (no ORM - не ORM) и выпустил версию v0.1.0 на этой неделе (мой первый опенсорс проект).
