SQL *

В Ptah 0.13.0 появилась нативная поддержка YDB. Ptah умеет читать текущую схему базы, сравнивать её с декларативным описанием и на основе разницы строить план изменений или генерировать версионные миграции. В статье разберём этот процесс на примере HCL-схемы, посмотрим на работу с индексами и drift detection, а также на особенности YDB, которые приходится учитывать при миграциях: разные возможности версий, feature flags и нетранзакционный DDL.

Завершаем обзор мартовского коммитфеста 19-й версии. В четвертой и последней статье серии рассмотрим изменения, относящиеся к языку SQL и материалам курсов DEV1 и DEV2.

Напоминаю план статей о последнем коммитфесте 19-й версии:

Часть 5.1 (QPT)

Часть 5.2 (DBA1, DBA2)

Часть 5.3 (DBA3, DBS)

Часть 5.4 (SQL, DEV1, DEV2) – мы здесь 🙂

Об изменениях в предыдущих коммитфестах рассказано здесь: 2025-07, 2025-09, 2025-11, 2026-01.

Продолжаем обзор мартовского коммитфеста 19-й версии. В третьей статье серии рассмотрим изменения, относящиеся к материалам курсов DBA3 и DBS.

Напоминаю план статей о последнем коммитфесте 19-й версии:

Часть 5.1 (QPT)

Часть 5.2 (DBA1, DBA2)

Часть 5.3 (DBA3, DBS) – мы здесь 🙂

Часть 5.4 (SQL, DEV1, DEV2)

Об изменениях в предыдущих коммитфестах рассказано здесь: 2025-07, 2025-09, 2025-11, 2026-01.

Я собрал MVP системы поддержки принятия решений для эпидемиологического мониторинга. Цель была технической: проверить полный путь от временного ряда по территории до расчёта риска и выдачи результата в диалоговом интерфейсе.

Важное ограничение: эпидемиологическая динамика в этом MVP синтетическая. Реальными были названия муниципалитетов, площадь, численность населения, плотность и температура из Яндекс Погоды. Показатели вакцинации, число случаев, заболеваемость и целевая метка генерировались программно.

Поэтому приведённые метрики не говорят ничего о способности модели прогнозировать реальные вспышки ОРВИ. На таких данных нельзя делать вывод, что одна архитектура лучше другой: модель в первую очередь учится закономерностям, заложенным в генератор синтетического ряда.

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

Добавил фильтр по городу в подзапрос — туда, куда учебники и велят его ставить. На тестовой базе в 750 строк незаметно, на проде запрос стал висеть: 0,71 с превратились в 53,7 с. Починил, замеры оставил в комментарии. Спустя две недели сел писать про это статью, перемерил — и тот же запрос на той же базе отработал за полсекунды. Разбираю, почему катастрофа рассосалась сама, почему дело было не в join и почему измеренная цифра в комментарии протухает быстрее, чем кажется.

Продолжаем обзор мартовского коммитфеста 19-й версии. Во второй статье серии рассмотрим изменения, относящиеся к материалам курсов DBA1 и DBA2.

Напоминаю план статей о последнем коммитфесте 19-й версии:

Часть 5.1 (QPT)

Часть 5.2 (DBA1, DBA2) – мы здесь 🙂

Часть 5.3 (DBA3, DBS)

Часть 5.4 (SQL, DEV1, DEV2)

Об изменениях в предыдущих коммитфестах рассказано здесь: 2025-07, 2025-09, 2025-11, 2026-01.

Я много знакомлю лидов друг с другом. Теперь этот процесс автоматизирован. Этот способ позволяет мне расширять свой нетворк и давать пользу тем, с кем я знаком

Три узла, одна база, клиент шлёт UPSERT. Нужно решить две вещи сразу: разрешить запись только на согласованном кластере и не допустить, чтобы после обрыва связи между узлами в журналах оказались разные версии одних и тех же данных.

В стеке вроде Raft логика такая: узлы голосуют за лидера, пишет только он; у каждого периода лидерства есть порядковый номер (term), чтобы отличать старые голоса от новых; лидер пропал — новые выборы. В Grid допуск записи устроен иначе. Лидер не выбирается голосованием. Вместо этого узлы обмениваются числовым параметром синхронизации (фазой, в смысле модели Курамото) и отдельно подтверждают каждую операцию контрольной суммой её содержимого. Этот протокол называется ORCHID.

Завершаем цикл статей с обзором изменений 19-й версии. Предыдущие статьи были посвящены первым четырем коммитфестам: 2025-07, 2025-09, 2025-11, 2026-01.

А сегодня начнем обзор мартовского коммитфеста 2026 года. Почему «начнем»? По опыту прошлых лет, мартовский обзор всегда очень объемный. Именно в последнем коммитфесте принимается большое число важных изменений. Обзор не только сложно подготовить, но и непросто дочитать до конца 🙂. Поэтому для 19-й версии он разбит на четыре статьи.

В первую статью вошли изменения, так или иначе связанные с оптимизацией запросов, — все, что можно отнести к нашему учебному курсу QPT. Вторая будет посвящена изменениям, которые больше относятся к курсам DBA1 и DBA2. Третья — к DBA3 и DBS. В четвертой будут рассмотрены новинки SQL, а также изменения, относящиеся к курсам DEV1 и DEV2.

В феврале 28 дней, в марте 31, продавайте одинаково каждый день — и рост на 11% появится сам, без новых клиентов.
В статье разбираю базу, как календарь и сезонность ломают отчёты: три вопроса перед сравнением периодов, SQL-запросы для среднего за день и скользящего среднего, ловушки сравнения год к году.

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

Разберём, как найти причину такого поведения в PostgreSQL, чем отличаются ROWS, RANGE и GROUPS, и какие настройки помогают получить предсказуемый результат в рабочих запросах.

Мы привыкли, что ограничения (CONSTRAINT) — это способ указания допустимых значений для столбцов, ограничение уникальности и создание связей между таблицами. Это отличный способ поддерживать целостность данных, предотвращая некорректные операции. Но помимо этого, ограничения также помогают оптимизатору запросов генерировать более эффективный план выполнения. Как именно? Читайте ниже.

Когда говорят про recon в Bug Bounty, обычно вспоминают subfinder, httpx, поиск директорий, JS-файлы и огромные списки URL. Всё это действительно используется. Но проблема в том, что сам по себе список из нескольких тысяч поддоменов почти ничего не даёт.

Главный вопрос начинается после сбора информации: что из этого действительно заслуживает внимания и почему?

Сценарий знакомый: открываешь в pandas файл побольше, ноутбук задумывается, и через минуту всё падает с MemoryError. Следом обычно звучит совет: для больших данных есть Spark. Я решил проверить его цифрами, но не на кластере, а на слабой машине с двумя ядрами и 5,8 ГБ памяти.

Сравнил шесть вариантов: pandas, pandas с pyarrow, Polars, Polars в потоковом режиме, DuckDB и PySpark. Пять типовых операций, объёмы от 6 до 180 млн строк, контроль памяти и автоматическая сверка результатов между библиотеками. Эта сверка по дороге нашла баг, из-за которого Spark терял целый день данных.

Кто сдался первым, кто удивил и почему переход на Spark часто не лучший выход, рассказываю под катом.

DISCLAIMER: Это неофициальный форк. Но, по моим сведениям, и в официальный pony эти фичи скоро подъедут в каком‑то виде.

Некоторое время назад, я решил испробовать программирование с помощью ИИ‑агентов и решил выбрать pony в качестве пет‑проекта. О pony я уже писал в предыдущей статье. Теперь хочу поделиться результатами своего недельного спринта.

В pony добавилось:
— поддержка асинхронности
— поддержка миграций
— разные улучшения из серии quality‑of‑life

Так что, фреймворк pony теперь чрезвычайно важен и сердит — что можно понять по этой картинке. Всё — благодаря DeepSeek 4.1 Flash и Kimi K3 (последняя — умная, но дорогая — она делала ревью).

На демо все выглядит безобидно: загружаем документы, строим эмбеддинги, подключаем векторный поиск — и RAG уже отвечает на вопросы. А потом поиск тормозит, после фильтрации пропадают результаты, а команда внезапно тратит все силы на систему, которая слишком велика для проекта.

Разберу, когда для векторного поиска достаточно PostgreSQL с pgvector, зачем выносить его в Qdrant и в каких случаях сложная архитектура Milvus действительно оправдана.

Чем сложнее бизнес-процессы, тем сильнее размывается логика связей: она оседает в каскадах SQL-джойнов, коде микросервисов и витринах, а LLM поверх плоских таблиц начинают галлюцинировать. Альтернатива — перенести доменные правила, сущности и роли на уровень схемы с помощью семантического слоя. Команда Neoflex протестировала этот подход на TypeDB — СУБД с нативными n-арными отношениями и встроенным логическим выводом. На сквозном датасете из 65 752 заказов и 470 000 веб-событий мы на практике сопоставили классический SQL и TypeQL: сравнили декларативные ролевые паттерны с каскадами JOIN и декартовым раздуванием строк, замерили реальную скорость выполнения и упаковали структурированный контекст для ИИ-агента без мусорных дубликатов. В статье на Хабре — методология декомпозиции схемы, замеры производительности и честный разбор того, в каких сценариях гиперграфы дают преимущество, а где привычные реляционные и графовые базы остаются незаменимыми.

Резерв товара сгорал за пять минут вместо тридцати: приложение и база писали в одну таблицу время из разных поясов. Как это найти, почему стейдж молчал и зачем проверять таймзону при старте.

Обычный день, любимый сервис и рандомная проверка: делюсь своим рабочим кейсом. Как из обычной проверки сервиса, который работал без замечаний, выросла целая задача на дедупликацию данных. Расскажу, в чём была разница между одинаковыми записями, как я искала «ту самую» среди десятков похожих и почему не стоило выбирать поваром Рафаэля только за то, что он последним заходил на кухню.

Всем привет! Я Аня Мавлютова, технический менеджер продуктов Data Governance в Платформе данных в Т-Банке. Работаю в компании больше девяти лет. Начинала свой путь с дата-инженера, последние три года занимаюсь продуктами, которые помогают нашим пользователям работать с данными многократно быстрее и удобнее. В моей зоне ответственности продукты каталога метаданных Data Detective, инструменты Data Quality и сервис управления разметкой чувствительных данных.

В эпоху AI ценность данных компании сильно возросла, на них направлено более пристальное внимание. Процессы operate и observability над данными получили большой фокус: если нет уверенности, что сегодня данные построились в качественном виде, то задачу точно нельзя отдавать агенту. Данных становится в разы больше, поэтому очень важно как можно раньше отлавливать проблемы и ошибки в данных, если они возникли, чтобы предотвратить их увеличение в зависимых процессах.

В статье расскажу, как мы прошли путь от 11 длительных ручных шагов до автоматизации через AI-агента. Почему отказались от low-code-подхода, как работает распознавание intent и почему выбрали агентскую архитектуру вместо цепочки промптов. Спойлер: решение оказалось смелее, чем мы планировали в начале.