«Сбер» выпустил GigaChat Ultra. 700 млрд параметров, суверенная архитектура и никаких импортных зависимостей

«Сбер» представил новую флагманскую модель ИИ — GigaChat Ultra.

Цифры, которые впечатляют:

- 700 млрд параметров
- Архитектура mixture of experts (когда внутри модели много маленьких «специалистов», а не один огромный)
- Двукратное ускорение генерации ответов по сравнению с предыдущей версией

Но главное не в цифрах. Главное — суверенность.

Модель полностью разработана и обучена внутри страны. Всё своё, никаких внешних зависимостей. Это уже не просто «отечественный аналог», а стратегический технологический фундамент на случай, если зарубежные модели вдруг станут недоступны.

На каких задачах модель показывает рост?

- Математика
- Право
- Финансы
- Медицина

И, что важно для нас, — отличные результаты в русскоязычном домене. Потому что английский модель учить не надо, она с нашим языком уже дружит.

Что умеет?

- Позиционируется как персональный ассистент:
- Использует поисковые и кодовые агенты (может сама искать информацию и писать код)
- Анализирует файлы
- Запоминает факты о пользователе (и даёт управлять этой памятью)

Что с внедрением?

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

Рынок генеративного ИИ меняется. Если раньше все смотрели только на OpenAI и Google, то теперь появляются сильные игроки с собственной инфраструктурой. И это круто — хотя бы потому, что конкуренция двигает прогресс.

Зачем аналитику SQL, если есть Excel? (Спойлер: чтобы выжить)

Давайте будем честными: Excel — это крутой инструмент. Он понятный, гибкий и в нем можно быстро набросать график для отчета. Но рано или поздно в карьере любого аналитика наступает момент, когда «экселька» начинает нещадно виснуть, а потом и вовсе вылетает с криком о нехватке памяти.

Почему же SQL — это не просто «еще один навык в резюме», а ваш главный инструмент выживания?

1. Объем данных: когда миллион — это предел
В Excel есть жесткий лимит — 1 048 576 строк на один лист. Для малого бизнеса этого может и хватит, но в серьезном проекте столько данных генерируется за пару часов. SQL смеется над этими цифрами: он легко «переваривает» миллиарды строк, пока вы спокойно пьете кофе.
(«Масштаб имеет значение, поверьте»).

2. Чистота и воспроизводимость
Вспомните этот ужас: вы получили чужую таблицу, где куча скрытых столбцов, странных формул и ячеек, покрашенных вручную. Понять логику расчета — настоящий квест. В SQL всё прозрачно: ваш код — это четкая инструкция. Его можно запустить снова, отдать коллеге на проверку или автоматизировать.

3. Мощность объединения (JOIN)
Связать пять таблиц в Excel через ВПР (VLOOKUP) — это верный способ повесить компьютер на полчаса. В SQL соединение таблиц по ключам — это базовая, мгновенная операция.
(«Связи должны работать на вас, а не против вашего процессора»).

4. Безопасность и первоисточник
В Excel данные легко случайно удалить или «поправить» не ту ячейку. В SQL вы работаете с копией данных или через запросы на чтение. Сами данные в базе остаются в сохранности, что критически важно для серьезной аналитики.

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

Главная мысль: Excel идеален для финальной визуализации и быстрых правок «на коленке». Но SQL — это фундамент. Это двигатель, который позволяет вам доставать золото из гор сырой информации.

(«Не будьте заложниками ячеек, становитесь повелителями данных»).

Мы часто слышим, что за искусственным интеллектом будущее. Но прямо сейчас на примере Microsoft мы видим, какую цену за это будущее приходится платить. Акции компании обвалились на 24% с начала года — это худший результат со времен великого кризиса 2008 года.

Что пошло не так, когда на кону стоят миллиарды?

1. Аппетиты растут быстрее прибыли
Microsoft вливает в ИИ-инфраструктуру запредельные суммы. Только в 2026 году расходы составят $146 млрд, а к 2028-му могут доползти до $191 млрд. Это космические деньги. Проблема в том, что инвесторы не видят адекватной отдачи. Облачный сервис Azure замедляется, а Copilot пока не стал тем «золотым ключиком», который открывает кошельки всех пользователей.
(«Вливать деньги в бак — это хорошо, но только если машина едет быстрее»).

2. Иллюзия незаменимости
Пока Microsoft строит огромную и дорогую экосистему, на пятки наступают гибкие стартапы вроде OpenAI и Anthropic. Инвесторы всерьез опасаются, что клиенты предпочтут работать с создателями ИИ напрямую, минуя посредника в лице Microsoft. Это ставит под удар всю маржинальность бизнеса.

3. Ловушка ожиданий
Рынок перегрет ожиданиями «чуда». Но реальность такова: инфраструктура стоит дорого, аренда серверов растет, а реальное внедрение технологий в повседневную работу идет гораздо медленнее, чем рисуют в презентациях. Капитализация компании «похудела» на $360 млрд — это цена, которую рынок выставил за неоправданный оптимизм.
(«Будет больно, но реальность всегда берет свое»).

Главная мысль: Этот обвал — громкий звоночек для всего рынка. Нельзя бесконечно заливать деньги в технологию, если она не приносит понятной прибыли здесь и сейчас. Даже у самого крупного игрока в мире ресурсы не безграничны.

Транзакции в SQL: почему «ручной» DML — это всегда риск?

Друзья, сегодня поговорим о безопасности. Когда вы пишете INSERT, UPDATE или DELETE (те самые DML-операции), вы меняете живое тело базы данных. И если делать это «в лоб», без страховки, цена ошибки может быть фатальной.

Как оформляется транзакция?
В PostgreSQL всё просто. У вас есть три главных инструмента:

BEGIN — вы выставляете «оцепление». С этого момента всё, что вы делаете, происходит в изолированном пространстве.

COMMIT — вы подтверждаете изменения. Только после этой команды ваши правки увидят все остальные и они станут постоянными.

ROLLBACK — ваш «счастливый билет» назад. Если что-то пошло не так, эта команда мгновенно откатывает базу в состояние до слова BEGIN.

Почему при ручных операциях нужно ВСЕГДА открывать транзакцию явно?

По умолчанию многие клиенты (и сам Postgres) работают в режиме autocommit. Это значит: нажал Enter — данные изменились навсегда. И вот здесь кроются главные ловушки:

1. Тот самый «забытый WHERE»
Классика: ты хотел обновить статус заказа для одного клиента, но забыл дописать WHERE id = 5. Без явной транзакции ты только что обновил статус у всех миллиона клиентов.
(«В этот момент в офисе обычно становится очень тихо»).
Если бы ты сначала написал BEGIN, ты бы увидел в консоли: «UPDATE 1000000». Сказал бы: «Ой!», набрал ROLLBACK и пошел пить чай с целой базой.

2. Логическая целостность
Иногда одно действие в бизнесе — это три запроса в базе. Например, перевод денег: у одного отнять, другому прибавить, в лог записать. Если на втором запросе моргнет свет или пропадет связь, без транзакции деньги у одного уйдут, а другому не придут. Явная транзакция гарантирует: либо выполнится всё, либо ничего.

3. Проверка результата перед фиксацией
Когда ты открыл транзакцию руками, ты можешь сделать UPDATE, а следом — SELECT, чтобы убедиться, что всё изменилось именно так, как ты планировал. И только когда глаз радуется результату, давать команду COMMIT.

(«Возьмите за правило: заходите в базу подёргать данные — сразу пишите BEGIN. Это как пристегнуть ремень в машине: вроде и без него едет, но со стеной лучше не встречаться»).

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

Почему проектирование базы данных — это 70% успеха всего проекта?

Давайте признаем один факт: создать таблицы в базе можно за пять минут. Но спроектировать систему, которая будет работать годы, не превращаясь в клубок костылей — это отдельное искусство. Часто разработку начинают «от фронтенда» или «от бизнес-логики», оставляя базу на потом. И это большая ошибка.

Почему этапу проектирования нужно уделять максимум внимания еще до первой строчки кода?

1. База — это фундамент, который сложно передвинуть
Если вы ошиблись в цвете кнопки на сайте, это правится за минуту. Если вы ошиблись в логике связей между сущностями (например, не учли, что у одного договора может быть несколько соисполнителей), переделка затронет всё: от структуры таблиц до кода бэкенда и API.
(«Ошибки проектирования — самые дорогие в исправлении»).

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

3. Производительность закладывается на старте
Многие думают: «Потом накинем индексов и всё полетит». Но индексы не спасут, если сама структура данных заставляет базу делать лишнюю работу. Правильное распределение данных по таблицам (нормализация) и выбор верных типов данных — это то, что позволяет системе «летать» на стандартном железе даже при росте нагрузки.

4. Бизнес-логика в зеркале базы
Проектирование базы — это лучший способ проверить, понимаете ли вы бизнес-процесс. Если вы не можете четко распределить данные по таблицам и настроить связи, значит, в самой логике продукта есть «белые пятна». Работа над схемой данных заставляет задавать правильные вопросы заказчику еще на берегу.
(«Хорошая схема БД — это фактически документация вашего бизнеса в табличном виде»).

Главная мысль: Внимание к деталям при разработке БД — это не перфекционизм. Это забота о будущем проекта. Когда схема логична и прозрачна, разработка идет быстрее, багов меньше, а новые фичи внедряются без боли.

«Почему у разработчиков случаются триггеры от слова "триггеры" (и когда они всё-таки нужны)» 🤯🐘

В мире баз данных триггеры — это своего рода «серые кардиналы». Они живут в тени, их не видно в коде приложения, но они обладают абсолютной властью над данными. И именно за это их ненавидят и обожают одновременно.

Почему триггеры превращают отладку в ад?

Основная претензия к триггерам — это скрытая логика. Представьте: вы пишете простейший UPDATE одной колонки. Вы ожидаете, что изменится одна цифра, но внезапно:

Обновляются еще пять таблиц.

Улетает письмо клиенту.

База выдает ошибку о нарушении бизнес-логики, которой вообще нет в вашем коде.

Вы идете в код приложения, перерываете весь Python/Java-бэкенд и... ничего не находите. Потому что логика спрятана «внутри» самой таблицы.

Главные «грехи» триггеров:

Невидимость. Новым разработчикам крайне сложно понять, почему система ведет себя именно так, если они не заглянули в DDL каждой таблицы.

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

Сложность миграции. Перенести логику триггеров между разными СУБД — та еще задача, так как синтаксис процедурных языков везде свой.

Но если они такие плохие, зачем их оставили в 2026 году?

Несмотря на весь негатив, есть ситуации, где триггеры — это единственное элегантное решение.

Когда они реально нужны:

Железный аудит. Если вам нужно логировать каждое изменение в таблице (кто, когда и что поменял), триггер сделает это гарантированно. Даже если админ залез в базу руками в обход приложения — триггер всё запишет.

Поддержание сложных итогов (Aggregates). Например, у вас есть таблица заказов и таблица остатков на складе. Триггер может мгновенно вычитать товар при создании заказа. Это быстрее и надежнее, чем делать это на стороне приложения.

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

(«Триггер — это как автоматическая ловушка в заброшенном замке: она сработает всегда, даже если вы про неё забыли. Главное — самому в неё не попасть при инвентаризации»).

Главная мысль: Триггеры — это инструмент «последнего шанса». Их не стоит использовать для обычной бизнес-логики, которую можно описать в коде. Но для задач безопасности и тотального контроля за целостностью данных ничего лучше еще не придумали.

Отчет State of Analytics Engineering 2026: Скорость в ущерб качеству? 📉🏗
Свежий аналитический отчет от dbt Labs вскрыл серьезный перекос в развитии современных систем данных. Индустрия разогналась до предела, но, похоже, забыла укрепить фундамент. Ускорение разработки с помощью ИИ происходит на фоне деградации механизмов контроля и доверия.

Основные выводы исследования, которые определяют повестку 2026 года:

1. Инфраструктура против человеческого ресурса
Расходы на облачные вычисления и хранилища (warehouse compute) растут у 57% компаний. При этом бюджеты на команды и специалистов увеличились лишь у 36%.
Возникает опасный разрыв: спрос на данные растет, инфраструктура раздувается, но количество людей, способных управлять этим хаосом, не увеличивается пропорционально. Вливание денег в «железо» не исправляет системные ошибки в архитектуре.

2. Дисбаланс в автоматизации
72% команд уже внедрили ИИ в написание кода. Однако автоматизация контроля качества, тестирования и мониторинга (observability) является приоритетом лишь для 24%.
Результат: код генерируется в разы быстрее, но механизмы его стабилизации не справляются. Скорость разработки опережает скорость контроля.

3. Кризис доверия и галлюцинации
71% респондентов выражают серьезную обеспокоенность тем, что недостоверные данные или «галлюцинации» ИИ доходят до конечных бизнес-заказчиков.
Проблема качества данных остается вызовом номер один. В условиях, когда пайплайны работают непрерывно и на высоких скоростях, цена одной ошибки возрастает многократно.

4. Отсутствие владельцев и дефицит грамотности
Фундаментальные проблемы никуда не исчезли:

41% организаций заявляют о неопределенности в вопросах владения данными (ambiguous ownership).

36% фиксируют низкий уровень грамотности в работе с данными (data literacy) среди стейджеров.

Главная мысль: 2026-й — это год контекста и дисциплины. Скорость больше не является преимуществом, если вашим данным нельзя доверять. Как сказала Пуджа Крахен из Okta: «Дисциплина в моделировании и валидации — это больше не "лучшая практика", это обязательное требование для выживания».

Сколько строк вернет этот SQL запрос ?

❗️Self-Join: Когда таблица ссылается сама на себя

Self-Join (самообъединение) — это обычный JOIN, в котором таблица соединяется с собственной копией. В SQL нет отдельной команды для этого, мы просто дважды указываем одну и ту же таблицу, но даем ей разные «имена» (алиасы), чтобы база не запуталась.

Зачем это нужно?
Самый живой пример — иерархия сотрудников.

В структуре компании у каждого сотрудника есть руководитель. Но руководитель — это тоже сотрудник, который числится в той же самой таблице. В итоге у нас есть колонка manager_id, которая ссылается на id из этой же таблицы.

Чтобы вывести в одном отчете имя сотрудника и имя его начальника, нам нужно «раздвоить» таблицу в запросе:

=============================
SELECT
e.name AS employee_name,
m.name AS manager_name
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id;
=============================

Как это работает:

Мы берем таблицу employees и называем её e (Employee — исполнитель).

Присоединяем её же под именем m (Manager — руководитель).

Условие ON e.manager_id = m.id связывает конкретного сотрудника с его шефом.

Почему это важно:
Если использовать INNER JOIN, то из отчета пропадет самый главный босс (генеральный директор), так как у него нет руководителя (manager_id будет NULL). Поэтому здесь мы используем LEFT JOIN, чтобы сохранить в списке всех, даже тех, над кем «только небо».

✅Итог:
Self-Join — это способ превратить плоский список сотрудников в понятное дерево связей. Если данные в одной строке зависят от данных в другой строке той же таблицы — вам нужен этот прием.

Почему age = NULL всегда возвращает «Ложь»?

Чтобы это запомнить, нужно понять философию NULL. В базах данных NULL — это не ноль и не пустая строка. Это неизвестность.

Представьте, что перед вами две закрытые коробки. Вы не знаете, что внутри первой, и не знаете, что внутри второй. Можете ли вы сказать, что их содержимое одинаково? Нет. Оно неизвестно.

В SQL любая операция сравнения с NULL (будь то =, >, < или !=) выдает результат UNKNOWN. А так как фильтр WHERE пропускает только те строки, где условие истинно (TRUE), строки с NULL просто отбрасываются.

Как запомнить это навсегда?
Используйте аналогию с «правилом детектива»:

Равенство (=) — это опознание: «Этот человек (данные) точно тот, кого мы ищем».

IS NULL — это констатация отсутствия: «У нас нет данных об этом человеке».

Вы не можете «приравнять» данные к их отсутствию. Вы можете только спросить: «Является ли это поле пустым?» (IS NULL) или «Содержит ли оно хоть что-то?» (IS NOT NULL).

Итог:
В SQL есть три типа логики: True, False и Unknown. NULL — это всегда неопределенность. Поэтому вместо знака равенства мы используем специальные операторы-проверки.

DISTINCT ON: Умный поиск уникальных строк
Обычный DISTINCT работает просто: он смотрит на всю строку целиком и убирает полные дубликаты. DISTINCT ON работает тоньше: он оставляет уникальные значения только по конкретным колонкам, которые вы укажете в скобках.

Зачем это нужно?
Представьте таблицу заказов. У вас есть customer_id (кто купил), order_date (когда) и amount (на сколько). Вам нужно получить список всех клиентов и для каждого вывести только его самый первый заказ.

Если использовать обычный DISTINCT, вы получите все уникальные комбинации дат и сумм. А с DISTINCT ON вы получите ровно по одной строке на клиента.

Как это пишется:

SELECT DISTINCT ON (customer_id)
       customer_id,
       order_date,
       amount
FROM orders
ORDER BY customer_id, order_date ASC;

Три правила работы с DISTINCT ON:

1. Порядок в ORDER BY: Это критически важно. Колонки, указанные в DISTINCT ON (...), должны быть первыми в списке ORDER BY. Это нужно базе, чтобы сгруппировать данные перед выбором строки.

2. Выбор «той самой» строки: Именно ORDER BY определяет, какая именно строка из группы дубликатов попадет в результат. Хотите последний заказ? Используйте DESC. Хотите самый дешевый? Сортируйте по amount ASC.

3. Читаемость: Этот оператор заменяет использование оконных функций (вроде ROW_NUMBER()), делая запрос короче и понятнее для тех, кто знает PostgreSQL.

Когда это использовать?
Когда нужно найти «самый первый/последний/лучший» объект в каждой группе.

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

Главная мысль: DISTINCT ON — это способ сказать базе: «Сгруппируй данные по этим полям, отсортируй их внутри группы и отдай мне только верхнюю строку».

В чем магия ORDER BY 1?
В PostgreSQL разрешено указывать номер столбца из секции SELECT вместо его имени.

SELECT name, age, salary
FROM employees
ORDER BY 1; — Сортировка по полю name

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

Почему это ломается?

Основная проблема — жесткая привязка к структуре. Представьте, что через месяц вам понадобилось добавить техническое поле id в начало выборки.

Было:

SELECT name, salary FROM employees ORDER BY 1;
— Сортировка по имени (логично)

Стало:

SELECT id, name, salary FROM employees ORDER BY 1;
— Сортировка внезапно переключилась на ID

Если этот запрос зашит в коде приложения или в BI-отчете, визуализация «поплывет». Пользователь ожидал список по алфавиту, а получил набор данных, отсортированный по внутреннему идентификатору базы.

Почему это плохая практика (Code Review):

Скрытая логика. Читая ORDER BY 1, коллега (или вы через полгода) должен каждый раз возвращаться глазами к SELECT, чтобы понять, что именно сейчас является «первым». Имена столбцов (например, ORDER BY name) делают код самодокументированным.

Проблемы с рефакторингом. Любое изменение порядка полей в SELECT требует синхронного изменения всех ORDER BY и GROUP BY, завязанных на цифры. Шанс забыть об этом и выкатить баг — почти 100%.

Неявное поведение при SELECT *. Если использовать звездочку, то ORDER BY 1 будет сортировать по тому полю, которое идет первым в схеме таблицы. Если кто-то изменит схему (например, через ALTER TABLE), порядок строк в приложении изменится без предупреждения.

Когда это допустимо?

В консоли (psql, DBeaver), когда нужно быстро «повертеть» данные.

В очень длинных и сложных UNION, где имена колонок могут различаться, но типы данных совпадают.

Вердикт:

В черновиках — пожалуйста. В репозитории — только имена. Это признак профессионализма и заботы о тех, кто будет поддерживать ваш код.

(«Код пишется для людей, и только иногда — для машин. Не заставляйте людей считать колонки на пальцах»).

Массовые блокировки в Claude: как не потерять доступ к своим проектам
Американская нейросеть Claude от компании Anthropic начала масштабную волну блокировок аккаунтов. Под ограничения попали многие пользователи из России, включая разработчиков и ИТ-специалистов, для которых сервис стал важным рабочим инструментом.

Для справки:

Claude — это продвинутый чат-бот на базе ИИ, созданный выходцами из OpenAI. Его ценят за высокое качество работы с кодом и сложной аналитикой.

Антифрод-система — автоматический алгоритм безопасности. Он анализирует IP-адреса, платежные данные и использование VPN, чтобы выявлять подозрительную активность и блокировать доступ «рискованным» аккаунтам.

Почему это происходит?
Эксперты выделяют несколько ключевых факторов:

Ужесточение антифрод-политики. Постоянная смена IP-адресов через VPN и регистрация на зарубежные виртуальные номера выглядят для системы как мошенничество.

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

Защита данных. Anthropic борется с «дистилляцией» моделей — когда их нейросеть используют для обучения других алгоритмов, что запрещено правилами.

Чем это опасно?
Многие привыкли использовать Claude как полноценную рабочую среду, храня внутри историю исследований и проектную документацию. Блокировка происходит без объяснения причин, и доступ к этим данным восстановить практически невозможно.

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

Переход на API. Использование модели через API часто оказывается стабильнее, чем прямой доступ через интерфейс чата.

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

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

Подробный разбор ситуации и мнения экспертов читайте в материале РБК:www.rbc.ru/technology...

SQL как меню в ресторане: в чем сила декларативного подхода?

Большинство языков программирования — императивные. Когда вы пишете на них код, вы даете компьютеру пошаговую инструкцию: «создай переменную», «запусти цикл», «проверь условие», «прибавь единицу». Это похоже на приготовление блюда по рецепту, где вы сами стоите у плиты.

SQL работает иначе. Это декларативный язык.

Представьте, что вы пришли в ресторан. Чтобы пообедать, вам не нужно идти на кухню, чистить овощи и следить за температурой конфорки. Вы просто открываете меню и говорите: «Я хочу салат „Цезарь“ без сухариков». А кухня ресторана и повар уже сами решают как они будут готовить этот салат для вас.

Как это работает в базе данных:
Ваш запрос (Заказ): Вы формулируете только конечный результат.

«Мне нужны имена всех клиентов, которые совершили покупку в мае». Вы не объясняете базе, как именно перебирать строки или в какой оперативной памяти их хранить.

SELECT name FROM users WHERE last_purchase_date >= '2026-05-01';

СУБД (Кухня): Получив ваш запрос, система активирует «шеф-повара» — оптимизатор запросов. Он сам решает, как выполнить задачу быстрее:

- Использовать ли индекс (быстрый поиск по списку)?
- Просканировать ли всю таблицу целиком?
- В каком порядке объединять данные?

Результат (Блюдо): Вы получаете готовый набор данных. Вам не важно, какие внутренние алгоритмы использовала база, если результат соответствует вашему описанию в SELECT.

Фокус на задаче: Вы тратите время на описание того, что нужно получить, а не на написание сложных циклов и алгоритмов сортировки.

Оптимизация «под капотом»: Создатели баз данных (PostgreSQL, MySQL) постоянно совершенствуют алгоритмы поиска. Когда выходит обновление СУБД, ваш старый запрос может начать работать быстрее сам по себе, потому что «кухня» стала работать эффективнее.

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

Итог: SQL позволяет нам быть «заказчиками», а не «исполнителями». Главное — максимально точно описать в запросе, какой «салат» вы хотите получить в итоге, чтобы система не принесла вам ничего лишнего.

🏗 Программистский костыль или гениальное упрощение: зачем в SQL пишут WHERE 1=1?

Если вы когда-нибудь заглядывали в логи запросов своего приложения или разбирали чужой код, то наверняка встречали эту странную конструкцию. На первый взгляд она кажется бессмысленной: зачем просить базу данных проверять, равно ли число 1 самому себе?

На самом деле, это не ошибка и не «мусор», а старый добрый прием для работы с динамическими фильтрами.

В чем проблема?
Представьте, что вы пишете код для поиска в интернет-магазине. Пользователь может выбрать категорию, бренд, диапазон цен или... не выбрать ничего. В коде вам нужно собрать SQL-запрос из кусочков.

Без «заглушки» логика становится перегруженной:

- Нужно проверить: если это первый фильтр, пишем WHERE.
- Если фильтров несколько, для всех последующих нужно писать AND.
- Если фильтров нет вовсе, блок WHERE нужно вообще стереть.

Это порождает кучу условий if/else, в которых легко запутаться и получить ошибку синтаксиса.

Решение: Универсальный фундамент
Конструкция WHERE 1=1 всегда истинна. Она не фильтрует данные, но создает «якорь», к которому можно бесконечно приклеивать любые условия.

Теперь логика в коде становится максимально простой: мы всегда добавляем к запросу строку, начинающуюся с AND.

Как это выглядит в коде:

— База запроса
SELECT * FROM products WHERE 1=1
— Все остальные условия просто дописываются в конец
AND category = 'электроника'
AND price <= 50000
AND in_stock = true

Не тормозит ли это базу?
Нет. Современные оптимизаторы СУБД видят, что это константное выражение. Они просто игнорируют его при построении плана выполнения. Для производительности разницы между WHERE 1=1 AND price > 0 и просто WHERE price > 0 не существует.

Итог: WHERE 1=1 — это классический пример того, как небольшая хитрость в SQL делает программный код чище и надежнее.

⚔️ Священная война в SQL: COUNT(*) против COUNT(1) — есть ли разница?

В мире баз данных есть споры, которые не утихают десятилетиями. Один из самых жарких — что быстрее и правильнее использовать для подсчета строк: COUNT(*) или COUNT(1)?

Недавно мы с коллегой чуть не сорвали обед, доказывая друг другу свою правоту. Один утверждал, что COUNT(1) экономит ресурсы, другой — что современным базам всё равно. Мы решили прекратить спор и просто посмотреть, как это работает «под капотом».

В чем суть спора?
Сторонники COUNT(1) верят, что эта конструкция работает быстрее. Логика такая: раз мы передаем единицу (константу), базе не нужно смотреть на содержание строк, она просто считает количество этих единиц.

Сторонники COUNT(*) парируют: это стандарт SQL. Звездочка здесь не означает «выбрать все столбцы» (как в SELECT *), а является специальным токеном, указывающим базе посчитать количество строк.

Что говорит оптимизатор?
Правда в том, что для современных СУБД (PostgreSQL, MySQL, Oracle, SQL Server) разницы в производительности нет.

Когда вы отправляете запрос, оптимизатор первым процессом разбирает его и строит план выполнения. Он видит и COUNT(*), и COUNT(1) как одну и ту же задачу: «посчитать количество записей в выборке».

А вот COUNT(column_name) — это другое!
Важно не путать эти две конструкции с COUNT(имя_столбца). Вот тут разница колоссальная:

COUNT(*) и COUNT(1) считают все строки, включая те, где данные отсутствуют.

COUNT(column_name) считает только те строки, где в указанном столбце нет значения NULL.

Если в столбце много пустых значений, COUNT(column_name) отработает медленнее (базе придется проверять содержимое каждой ячейки) и выдаст другое число.

Итог спора:
Мы оба оказались правы: запросы выполняются одинаково быстро.

Если вы привыкли к COUNT(1) — это не ошибка.

Если пишете COUNT(*) — вы следуете стандарту.

Лично я предпочитаю COUNT(*), потому что это делает код более читабельным для любого SQL-разработчика и четко говорит о намерении посчитать именно строки.

📈 Рынок СУБД в России: от форсированного рывка к стабильному росту
Российский рынок систем управления базами данных (СУБД) по итогам 2025 года показал интересную динамику. После взрывного роста 2024 года (+34%), темпы ожидаемо стабилизировались на уровне 13,9%, а объем рынка достиг 101,9 млрд рублей.

Что это значит для индустрии?
Эксперты ЦСР отмечают, что мы перешли от «аварийного» импортозамещения к планомерному развитию.

- Рынок СУБД по-прежнему растет быстрее всего ИТ-сектора (3–10%).
- Доля отечественного ПО в новых продажах достигла 91%.
- К 2032 году прогнозируется рост рынка почти в 3 раза — до 281 млрд рублей.

Кто в лидерах?
Топ-игроки, которые сейчас определяют технологический ландшафт:

- Postgres Pro и «Тантор Лабс» (ГК «Астра») — доминирование решений на базе PostgreSQL.
- Группа Arenadata — фокус на аналитических системах и подготовке данных для ИИ.
- Yandex B2B Tech и DIS Group.

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

- Гибридные модели. Компании всё чаще выбирают микс из локальных (on-premise) и облачных инсталляций. Это позволяет быстрее запускать ИИ-проекты, не перестраивая всю внутреннюю инфраструктуру.

- Проблема «тяжелого» наследия. Заменить условный Oracle Exadata на обычный PostgreSQL без потери производительности всё еще сложно. Рынок ждет решений, которые сохранят архитектурную мощь при полной совместимости с экосистемой Postgres.

Интересный факт: несмотря на успехи импортозамещения, более 50% уже установленных решений в компаниях — всё еще зарубежные. Это огромный пласт работы для миграции в ближайшие годы.

Итог: СУБД остаются самым значимым сегментом ИТ-рынка. Для специалистов это сигнал: спрос на экспертов по PostgreSQL и архитекторов данных в ближайшие 5–7 лет будет только расти.

📖 Как понять индексы в PostgreSQL с помощью обычной книги
Представьте, что вы держите в руках толстый учебник по базам данных на 1000 страниц. Вам нужно найти все упоминания термина «ACID». Как вы поступите?

Вы можете начать перелистывать книгу с самой первой страницы и читать строчка за строчкой, надеясь наткнуться на нужное слово. В базах данных этот процесс называется Sequential Scan (последовательное сканирование). Если книга большая, вы потратите кучу времени.

Но обычно в конце хороших книг есть предметный указатель (индекс). Вы открываете его на букву «А», находите слово «ACID» и видите список страниц: 124, 345, 782. После этого вы сразу переходите к нужным страницам.

Так и работают индексы в PostgreSQL.

Как это устроено в базе данных?
Когда вы создаете индекс для столбца в таблице (например, по ID пользователя или по адресу электронной почты), PostgreSQL создает отдельную скрытую структуру данных. Она очень похожа на предметный указатель:

Ключ (Слово в указателе): Это значение из вашего столбца (например, user_id = 452).

Указатель (Номер страницы): В PostgreSQL это называется ctid — физический адрес строки на диске (номер блока данных и смещение внутри него).

Когда вы пишете запрос WHERE user_id = 452, планировщик базы данных не читает всю таблицу с диска. Он обращается к индексу, находит нужный user_id, забирает его физический адрес и мгновенно извлекает конкретную строку уже из самой таблицы по этому адресу. Этот процесс называется Index Scan.

Цена скорости: почему нельзя сделать «указатель» для каждого слова?
Кажется, что если индексы так ускоряют работу, то нужно повесить их на каждый столбец. Но вернемся к нашей аналогии с книгой.

Если вы сделаете указатель для абсолютно каждого слова, то сам указатель по объему станет больше, чем исходная книга. База данных начнет раздуваться в размерах.

Самое главное: представьте, что вы решили дописать в книгу новую главу или исправить абзац. Вам придется не просто изменить текст, но и заново пересчитать страницы для сотен слов в предметном указателе.

В SQL то же самое: каждая операция INSERT, UPDATE или DELETE заставляет базу данных тратить ресурсы на обновление всех связанных индексов. Чтение ускоряется, но запись замедляется.

Итог
Индексы в PostgreSQL — это мощный инструмент, который превращает хаотичный поиск в точечную работу. Главное правило разработчика здесь звучит так: индексируйте только те столбцы, по которым действительно часто происходит фильтрация (WHERE) или соединение таблиц (JOIN), и всегда помните о цене, которую база платит при записи данных.

🗣 Soft skills для работы с данными: почему умение задавать вопросы важнее знания синтаксиса

В ИТ-индустрии до сих пор жив стереотип: лучший специалист по данным — это тот, кто может без гугла написать пятиэтажный запрос с оконными функциями и JOIN. Но на практике технический хард-скилл — это лишь инструмент. Если инструмент применяется к неверно понятой задаче, результат будет бесполезным.

Самый главный навык аналитика, разработчика СУБД или дата-инженера — это умение задавать правильные вопросы до того, как начнется написание кода.

Бизнес говорит на одном языке, база данных — на другом
Основные проблемы с данными возникают не из-за того, что разработчик забыл синтаксис JOIN. Они возникают на этапе перевода бизнес-требований в SQL-логику.

Бизнес-заказчик часто приходит с размытой формулировкой: «Мне нужен отчет по активным пользователям за прошлый месяц». Если джуниор сразу побежит писать SELECT, он почти наверняка ошибется. Мидл или синьор сначала остановит заказчика и задаст несколько уточняющих вопросов.

Почему формулировка «активный пользователь» — это ловушка?
Без уточнения деталей этот запрос можно интерпретировать десятком разных способов. Умение задавать вопросы превращает абстракцию в точные метрики:

Вопрос 1: Кто такой «активный» пользователь? Тот, кто просто авторизовался? Тот, кто зашел на сайт и провел там больше 5 минут? Или тот, кто совершил целевое действие (например, оплатил заказ)?

Вопрос 2: Что мы считаем «прошлым месяцем»? Календарный месяц (с 1 по 31 число) или скользящее окно в 30 дней от сегодняшней даты?

Вопрос 3: Как обрабатывать аномалии? Включать ли в отчет внутренних тестировщиков, сотрудников компании или ботов, которые генерируют ложную активность?

Разница между синтаксисом и логикой
Знание синтаксиса SQL проверяет СУБД. Если вы ошибетесь в операторе или забудете запятую, база данных выдаст ошибку и не выполнит запрос. Это безопасная ошибка — вы сразу понимаете, что код не работает.

Проблема «неправильных вопросов» гораздо опаснее. Если вы не уточнили логику задачи, вы напишете синтаксически идеальный запрос. Он выполнится без ошибок, вернет красивую таблицу с цифрами, но эти цифры будут ложными. Бизнес примет на их основе неверное решение, и цена такой ошибки будет огромной.

Чек-лист: вопросы, которые спасают ИТ-проекты
Прежде чем приступать к проектированию таблиц или написанию сложных выборок, выработайте привычку прояснять три уровня контекста:

Контекст цели: «Какую бизнес-проблему мы решаем этим отчетом/выборкой?» (Иногда выясняется, что нужные данные уже есть в другой системе).

Контекст ограничений: «Есть ли крайние случаи (edge cases), которые нужно исключить или, наоборот, учесть особо?» (NULL-значения, заблокированные аккаунты, возвраты товаров).

Контекст использования: «Как часто будет запускаться этот запрос и кто его потребитель?» (Одноразовая выгрузка для маркетолога требует меньше оптимизации, чем запрос, который будет вызываться каждую секунду в мобильном приложении).

Итог:

Изучить синтаксис SQL можно и нужно. Научиться видеть за таблицами реальные бизнес-процессы и сомневаться в двусмысленных формулировках — задача сложнее. Но именно этот навык превращает простого исполнителя («кодера») в сильного инженера, чьим решениям доверяет команда.

🇲🇹 Беспрецедентный шаг: Мальта предоставит всем гражданам бесплатный доступ к ChatGPT Plus
Мальта стала первой страной в мире, которая запускает национальную программу партнерства с OpenAI и полностью оплатит своим гражданам премиум-подписку на искусственный интеллект.

Инициатива получила говорящее название «Искусственный интеллект для всех».

Что получат жители Мальты?
Каждый гражданин страны (включая тех, кто живет за границей) на один год получит бесплатный доступ к ChatGPT Plus, который в обычном режиме стоит $20 в месяц. С учетом населения острова — это охват около 570 тысяч человек.

Финансовые детали сделки OpenAI и правительство Мальты не раскрывают, но масштаб проекта для небольшого государства впечатляет.

«Мальта — первая страна, запустившая партнерство такого масштаба, потому что мы не позволяем нашим гражданам отставать в цифровую эпоху. Мы ставим наших людей в авангард глобальных перемен», — заявил министр экономики страны Сильвио Шембри.

Зачем это нужно государству и OpenAI?
Для Мальты: это грандиозный эксперимент по тотальной цифровизации и повышению ИТ-грамотности населения. Страна фактически создает прецедент, когда доступ к передовому ИИ приравнивается к базовым социальным благам (как интернет или медицина).

Для OpenAI: это идеальная «песочница» и огромная база данных. Компания Сэма Альтмана получит уникальный опыт интеграции технологий в масштабах целой (пусть и небольшой) страны и сможет изучить, как ИИ влияет на экономику, образование и повседневную жизнь общества, когда он доступен абсолютно всем.

Старт программы намечен уже на май. Будет крайне интересно понаблюдать за результатами этого эксперимента через год.

Как думаете, приживется ли такая практика в других странах или проект окажется слишком дорогим и неэффективным?

🚀 Путь от аналитика до архитектора СУБД: как перестать просто просить данные и начать ими управлять

В ИТ-индустрии существует устойчивый тренд: техническое крыло аналитиков (дата-, системные и бизнес-аналитики) всё чаще переходит в разработку и инженерию данных. Это достаточно логичная и сильная эволюция. Аналитик годами смотрит на данные с точки зрения бизнеса, но в какой-то момент упирается в потолок и хочет понять, как устроена эта магия «под капотом».

Переход из аналитика в архитектора СУБД (на примере той же PostgreSQL) — один из самых красивых и сильных карьерных треков. Вы уже знаете, зачем нужны данные, осталось разобраться, как заставить их летать на терабайтных объемах.

Давайте разберем три главных сдвига в мышлении и технологиях, которые придется пройти на этом пути.

1. От логики к «железу»: как Postgres видит ваш запрос
Для аналитика база данных — это черный ящик. Вы написали красивый SELECT с кучей JOIN и оконных функций, нажали кнопку и ждете отчет. Если он считается 10 минут — ну что ж, база большая.

Для архитектора этот черный ящик становится прозрачным. Вы начинаете мыслить физическими ограничениями сервера.

Как было: Вы думаете категориями строк и таблиц.

Как стало: Вы открываете EXPLAIN ANALYZE и оцениваете стоимость запроса. Вы начинаете понимать, упрется ли ваш JOIN в дисковое чтение (I/O) или база сможет удержать нужную таблицу в оперативной памяти (shared_buffers). Вы настраиваете конфигурацию так, чтобы тяжелая сортировка не сбрасывалась во временные файлы на медленный диск.

2. От идеальных учебников к жесткому прагматизму
В аналитике ценится идеальная структура данных. Вас учили третьей нормальной форме (3NF): данные не должны дублироваться, всё должно быть разбито на аккуратные связанные справочники.

Архитектор СУБД знает: правила созданы для того, чтобы их нарушать ради производительности.

Как было: Схема данных, где справочник регионов отделен от городов, города от улиц, а улицы от адресов клиентов. Красиво? Да.

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

3. От одного сервера — к масштабируемой экосистеме
Аналитик работает с тем, что настроили сисадмины или DevOps-инженеры. Архитектор сам проектирует отказоустойчивую среду, которая не «ляжет» в черную пятницу или во время ночного расчета тяжелых моделей ИИ.

Как было: База упала? Пишем в поддержку, ждем.

Как стало: Вы закладываете в архитектуру кластер высокой доступности (например, связку Postgres + Patroni). Вы настраиваете потоковую репликацию: основной сервер (Master) занимается только быстрой записью и транзакциями, а все аналитики со своими тяжелыми отчетами автоматически отправляются на чтение на резервные серверы (Replica).

Почему у бывших аналитиков здесь огромное преимущество?

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

У аналитика уже развито продуктовое мышление. Вы понимаете, какие метрики важны для компании, как пользователи будут крутить эти данные и какие edge cases (крайние случаи, вроде отмен заказов или пустых значений NULL) могут сломать логику. Добавив к этому понимание системных процессов Postgres, работы с памятью и индексами, вы становитесь уникальным и крайне дорогим специалистом на рынке.

С чего начать переход уже завтра?

Перестаньте верить базе на слово. Возьмите свой самый частый рабочий запрос и пропустите его через EXPLAIN (ANALYZE, BUFFERS). Разберитесь, почему Postgres выбрал именно этот индекс и сколько страниц данных он прочитал из кэша, а сколько — с диска.

Разверните свой Postgres. Не в облаке, где всё настроено за вас, а локально через Docker и покрутите конфигурацию.

Спрос на таких инженеров в эпоху больших данных и ИИ будет только расти.