Обновление PostgreSQL остановит ваш CDC-пайплайн на wal2json, если не поправить конфиг
13 августа вышли PostgreSQL 18.6, 17.11, 16.15, 15.19 и 14.24: они закрывают CVE-2026-6471 (7,2 балла из 10 по шкале опасности). Аккаунт с атрибутом REPLICATION мог передать в CREATE_REPLICATION_SLOT любой путь к библиотеке, а сервер загружал её и выполнял код от имени пользователя ОС. Ошибке 12 лет: она с самого появления логического декодирования в 9.4.
Закрыли белым списком: параметр output_plugin_libraries, по умолчанию pgoutput и test_decoding. Любой другой плагин вывода, включая wal2json и decoderbufs, после обновления получает отказ, и декодирование не стартует, пока библиотеку не впишут в список и не перечитают конфиг.
Атрибут REPLICATION висит на бэкапах, standby, мониторинге и CDC. Проверьте plugin в pg_replication_slots до апдейта и допишите его в параметр тем же окном обслуживания.
13 августа вышли PostgreSQL 18.6, 17.11, 16.15, 15.19 и 14.24: они закрывают CVE-2026-6471 (7,2 балла из 10 по шкале опасности). Аккаунт с атрибутом REPLICATION мог передать в CREATE_REPLICATION_SLOT любой путь к библиотеке, а сервер загружал её и выполнял код от имени пользователя ОС. Ошибке 12 лет: она с самого появления логического декодирования в 9.4.
Закрыли белым списком: параметр output_plugin_libraries, по умолчанию pgoutput и test_decoding. Любой другой плагин вывода, включая wal2json и decoderbufs, после обновления получает отказ, и декодирование не стартует, пока библиотеку не впишут в список и не перечитают конфиг.
Атрибут REPLICATION висит на бэкапах, standby, мониторинге и CDC. Проверьте plugin в pg_replication_slots до апдейта и допишите его в параметр тем же окном обслуживания.
Офсетный лаг не скажет, насколько старые данные лежат в вашем озере
Он показывает, на сколько сообщений консьюмер отстал от топика, а не возраст данных. При неровном потоке один и тот же лаг означает то минуты, то часы, а SLA на свежесть написан во времени.
В Twilio для пайплайнов на Apache Hudi Delta Streamer лаг считают во времени, не трогая продюсеров и консьюмеров: берут последний коммит Hudi в S3, достают из него чекпоинт Kafka, перематывают топик на этот офсет и вычитают время сообщения из текущего.
Грабли: в последнем коммите чекпоинта может не быть, если его сделал параллельный легаси-пайплайн. Тогда алгоритм идёт по истории коммитов назад, до ближайшего с метаданными.
Офсетный мониторинг это не отменяет: он ловит зависшего консьюмера, а time in queue даёт возраст данных и порог свежести с алертами на каждый пайплайн. Разбор на 5 трлн записей в месяц у InfoQ.
Он показывает, на сколько сообщений консьюмер отстал от топика, а не возраст данных. При неровном потоке один и тот же лаг означает то минуты, то часы, а SLA на свежесть написан во времени.
В Twilio для пайплайнов на Apache Hudi Delta Streamer лаг считают во времени, не трогая продюсеров и консьюмеров: берут последний коммит Hudi в S3, достают из него чекпоинт Kafka, перематывают топик на этот офсет и вычитают время сообщения из текущего.
Грабли: в последнем коммите чекпоинта может не быть, если его сделал параллельный легаси-пайплайн. Тогда алгоритм идёт по истории коммитов назад, до ближайшего с метаданными.
Офсетный мониторинг это не отменяет: он ловит зависшего консьюмера, а time in queue даёт возраст данных и порог свежести с алертами на каждый пайплайн. Разбор на 5 трлн записей в месяц у InfoQ.
Трассировки OpenTelemetry можно свернуть в метрику, которая показывает, какой SQL чинить первым
Запрос, вчера укладывавшийся в десятки миллисекунд, сегодня держит витрину минуту, а в трассировках десятки тысяч спанов, и по ним не видно, что просело.
Разбор на блоге CNCF предлагает не копить телеметрию, а сворачивать спаны БД в метрики: у спана есть длительность и текст запроса, по нормализованному тексту считается агрегат, и вместо потока событий выходит ряд для дашборда и алерта.
Метрика закрывает два вопроса. Оптимизация: ускорение какого запроса даст больше всего, если взвесить длительность на частоту вызовов. Инцидент: какой запрос отклонился от собственной нормы прямо сейчас.
SELECT по orders без индекса на customer_id отдаёт 20 мс на 10 тыс. строк и минуты на 10 млн: запрос не менялся, вырос объём. В статье это собрано в лабораторию, повторяемую на своём стеке.
Запрос, вчера укладывавшийся в десятки миллисекунд, сегодня держит витрину минуту, а в трассировках десятки тысяч спанов, и по ним не видно, что просело.
Разбор на блоге CNCF предлагает не копить телеметрию, а сворачивать спаны БД в метрики: у спана есть длительность и текст запроса, по нормализованному тексту считается агрегат, и вместо потока событий выходит ряд для дашборда и алерта.
Метрика закрывает два вопроса. Оптимизация: ускорение какого запроса даст больше всего, если взвесить длительность на частоту вызовов. Инцидент: какой запрос отклонился от собственной нормы прямо сейчас.
SELECT по orders без индекса на customer_id отдаёт 20 мс на 10 тыс. строк и минуты на 10 млн: запрос не менялся, вырос объём. В статье это собрано в лабораторию, повторяемую на своём стеке.
Q4 не сходится, а человек, который писал пайплайн, уволился два года назад
Знакомый маршрут: grep по ETL-скриптам, обход внешних ключей, вью, которая ссылается на другую вью, а та на таблицу, которую когда-то переименовали. Через час вопросов больше, чем ответов.
Задача называется происхождением данных: откуда пришло значение, что от него зависит, через какие преобразования оно прошло и что сломается, если тронуть источник. dbt и Airflow отвечают на это в границах своего графа, а то, что собирается внутри базы, остаётся серым пятном.
Отвечать приходится не только финансистам. SOX требует разбирать квартальный отчёт по шагам, GDPR — объяснять логику обработки данных, а BCBS 239 появился, когда регуляторы устали слышать от банков, что источник цифр риска не установить.
В блоге Cybertec разбирают, что на этот вопрос отвечает PostgreSQL 19.
Знакомый маршрут: grep по ETL-скриптам, обход внешних ключей, вью, которая ссылается на другую вью, а та на таблицу, которую когда-то переименовали. Через час вопросов больше, чем ответов.
Задача называется происхождением данных: откуда пришло значение, что от него зависит, через какие преобразования оно прошло и что сломается, если тронуть источник. dbt и Airflow отвечают на это в границах своего графа, а то, что собирается внутри базы, остаётся серым пятном.
Отвечать приходится не только финансистам. SOX требует разбирать квартальный отчёт по шагам, GDPR — объяснять логику обработки данных, а BCBS 239 появился, когда регуляторы устали слышать от банков, что источник цифр риска не установить.
В блоге Cybertec разбирают, что на этот вопрос отвечает PostgreSQL 19.
❤1
SQL-запрос доезжает до хранилища набором ключей, и от их формата зависит, будет чтение по ключу или скан
Когда план запроса в TiDB или CockroachDB показывает скан, на уровне SQL это уже не объяснить: раскладывает таблицы и строки по парам «ключ-значение» слой ниже, и обычно его не видно.
В шестой части серии про учебную базу SaarDB автор пишет этот слой руками: движок хранения у него умеет только ключи и строковые значения, про таблицы и типы колонок он не знает. По шагам:
• почему CREATE TABLE и INSERT сводятся к одной операции PUT;
• зачем схема таблицы уезжает под служебный ключ с префиксом
• как уложить структуру со списком колонок и их типами в значение, которое всегда строка;
• как из строки собрать ключ, по которому её потом найдут.
Свою базу писать не обязательно: понимание, во что превращается таблица в хранилище, объясняет цену предиката не по ключевой колонке.
Когда план запроса в TiDB или CockroachDB показывает скан, на уровне SQL это уже не объяснить: раскладывает таблицы и строки по парам «ключ-значение» слой ниже, и обычно его не видно.
В шестой части серии про учебную базу SaarDB автор пишет этот слой руками: движок хранения у него умеет только ключи и строковые значения, про таблицы и типы колонок он не знает. По шагам:
• почему CREATE TABLE и INSERT сводятся к одной операции PUT;
• зачем схема таблицы уезжает под служебный ключ с префиксом
_schema:;• как уложить структуру со списком колонок и их типами в значение, которое всегда строка;
• как из строки собрать ключ, по которому её потом найдут.
Свою базу писать не обязательно: понимание, во что превращается таблица в хранилище, объясняет цену предиката не по ключевой колонке.
Подзапрос в списке колонок пересчитывается для каждой строки витрины
Витрина собирается минутами, а в плане Postgres висит узел SubPlan. Внутри max(amount) из payments по payments.user_id = users.id, и он выполняется отдельно для каждой строки внешнего запроса: на 10 млн пользователей это 10 млн обращений к payments.
В WHERE так почти не бывает: IN и EXISTS планировщик обычно разворачивает в semi join и проходит payments один раз. Цену задаёт место, где стоит подзапрос, а сами виды подзапросов разбирают на freeCodeCamp.
Лечится агрегатом в CTE: сгруппировать payments по user_id один раз и приджойнить LEFT JOIN, тогда вместо SubPlan появится HashAggregate. В Spark план смотреть отдельно: там коррелированные подзапросы допускаются не везде.
Прогоните EXPLAIN по медленным витринам и поищите SubPlan: в списке колонок его стоит переписывать, под фильтром он обычно уже развёрнут в join.
Витрина собирается минутами, а в плане Postgres висит узел SubPlan. Внутри max(amount) из payments по payments.user_id = users.id, и он выполняется отдельно для каждой строки внешнего запроса: на 10 млн пользователей это 10 млн обращений к payments.
В WHERE так почти не бывает: IN и EXISTS планировщик обычно разворачивает в semi join и проходит payments один раз. Цену задаёт место, где стоит подзапрос, а сами виды подзапросов разбирают на freeCodeCamp.
Лечится агрегатом в CTE: сгруппировать payments по user_id один раз и приджойнить LEFT JOIN, тогда вместо SubPlan появится HashAggregate. В Spark план смотреть отдельно: там коррелированные подзапросы допускаются не везде.
Прогоните EXPLAIN по медленным витринам и поищите SubPlan: в списке колонок его стоит переписывать, под фильтром он обычно уже развёрнут в join.
SQL от ассистента выполнился без ошибок, но число в отчёте завышено
Запрос пишется за десять секунд и сразу отрабатывает, а база проверила в нём только грамматику. Опечатку в имени таблицы она поймает; сумму не по тому столбцу, задвоение строк после join и фильтр, поставленный после группировки, пропустит. Это валидный SQL с неверным числом.
Типовой случай: выручка за вычетом возвратов как
Самая дешёвая проверка: до SUM выполнить COUNT(*) с тем же join и сверить с числом строк до соединения. Не совпало, значит join размножает строки, и возвраты надо свернуть подзапросом, а присоединять уже готовую сумму.
Ещё четыре проверки, от фильтров до знаменателя, разобраны в статье на dev.to.
Запрос пишется за десять секунд и сразу отрабатывает, а база проверила в нём только грамматику. Опечатку в имени таблицы она поймает; сумму не по тому столбцу, задвоение строк после join и фильтр, поставленный после группировки, пропустит. Это валидный SQL с неверным числом.
Типовой случай: выручка за вычетом возвратов как
SUM(o.amount) - SUM(COALESCE(r.refund_amount, 0)) с LEFT JOIN из orders в refunds. Если возврат по заказу оформлен двумя платежами, заказ превращается в две строки, и его amount уходит в сумму дважды.Самая дешёвая проверка: до SUM выполнить COUNT(*) с тем же join и сверить с числом строк до соединения. Не совпало, значит join размножает строки, и возвраты надо свернуть подзапросом, а присоединять уже готовую сумму.
Ещё четыре проверки, от фильтров до знаменателя, разобраны в статье на dev.to.
Пятнадцать минут простоя ClickHouse не должны стоить вам пропущенных событий
Типовая схема: сервис читает очередь в памяти и пишет пачками в аналитическую базу. Останавливаете её на миграцию схемы или контейнер уходит в рестарт, и события за эти минуты исчезают: держать их было некому.
NATS JetStream закрывает разрыв. В базовом NATS сообщение живёт до первого получателя, в JetStream поток пишется на диск и ждёт подтверждения от консьюмера. База поднялась через 15 минут — консьюмер дочитывает пропущенное с последней подтверждённой позиции. Вместо дыры в данных отставание, которое рассасывается само.
В разборе пайплайна для аналитики свопов Solana показана вторая половина: схема таблицы solana_swaps в ClickHouse и то, как один поток разводится на историческую аналитику и на живую отдачу в WebSocket.
А чем вы прикрываете аналитическую базу на время миграций?
Типовая схема: сервис читает очередь в памяти и пишет пачками в аналитическую базу. Останавливаете её на миграцию схемы или контейнер уходит в рестарт, и события за эти минуты исчезают: держать их было некому.
NATS JetStream закрывает разрыв. В базовом NATS сообщение живёт до первого получателя, в JetStream поток пишется на диск и ждёт подтверждения от консьюмера. База поднялась через 15 минут — консьюмер дочитывает пропущенное с последней подтверждённой позиции. Вместо дыры в данных отставание, которое рассасывается само.
В разборе пайплайна для аналитики свопов Solana показана вторая половина: схема таблицы solana_swaps в ClickHouse и то, как один поток разводится на историческую аналитику и на живую отдачу в WebSocket.
А чем вы прикрываете аналитическую базу на время миграций?
9 млрд генетических изменений собрали в карту на 1 ПБ
Для каждого возможного односимвольного изменения в геноме человека уже рассчитан прогноз влияния на молекулярные процессы. В AlphaGenome Atlas лежат 9 млрд таких прогнозов, которые можно быстро запрашивать без повторного расчёта модели.
Чтобы не перебирать тысячи показателей, индекс влияния варианта AVI объединяет прогнозы для кодирующих и некодирующих участков ДНК. На данных 54 000+ участников UK Biobank группировка по ожидаемому молекулярному эффекту помогла найти на 22% больше связей в некодирующих участках.
Для ML-практика здесь полезен сам паттерн: массовый предварительный расчёт, единая оценка и быстрый отбор кандидатов для дальнейшего исследования.
Для каждого возможного односимвольного изменения в геноме человека уже рассчитан прогноз влияния на молекулярные процессы. В AlphaGenome Atlas лежат 9 млрд таких прогнозов, которые можно быстро запрашивать без повторного расчёта модели.
Чтобы не перебирать тысячи показателей, индекс влияния варианта AVI объединяет прогнозы для кодирующих и некодирующих участков ДНК. На данных 54 000+ участников UK Biobank группировка по ожидаемому молекулярному эффекту помогла найти на 22% больше связей в некодирующих участках.
Для ML-практика здесь полезен сам паттерн: массовый предварительный расчёт, единая оценка и быстрый отбор кандидатов для дальнейшего исследования.
Полезная ML-модель может затеряться в соседнем домене
Эмбеддинги Netflix, созданные для студийных процессов, находят границы сцен, визуальные переходы и структуру видео. Эти числовые представления контента потенциально пригодились бы рекламе для подбора объявления под контекст, а рекомендательной системе — для сопоставления темы или настроения эпизода с интересами зрителя.
Переиспользованию мешает видимость. У доменов разные стеки, бизнес-метрики и оргструктуры; без инфраструктуры поиска наработки превращаются в чёрные ящики, недоступные другим ML-командам.
В Netflix TechBlog разбирают, зачем компании понадобился граф жизненного цикла моделей. Для своей ML-платформы стоит проверить: найдёт ли соседняя команда подходящую модель до того, как обучит свою?
Эмбеддинги Netflix, созданные для студийных процессов, находят границы сцен, визуальные переходы и структуру видео. Эти числовые представления контента потенциально пригодились бы рекламе для подбора объявления под контекст, а рекомендательной системе — для сопоставления темы или настроения эпизода с интересами зрителя.
Переиспользованию мешает видимость. У доменов разные стеки, бизнес-метрики и оргструктуры; без инфраструктуры поиска наработки превращаются в чёрные ящики, недоступные другим ML-командам.
В Netflix TechBlog разбирают, зачем компании понадобился граф жизненного цикла моделей. Для своей ML-платформы стоит проверить: найдёт ли соседняя команда подходящую модель до того, как обучит свою?
Единый API может убрать маршрутизацию моделей из ваших микросервисов
Запросу рекомендательной системы мало попасть в модель: нужно выбрать нужную версию, экземпляр и шард кластера с учётом пользователя и сценария. При этом клиентскому сервису не обязательно знать устройство платформы инференса.
В Netflix эту границу провели через единый доменно-независимый API. Платформа сама направляет трафик к нужному экземпляру модели и шарду. По данным за 2025 год, так она обслуживала сотни типов и версий моделей и 1 млн запросов в секунду. Архитектуру подробнее разбирают в Netflix TechBlog.
Для своей платформы полезно разделить ответственность так же: доменный сервис знает единый контракт, а платформа выбирает тип и версию модели, экземпляр и шард. Тогда исследователи могут быстрее выпускать новые версии, не раскрывая сервисам детали маршрутизации.
Запросу рекомендательной системы мало попасть в модель: нужно выбрать нужную версию, экземпляр и шард кластера с учётом пользователя и сценария. При этом клиентскому сервису не обязательно знать устройство платформы инференса.
В Netflix эту границу провели через единый доменно-независимый API. Платформа сама направляет трафик к нужному экземпляру модели и шарду. По данным за 2025 год, так она обслуживала сотни типов и версий моделей и 1 млн запросов в секунду. Архитектуру подробнее разбирают в Netflix TechBlog.
Для своей платформы полезно разделить ответственность так же: доменный сервис знает единый контракт, а платформа выбирает тип и версию модели, экземпляр и шард. Тогда исследователи могут быстрее выпускать новые версии, не раскрывая сервисам детали маршрутизации.
Redshift сводит SQL-запросы к хранилищу и озеру данных в один движок
Таблицы хранилища и файлы в озере данных теперь можно запрашивать через один SQL-движок Redshift. Новые инстансы RG на AWS Graviton обрабатывают нагрузки хранилища до 2,2 раза быстрее RA3, а цена одного виртуального процессорного ядра у них на 30% ниже.
Встроенный движок выполняет SQL-запросы сразу по хранилищу и озеру. По данным Amazon Web Services, на данных Apache Iceberg ускорение относительно RA3 достигает 2,4 раза, на Apache Parquet — 1,5 раза. Это рассчитано в том числе на поток запросов от ИИ-агентов.
Для выбора размера есть прямые пары: вместо ra3.xlplus предлагается rg.xlarge с 4 виртуальными ядрами и 32 ГБ памяти, вместо ra3.4xlarge — rg.4xlarge с 16 ядрами и 128 ГБ. Перед миграцией стоит прогнать собственные SQL-нагрузки: все показатели AWS заявлены как «до».
Таблицы хранилища и файлы в озере данных теперь можно запрашивать через один SQL-движок Redshift. Новые инстансы RG на AWS Graviton обрабатывают нагрузки хранилища до 2,2 раза быстрее RA3, а цена одного виртуального процессорного ядра у них на 30% ниже.
Встроенный движок выполняет SQL-запросы сразу по хранилищу и озеру. По данным Amazon Web Services, на данных Apache Iceberg ускорение относительно RA3 достигает 2,4 раза, на Apache Parquet — 1,5 раза. Это рассчитано в том числе на поток запросов от ИИ-агентов.
Для выбора размера есть прямые пары: вместо ra3.xlplus предлагается rg.xlarge с 4 виртуальными ядрами и 32 ГБ памяти, вместо ra3.4xlarge — rg.4xlarge с 16 ядрами и 128 ГБ. Перед миграцией стоит прогнать собственные SQL-нагрузки: все показатели AWS заявлены как «до».
У Kimi K3 2,8 трлн параметров, но один токен использует 104 млрд
Общий размер модели плохо описывает объём вычислений на токен. В Kimi K3 маршрутизатор почти в каждом слое активирует для него 16 из 896 специализированных блоков нейросети, которые называют экспертами. Ещё два общих эксперта обрабатывают каждый токен.
Архитектура со смесью экспертов сокращает вычисления на токен, но не убирает инфраструктурные расходы. Веса выбранных экспертов всё равно нужно читать из памяти графических процессоров, а представления токенов могут передаваться между ними.
В разборе freeCodeCamp сравнивают Mixtral, DeepSeekMoE, LatentMoE и Kimi K3: как эксперты становились мельче, зачем сжимали маршрутизируемый путь и чем стабилизировали обучение. При сравнении таких моделей смотрите на активные параметры, то есть задействованные для одного токена, и на перемещение данных.
Общий размер модели плохо описывает объём вычислений на токен. В Kimi K3 маршрутизатор почти в каждом слое активирует для него 16 из 896 специализированных блоков нейросети, которые называют экспертами. Ещё два общих эксперта обрабатывают каждый токен.
Архитектура со смесью экспертов сокращает вычисления на токен, но не убирает инфраструктурные расходы. Веса выбранных экспертов всё равно нужно читать из памяти графических процессоров, а представления токенов могут передаваться между ними.
В разборе freeCodeCamp сравнивают Mixtral, DeepSeekMoE, LatentMoE и Kimi K3: как эксперты становились мельче, зачем сжимали маршрутизируемый путь и чем стабилизировали обучение. При сравнении таких моделей смотрите на активные параметры, то есть задействованные для одного токена, и на перемещение данных.
Апсерт в справочник не возвращает id при конфликте: чем это чинят в Postgres 19
Наполнение dimension-таблиц упирается в одно и то же: вставить строку, если её ещё нет, и в любом случае забрать её id для фактовой таблицы. INSERT ... ON CONFLICT DO NOTHING RETURNING id отдаёт строку только тогда, когда вставка действительно произошла. Если строка уже есть, в результате ноль записей, и в dbt-модели или Airflow-таске появляется второй SELECT либо CTE, склеивающий вставленное с найденным.
Разбор синтаксиса грядущего Postgres 19 смотрит, чем в новой версии выражать этот get-or-create, и какие ещё мелкие правки синтаксиса экономят по несколько строк SQL на запрос.
Если ваши пайплайны наполняют справочники именно так, есть смысл посмотреть заранее: переписывать такие места удобнее один раз, до апгрейда.
Наполнение dimension-таблиц упирается в одно и то же: вставить строку, если её ещё нет, и в любом случае забрать её id для фактовой таблицы. INSERT ... ON CONFLICT DO NOTHING RETURNING id отдаёт строку только тогда, когда вставка действительно произошла. Если строка уже есть, в результате ноль записей, и в dbt-модели или Airflow-таске появляется второй SELECT либо CTE, склеивающий вставленное с найденным.
Разбор синтаксиса грядущего Postgres 19 смотрит, чем в новой версии выражать этот get-or-create, и какие ещё мелкие правки синтаксиса экономят по несколько строк SQL на запрос.
Если ваши пайплайны наполняют справочники именно так, есть смысл посмотреть заранее: переписывать такие места удобнее один раз, до апгрейда.
Pgedge
Looking Forward to Postgres 19: Syntax Potpourri
Shaun Thomas discusses ON CONFLICT DO SELECT, GROUP BY ALL, COPY JSON: three Postgres 19 syntax additions that fix things you've been quietly working around for years.
❤1
Баланс кошелька можно не хранить: он считается из append-only журнала операций
Изменяемая колонка ломается на гонке: два процесса читают 100, оба пишут 150, одно списание исчезает. В разборе маркетплейса на Go и Postgres такой колонки нет: есть журнал, куда строки только добавляются, а баланс выводится агрегатами:
• total = sum(grant, credit) - sum(debit);
• reserved = sum(reserve) - sum(release);
• available = total - reserved.
Корректность автор не отдал коду сервиса: мьютекс и лок в Redis не переживают второй инстанс и не откатываются вместе с транзакцией. Каждая операция с деньгами укладывается в одну транзакцию Postgres, конфликтующие части сериализует СУБД.
Аналитике это экономит слой: история движений уже в таблице, пересчёт задним числом делается запросом. Цена — агрегат на каждое чтение баланса.
Как считаете деньги у себя: агрегат на лету или снапшот с досчётом?
Изменяемая колонка ломается на гонке: два процесса читают 100, оба пишут 150, одно списание исчезает. В разборе маркетплейса на Go и Postgres такой колонки нет: есть журнал, куда строки только добавляются, а баланс выводится агрегатами:
• total = sum(grant, credit) - sum(debit);
• reserved = sum(reserve) - sum(release);
• available = total - reserved.
Корректность автор не отдал коду сервиса: мьютекс и лок в Redis не переживают второй инстанс и не откатываются вместе с транзакцией. Каждая операция с деньгами укладывается в одну транзакцию Postgres, конфликтующие части сериализует СУБД.
Аналитике это экономит слой: история движений уже в таблице, пересчёт задним числом делается запросом. Цена — агрегат на каждое чтение баланса.
Как считаете деньги у себя: агрегат на лету или снапшот с досчётом?
Низкий балл новой модели может оказаться ошибкой тестового стенда
Модель с открытыми весами провалила проверку. Это ещё не доказывает, что она слабее текущей: причиной могут быть сломанный шаблон запроса, неверные эталонные ответы или функция оценки, которая ищет не те слова.
За 60 минут практикум предлагает собрать на Python три тестовых задания, оценку по ключевым словам и файл JSONL, где каждый ответ занимает отдельную строку. Контрольный тест проверяет сам стенд. Результат: запускаемый скрипт и статический HTML-отчёт для команды.
В практикуме на DEV Community остались настройка библиотеки OpenAI, запуск через бесплатный API MonkeyCode и публикация отчёта на бесплатном сервере. Это промоматериал MonkeyCode. В августе 2026 года бесплатный тариф включал 10 млн токенов; перед запуском сверьте квоту и адрес сервиса в README.
Модель с открытыми весами провалила проверку. Это ещё не доказывает, что она слабее текущей: причиной могут быть сломанный шаблон запроса, неверные эталонные ответы или функция оценки, которая ищет не те слова.
За 60 минут практикум предлагает собрать на Python три тестовых задания, оценку по ключевым словам и файл JSONL, где каждый ответ занимает отдельную строку. Контрольный тест проверяет сам стенд. Результат: запускаемый скрипт и статический HTML-отчёт для команды.
В практикуме на DEV Community остались настройка библиотеки OpenAI, запуск через бесплатный API MonkeyCode и публикация отчёта на бесплатном сервере. Это промоматериал MonkeyCode. В августе 2026 года бесплатный тариф включал 10 млн токенов; перед запуском сверьте квоту и адрес сервиса в README.
Числовые статусы упрощают миграции и прячут смысл данных
В витрине код
В MySQL новый элемент в середине перечисления enum может переписать всю таблицу с блокировкой и запасом диска размером с неё. В PostgreSQL enum хранится отдельным типом:
Цена: значение трудно удалить, тип не переносится между СУБД и не годится для изменчивого набора или значений с метаданными. В статье на DEV Community сравнивают enum, числа и таблицу-справочник.
Где у вас граница между этими вариантами, и что уже ломалось при смене статуса?
В витрине код
3 непонятен без словаря. SQL-запросы и дашборды зависят от таблицы соответствий; её расхождение с базой даёт тихую ошибку.В MySQL новый элемент в середине перечисления enum может переписать всю таблицу с блокировкой и запасом диска размером с неё. В PostgreSQL enum хранится отдельным типом:
ADD VALUE меняет каталог без переписывания таблицы, а значение занимает 4 байта.Цена: значение трудно удалить, тип не переносится между СУБД и не годится для изменчивого набора или значений с метаданными. В статье на DEV Community сравнивают enum, числа и таблицу-справочник.
Где у вас граница между этими вариантами, и что уже ломалось при смене статуса?
Визуальный поиск получил энкодер на 51 страницу в секунду
Визуальный поиск по документам часто использует отдельный энкодер изображений и языковой декодер, хотя генерировать текст не нужно. NeoMME заменяет их одним двунаправленным трансформером: он превращает текст и фрагменты изображения в векторы.
Версия на 260 млн параметров при 2048×2048 на NVIDIA L40S кодирует около 51 страницы в секунду, вдвое быстрее ColModernVBERT в тех же условиях. Объединение токенов и квантование уменьшают индекс с 1,5 МБ до 6 КБ на страницу, сохраняя более 95% исходного качества первых десяти результатов по nDCG.
Модели на 260 млн и 800 млн параметров доступны в Hugging Face Transformers под Apache 2.0. Если индекс ограничивает поиск по большому архиву, стоит прогнать NeoMME на своей коллекции.
Визуальный поиск по документам часто использует отдельный энкодер изображений и языковой декодер, хотя генерировать текст не нужно. NeoMME заменяет их одним двунаправленным трансформером: он превращает текст и фрагменты изображения в векторы.
Версия на 260 млн параметров при 2048×2048 на NVIDIA L40S кодирует около 51 страницы в секунду, вдвое быстрее ColModernVBERT в тех же условиях. Объединение токенов и квантование уменьшают индекс с 1,5 МБ до 6 КБ на страницу, сохраняя более 95% исходного качества первых десяти результатов по nDCG.
Модели на 260 млн и 800 млн параметров доступны в Hugging Face Transformers под Apache 2.0. Если индекс ограничивает поиск по большому архиву, стоит прогнать NeoMME на своей коллекции.
А вы уже забрали свой подарок ко Дню программиста?
Мы в Tproger вместе с нашими друзьями собрали целую коробку подарков к вашему профессиональному празднику. Переходите по ссылке, трясите коробку и забирайте свой презент: https://tprg.ru/2CiK
Мы в Tproger вместе с нашими друзьями собрали целую коробку подарков к вашему профессиональному празднику. Переходите по ссылке, трясите коробку и забирайте свой презент: https://tprg.ru/2CiK
Мы вернулись из Суздаля с новым взглядом на магазин у дома
Были на tech-туре MAGNIT TECH «Без предела: Исходный код ритейла» и нам понравилось, как сошлись место и тема. Сначала купеческие ряды Суздаля, затем разговор о технологиях современной торговли на ГЭС на Нерли. В программе были и воздушный шар, и общение с инженерами у самовара. Получилась поездка, в которой было время и Суздалем полюбоваться, и познакомиться с людьми, стоящими за проектами.
Из выступлений особенно запомнился доклад Максима Покусенко о прогнозировании спроса. 17 млрд прогнозов ежедневно впечатляют, когда понимаешь связь с совершенно обыденной, казалось бы, вещью: приходишь в магазин, а нужный товар лежит на полке. Доклад помог увидеть, сколько расчётов стоит за этим привычным удобством.
Презентацию советуем посмотреть и тем, кто не работает с ритейлом. На одном понятном примере здесь можно проследить, как результат ML-модели становится решением о поставке.
Были на tech-туре MAGNIT TECH «Без предела: Исходный код ритейла» и нам понравилось, как сошлись место и тема. Сначала купеческие ряды Суздаля, затем разговор о технологиях современной торговли на ГЭС на Нерли. В программе были и воздушный шар, и общение с инженерами у самовара. Получилась поездка, в которой было время и Суздалем полюбоваться, и познакомиться с людьми, стоящими за проектами.
Из выступлений особенно запомнился доклад Максима Покусенко о прогнозировании спроса. 17 млрд прогнозов ежедневно впечатляют, когда понимаешь связь с совершенно обыденной, казалось бы, вещью: приходишь в магазин, а нужный товар лежит на полке. Доклад помог увидеть, сколько расчётов стоит за этим привычным удобством.
Презентацию советуем посмотреть и тем, кто не работает с ритейлом. На одном понятном примере здесь можно проследить, как результат ML-модели становится решением о поставке.