SQL *

В этой статье хочу рассказать о нашей передовой системе Text-to-SQL, построенной на базе динамической мультиагентной архитектуры. Вместо одной модели — команда из шести специализированных агентов. Каждый отвечает за свой участок работы: один проверяет безопасность на входе, второй понимает намерение пользователя, третий ищет нужные таблицы, четвертый пишет код, пятый проверяет его на уязвимости, шестой безопасно выполняет и логирует результат. 

Это универсальная платформа, где данные под полным контролем, а точность запросов на порядок выше. Text-to-SQL — лишь первое применение. Архитектура позволяет решать любые AI-задачи, где критична надежность. 

На просторах интернета легко можно найти материалы по реализации нечёткого поиска, в которых предполагается поиск одной строки в множестве строк M. Но что если возникнет необходимость реализовать нечёткое сравнение множества M₁ с множеством M₂? При классическом подходе нам придется выполнить сравнений - при линейном росте этих множеств, сложность задачи будет расти экспоненциально, в плане производительности это решение никуда не годиться!
В этой статье предложен вариант реализации ускоренного алгоритма для решения этой задачи. Теоретической новизны в проекте практически нет. Цели:
1 - Ознакомить с концепцией
2 - Дать конкретный пример интеграции в БД SQL(MSSQL)
3 - Ознакомить с возможностями на базе практической реализации

На данный момент я прохожу 5-дневный интенсив по AI‑агентам от Google. Эта статья представляет собой перевод оригинального материала, выполненный с помощью Gemini и мной. В этой статье вы узнаете как сделать так, чтобы ИИ не просто «отвечал», а «понимал» и «запоминал»? И если вы когда‑либо задумывались о том, как научить LLM‑агентов вести осмысленные, долгосрочные беседы, эта статья станет вашим проводником в мир сессий и памяти, которые формируют ИИ агентов.

JOIN vs коррелированный подзапрос: мой разбор мифа «JOIN всегда быстрее»

Я проверил оба подхода (JOIN + GROUP BY и коррелированный подзапрос) на маленьком датасете и в ряде СУБД. Иногда подзапрос быстрее. Всё зависит от плана (Nested Loop vs Hash) и индексов. Слепо верить «JOIN всегда быстрее» не стоит. Смотрите EXPLAIN.

Ваш сервис отправил сообщение в RabbitMQ, но в момент коммита транзакция в базе данных откатилась. Классический кошмар распределенных систем, порождающий данные-призраки и часы отладки. Обычно эту проблему решают сложным кодом, двухфазными коммитами или просто надеждой на лучшее. А что, если бы откат транзакции в PostgreSQL мог автоматически «откатить» и отправку сообщения, вернув его в очередь без единой строчки вашего кода? Рассказываем, как это работает.

Недавно я изучал детали реализации взаимодействия клиента PostgreSQL с базой данных и был удивлён, насколько легко просматривать трафик PostgreSQL с помощью wireshark. Когда я поделился своим удивлением в социальной сети, меня попросили привести пример того, как это сделать.

Substrait — это промежуточный формат (IR) для обмена планами запросов между системами. Он снимает боль диалектов SQL, позволяет делать pushdown в разные бэкенды и избавляет от повторного парсинга/оптимизации федеративных системах и позволяет относительно безболезненно заменять один бэкенд другим. Ниже - зачем он нужен, как устроен и кто поддерживает.

Первая часть статьи

В первой части мы обсудили философские основы и принципы работы рейтинговой системы, где у каждого человека разная сила голоса, отражающая его полезность для конкретного сайта (офелократия). Теперь перейдём к техническим деталям реализации на MySQL.

Некоторые из IT-компаний говорят, что поддерживают open source. На деле это нередко означает использование чужого кода и PR-активность. Мы считаем, что настоящий вклад — это коммиты в ядро. И чтобы делать это системно, мы открыли инженерный центр не в столичном бизнес-парке, а в месте, где фундаментальная наука — часть культурного кода. Рассказываем, почему будущее системного программирования мы строим в новосибирском Академгородке.

Последние несколько лет я параллельно писал код, преподавал и экспериментировал с форматами обучения. В какой-то момент понял, что преподавание — это тоже проект, просто с другим типом пользователей. И за 2 года обучил более 1000 студентов. В этой статье подробно расскажу, зачем вообще разработчику делать курсы и как системно подойти к их созданию. Бонусом в конце поделюсь советами и инсайтами.

Во время выполнения очередного проекта мне пришлось работать с Битрикс ORM, при этом параллельно в системе был инстанс Laravel. Две разные ORM работали с единой базой данных. Не буду вдаваться в причины, по которым был выбран такой подход, и воздержусь от его оценки. Суть в том, что мне приходилось одновременно работать с двумя принципиально разными системами. Этот опыт привел меня к фундаментальному выводу: ORM — не для меня.

Когда мы пишем запрос, СУБД делает гораздо больше, чем просто ищет данные. Она оценивает десятки сценариев выполнения, сравнивает стоимость операций и выбирает оптимальный путь к результату. От этого выбора зависит, будет ли запрос выполняться секунду или минуту. Почему одни системы находят лучший план, а другие выстраивают менее эффективный алгоритм? Попробуем разобраться, как планировщики СУБД принимают решения и что определяет их эффективность.

Apache Iceberg — табличный формат для озёр данных с поддержкой ACID, Schema Evolution, Hidden Partition и версионирования, но при больших метаданных и работе через S3 страдает планирование запросов и латентность. В связке со StarRocks мы показываем, как распределённый Job Plan, Manifest Cache, CBO с гистограммами, Data Cache и материализованные представления выводят lakehouse‑аналитику на уровень DWH: снижают накладные расходы на метаданные, ускоряют планы и выполнение, а запись обратно в Iceberg сохраняет единый источник истины. Разбираем архитектуру Iceberg, типовые узкие места и практики оптимизации на StarRocks 3.2–3.3, включая кейс WeChat/Tencent.

Алгоритм двухфазной блокировки (Two-Phase Locking, 2PL) — один из старейших механизмов управления параллелизмом, используемых реляционными СУБД для обеспечения целостности данных. В этой статье я расскажу, как работает алгоритм 2PL и как его можно реализовать на любом языке программирования.

В предыдущей статье обсуждали регламентное обслуживание с акцентом на пересчет статистик. Операция крайне полезная, необходимая и чем интенсивнее меняются данные в базе, тем важнее актуальные статистики. Сегодня поговорим про еще одну регламентную операцию – пересчет индексов. Как всегда с акцентом на высоконагруженные системы 1С.

"Нужно?", "Не нужно?", "А если у меня SSD-диск?", "А какой эффект от перестроения индексов?", "А я не успеваю за ночь. Что делать?"

Разберем подробно все нюансы.

Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.

Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике.

Мы разберём:

Началось все весьма прозаично, клиент позвонить к нам в техподдержку и спросил «а как бы мне поставить ваш софт но в другую схему БД». Собственно вопрос проще некуда — мы писали на спринге, а значит лезем в application.yml и ставим схему. Но, клиент не из тупых и уже это попробовал — не сработало.

Начинаем разбираться что сломалось и кто виноват. Первым делом ДевОпс повторяет кульбиты клиента и выдает простой вердикт: «В 151 миграции лажа». Я открываю и: «батюшки родный, да это же лосенок явное указание схемы!»

Всем привет! В этой коротенькой статье я попытаюсь вам доказать, что внешние ключи (foreign keys) в СУБД — не нужны и только вредны.

Можно ли смоделировать хаос пуассоновских потоков бронирований и конечный автомат состояний рейса (от «по расписанию» до «приземлился») целиком внутри PostgreSQL? Мы решили, что для создания идеальной учебной базы данных — можно. Вместо старых статичных таблиц мы построили генератор, имитирующий жизнь глобальной авиакомпании. Рассказываем, зачем это было нужно и почему старая база на 2,5 ГБ перестала справляться с задачами.

Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR, а второй — хитрую комбинацию AND. Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.