Backend Portal | Программирование

Летняя уборка в базе данных. Теперь пора посмотреть на сами запросы. pg_stat_statements отслеживает форму запросов, количество вызовов и время выполнения по всей базе. Это самый короткий путь от «база почему-то тормозит» до «вот эти пять запросов съедают большую часть времени». Включаем pg_stat_statements Если вы используете Crunchy Bridge, расширение уже доступно по умолчанию и можно сразу переходить к CREATE EXTENSION. При самостоятельном размещении нужно изменить postgresql.conf и перезапустить PostgreSQL shared_preload_libraries = 'pg_stat_statements, ...' pg_stat_statements.track = top Можно указать top или all. Режим all также учитывает запросы внутри функций и процедур. top используется по умолчанию и отслеживает только запросы, выполняемые клиентами. Затем включаем расширение для нужной базы CREATE EXTENSION IF NOT EXISTS pg_stat_statements; Ищем дорогие запросы Для такой проверки обычно полезнее смотреть на суммарное время выполнения. Запрос средней тяжести, который вызывается миллионы раз, часто наносит больше вреда, чем один редкий медленный запрос. SELECT round(total_exec_time::numeric, 1) AS total_ms, calls, round(mean_exec_time::numeric, 2) AS mean_ms, rows, query FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20; Также стоит смотреть на среднее время и количество строк. Например, последовательное сканирование может проявиться как большое total_exec_time и большое значение rows у запроса, который в норме должен находить одну конкретную запись. Что означают столбцы • calls — сколько раз запрос выполнялся с момента последнего сброса статистики • total_exec_time и mean_exec_time — суммарное и среднее время выполнения в миллисекундах • rows — общее количество полученных или изменённых строк • query — нормализованный запрос с параметрами вида $1 Статистика копится до ручного сброса SELECT pg_stat_statements_reset(); Важно помнить, что сброс удаляет всю накопленную историю. Для анализа можно либо сбросить статистику перед заранее известным периодом высокой нагрузки, либо сравнивать текущие данные с сохранённым ранее снимком. Что делать с найденными запросами 1. Запустить EXPLAIN с реальными параметрами. pg_stat_statements показывает форму запроса, но не план выполнения. 2. Проверить недостающие индексы, сбросы на диск из-за work_mem и слишком большое количество мелких запросов приложения вроде N+1. 3. После деплоя или добавления индекса сбросить статистику, дать системе поработать под реальной нагрузкой и проверить, уменьшилось ли суммарное время выполнения. 👉 @BackendPortal

Никто не хочет весь день смотреть в панели мониторинга PostgreSQL. Поэтому чувак сделал бота, который делает это за вас. Он находит, что работает не так, объясняет, что изменилось, и говорит, что нужно исправить в первую очередь. Метрики — это данные. pgbot даёт вам ответы. pgbot умеет следить за состоянием PostgreSQL, анализировать производительность запросов, находить медленные запросы и регрессии, разбирать блокировки и блокирующие запросы, анализировать таблицы и индексы, показывать работу VACUUM и autovacuum, отслеживать рост базы данных, находить первопричины проблем с помощью ИИ и давать рекомендации. Подключаться можно напрямую к базе или через агента с приватным доступом. Бесплатный, с открытым исходным кодом и написан на Go. 👉 @BackendPortal

Переименование поля в API изнутри кажется безобидным. Снаружи оно может положить каждый дашборд, который рассчитывал на старое имя. Любое изменение API попадает в одну из двух категорий, и от этого зависит всё. Если изменение ломающее, нужно поднимать версию: удаление или переименование полей, добавление обязательных параметров или фундаментальное изменение поведения эндпоинта. Безопасные изменения можно выпускать без новой версии: добавлять необязательные поля, новые эндпоинты или просто ускорять работу. Большая часть боли появляется из-за двух противоположных ошибок. Не версионировать вообще — и каждый релиз превращается для пользователей в лотерею. Версионировать всё подряд — и в итоге вы поддерживаете пять версий, а разработчики уже не понимают, какую использовать. Несколько простых правил помогают держать баланс: — Показывайте версию явно, например /v1/ в URL, как это делают Stripe и GitHub. — Используйте семантическое версионирование, чтобы смена мажорной версии сразу означала необходимость изменений в клиентском коде. — Если версия выводится из эксплуатации, говорите об этом прямо в ответе через заголовок Sunset и давайте 6–12 месяцев на миграцию. Версия API — это обещание о том, что не изменится. Нарушать его нужно редко и громко. Никогда — молча. Какую ошибку вы встречали чаще? 👉 @BackendPortal

Переписывание Postgres на Rust завершено. Заявляется полное воспроизведение поведения Postgres один в один: все тесты проходят, совместимость сохранена, система готова к использованию в production. Если это действительно так, то звучит безумно: один из самых важных проектов в мире баз данных фактически воспроизвели на Rust. 👉 @BackendPortal

Ещё один отличный плейлист по структурам данных и алгоритмам от pmavrin. https://youtube.com/playlist?list=PLrS21S1jm43igE57Ye_edwds_iL7ZOAG4&si=4mS5lXn3uxI-V2LM 👉 @BackendPortal

«Современные микропроцессоры: руководство на 90 минут». Автор пишет, что вчера обсуждал со стажёрами разные аспекты оптимизации производительности и был приятно удивлён их интересом к внутреннему устройству современных процессоров. В итоге он собрал компактный материал, который примерно за полтора часа даёт обзор того, как устроены современные микропроцессоры и что важно понимать для оптимизации производительности. https://lighterra.com/papers/modernmicroprocessors/ 👉 @BackendPortal

97% инженеров Google заявили, что довольны своим инструментом для ревью кода. Почти во всех командах, где я работал, процесс PR был болью. Обычно открываешь PR, ждёшь ревью — иногда несколько дней — потом начинается ещё один круг. В Google всё устроено иначе. Там ревью — часть самого процесса написания кода. Компания изучила собственный процесс на выборке из 9 млн проверенных изменений. И вот что особенно интересно. Медианный размер изменения — всего 24 строки. Более 10% изменений вообще затрагивают одну строку. 70% изменений попадают в основную ветку в течение 24 часов после отправки на ревью. Медианное время полного ревью — меньше 4 часов. Для сравнения: у AMD этот показатель составляет 17,5 часа, у Chrome OS — 15,7 часа. В исследованиях Microsoft фигурируют значения от 14,7 до 24 часов. Небольшие изменения получают первый комментарий меньше чем за час. Очень большие — примерно через 5 часов. Разработчик в среднем тратит на ревью 3,2 часа в неделю. Большинство изменений отправляются одному ревьюеру. И главная причина такой скорости — размер изменений. Разницу на 24 строки легко держать в голове. Разницу на 900 строк — уже нет. Внутренний инструмент Google называется Critique. Он убирает большую часть рутины. Статический анализ запускается ещё до отправки изменения. Система показывает, чья сейчас очередь действовать. Ревьюер может предложить исправление, а автор применяет его одним кликом. Но сильнее любой функции на культуру влияет одно правило. Ревьюер не может просто отклонить изменение и оставить всё как есть. Любая негативная обратная связь должна указывать на конкретную вещь, которую нужно исправить. Кроме того, каждое изменение должен одобрить ещё хотя бы один человек. То есть код всегда видят минимум двое. В книге Software Engineering at Google это сформулировано очень просто: «Доверие и коммуникация — основа процесса ревью кода». Однажды в нашей команде я видел огромный PR с изменениями в 2000 файлов. Его так и не смержили. Возможно, он открыт до сих пор. Если ревью у вас идут слишком медленно, сначала посмотрите на размер изменений. Возможно, проблема вообще не в процессе. 👉 @BackendPortal

90% PostgreSQL в 2026 году сводится к этим 10 вещам. Всё остальное — в основном споры об расширениях. 1. MVCC + VACUUM Обновления создают мёртвые строки. Если autovacuum настроен плохо, таблицы и индексы раздуваются, а задержки постепенно растут неделями. 2. Индексы под реальные сценарии запросов Порядок колонок в составных индексах важен. Нужно понимать частичные и покрывающие индексы, а также почему ORM иногда незаметно приводит к полному сканированию таблицы. 3. Блокировки и DDL ALTER TABLE может заблокировать запись. Важно понимать режимы блокировок, очереди и безопасные приёмы вроде CREATE INDEX CONCURRENTLY и обновления данных небольшими партиями. 4. Уровни изоляции и аномалии Read Committed, Repeatable Read, Serializable. Пропавшие или дублирующиеся строки часто нужно разбирать через конкурентные транзакции, а не искать проблему только в коде. 5. Управление соединениями Слишком много соединений убивает CPU и память. Нужны PgBouncer, адекватные размеры пулов и контроль долгих транзакций в состоянии idle in transaction. 6. WAL, checkpoints и репликация Объём WAL напрямую влияет на ввод-вывод. Плохие настройки checkpoints вызывают скачки задержек, а отставание реплик ломает чтение с реплик и делает переключение при сбое рискованным. 7. Основы планировщика запросов EXPLAIN (ANALYZE, BUFFERS) — ваш отладчик. Нужно понимать оценки количества строк, типы JOIN и когда требуется ANALYZE или расширенная статистика. 8. Наблюдаемость, привязанная к реальным сбоям Следите за p95 задержкой, ожиданием блокировок, временными файлами, попаданиями в кэш, отставанием autovacuum и реплик. Добавьте журнал медленных запросов с нормальными порогами. 9. Резервные копии и проверка восстановления Базовые бэкапы плюс архивирование WAL — минимум. Главная ошибка — никогда не проверять восстановление и уже во время аварии выяснить, что не хватает ролей, расширений или восстановление занимает слишком долго. 10. Безопасность и права Минимально необходимые права, отдельные владельцы объектов, никакого superuser у приложения, регулярная смена учётных данных, ограничение сетевого доступа и закрытая на запись схема public в production. 👉 @BackendPortal

Поздравляем, вы на 1 шаг ближе к работе мечты 🥳 Осталось только прочитать этот пост, подписаться на канал и откликнуться на вакансию 😉 Avito Career* — место, где Авито делится актуальными вакансиями и стажировками для бэкенд-разработчиков. Подписывайтесь, чтобы найти ту самую работу ✨ *карьера

Я ожидаю, что «джавафикация» экосистемы Go продолжится с появлением обобщённых методов в Go 1.27. Скорее всего, в стандартной библиотеке мы не увидим лишних обобщённых абстракций. Зато сторонние библиотеки наверняка с удовольствием воспользуются этой прекрасной возможностью. 👉 @BackendPortal

Нашёл сегодня несколько совершенно безумных открытых репозиториев для Kubernetes. Они автоматически генерируют архитектурные диаграммы: 1. KubeDiagrams Строит диаграммы из манифестов, Helm, Kustomize или текущего состояния кластера. [https://github.com/philippemerle/KubeDiagrams] 2. k8sviz Читает текущее состояние namespace и генерирует диаграмму через Graphviz. [https://github.com/mkimuram/k8sviz] 3. k8s-diagrams Написан на Go и получает данные напрямую через Kubernetes API. [https://github.com/trois-six/k8s-diagrams] 4. GruCloud Генерирует код и диаграммы для AWS, Azure, GCP и Kubernetes. [https://github.com/grucloud/grucloud] 5. k8s-to-diagram Превращает аннотации в манифестах в диаграмму взаимодействия сервисов. [https://github.com/kocierik/k8s-to-diagram] 👉 @BackendPortal

Яндекс анонсировал deep tech night — конференцию о вызовах, с которыми IT-индустрия сталкивается в эпоху AI. В программе — разговор о разработке, ML, инфраструктуре и данных на примере реальных инженерных задач. Приглашенный спикер Мо Гавдат, ex-Chief Business Officer Google X, расскажет, как генеративные нейросети меняют будущее разработки, процессы и роли в командах. Алексей Гусаков, CTO Бизнес-группы Поисковых сервисов и ИИ в Яндексе, разберёт переход от классического ML к генеративным моделям в рекомендательных системах. А Сергей Мельник, руководитель сервиса автономного транспорта и роботов Яндекса, объяснит, как устроен физический ИИ — системы, которые принимают решения не в чате, а в реальном мире. В онлайне будет доступен Hard-трек: трансляция технических докладов, Q&A-сессии с экспертами и запись после конференции будут бесплатны для зарегистрированных участников. Присоединяемся. Узнать подробности про офлайн и зарегистрироваться на трансляцию можно на сайте.

Чтобы хорошо разобраться в Kubernetes, свой кластер не обязателен. Нашёл репозиторий с 50 практическими лабораторными по Kubernetes, которые можно запускать прямо в браузере. → работа с kubectl вместо простого чтения документации → Pods, Deployments, StatefulSets, DaemonSets → HPA, scheduling, taints и tolerations → RBAC, Secrets, namespaces и quotas → Services, Ingress и реальные сценарии отладки В браузере поднимается настоящее Kubernetes-окружение, а задания построены вокруг практической работы. Просто открываете лабораторную и начинаете ломать вещи. Репозиторий: https://github.com/labex-labs/kubernetes-practice-labs 👉 @BackendPortal

Мгновенно клонируйте любую базу данных Postgres для быстрой разработки, тестирования и CI-пайплайнов. https://github.com/postgres-ai/database-lab-engine 👉 @BackendPortal

Если достаточно долго работать с базами данных, рано или поздно столкнёшься с проблемами подключений или параллелизма. В такой ситуации не стоит просто повышать лимиты в конфигурации. Лучше разобраться в архитектуре, чтобы понимать, почему это происходит и как исправить проблему оптимальным способом. Эта статья от гениального человека — отличный разбор управления подключениями в Postgres и возможных решений. Легко свести всё к особенностям Postgres с отдельным процессом на каждое соединение, но похожие проблемы могут возникать и в других базах данных, включая MySQL. Часто ответ кроется в пуле подключений, но и он добавляет свою сложность, которую тоже важно понимать. Статье уже 8 лет, но для Postgres она остаётся актуальной и в 2026 году. Ссылка ниже. https://brandur.org/postgres-connections 👉 @BackendPortal

Один из моих любимых инженерных блогов — DoltHub. Их материал про prolly trees очень хорошо объясняет, как можно встроить контроль версий прямо в движок хранения: контентно-адресуемые узлы, структурное разделение данных, деревья, не зависящие от истории изменений, и diff, который пропускает неизменившиеся поддеревья вместо полного сканирования базы. Особенно интересно сейчас следить за DoltLite — SQLite с нативным контролем версий. Это не SQLite, к которому просто прикрутили таблицу с коммитами. DoltLite форкает SQLite на уровне btree.h: парсер, планировщик, VDBE и значительная часть привычного API sqlite3_* остаются, а нижележащий страничный B-tree заменяется на контентно-адресуемое prolly tree. В результате коммиты, ветки, diff, построчный merge, clone, fetch, push и pull становятся операциями самой базы данных, а не логикой приложения. Мне особенно нравится эта модель для локальной памяти ИИ-агентов. Агент может создать ветку памяти перед экспериментом, посмотреть, что именно изменилось, слить полезное состояние и откатить всё остальное. Память превращается из очередного изменяемого blob в явное, проверяемое и воспроизводимое состояние. DoltHub применяет ту же идею хранения сразу к нескольким интерфейсам баз данных: Dolt — совместим с MySQL - https://github.com/dolthub/dolt Doltgres — вариант под PostgreSQL - https://github.com/dolthub/doltgresql DumboDB — совместим с MongoDB - https://github.com/dolthub/dumbodb Разные интерфейсы и реализации, но одна идея: контроль версий должен находиться на уровне хранения данных. Именно работа DoltHub во многом подтолкнула автора к созданию crabbuild/prolly — MIT-библиотеки prolly trees на Rust с асинхронным API, неизменяемыми упорядоченными картами, контентно-адресуемыми узлами, структурным разделением, снапшотами, быстрыми diff и merge, синхронизацией и подключаемыми хранилищами. https://github.com/crabbuild/prolly Есть биндинги для Python, Go, Java/Kotlin, Node, Ruby, Swift и WASM, а также адаптеры для SQLite, PostgreSQL, MySQL, Redis, DynamoDB, RocksDB, Turso, Spanner и других систем. Идея здесь не в создании ещё одной базы данных. Цель — сделать саму примитивную структуру переиспользуемой, чтобы на её основе можно было строить версионируемую память агентов, графы кода, воспроизводимые RAG-снапшоты, local-first состояние или собственные системы контроля версий. В этом и сила prolly trees: они превращают «контроль версий для X» из функции приложения в свойство самой структуры данных. 👉 @BackendPortal

Algorithms Джеффа Эриксона — одна из лучших книг по алгоритмам. Иллюстрации в ней просто отличные. Очень рекомендую. https://jeffe.cs.illinois.edu/teaching/algorithms/ 👉 @BackendPortal

Криптография — одна из недооценённых сильных сторон Go. Стандартная библиотека включает множество криптографических алгоритмов. Все они хорошо написаны, подробно документированы, достаточно компактны и тщательно проверены. Некоторые из них ещё и очень быстрые. Например, для одного из этапов SHA-256 Go использует платформенно-зависимый ассемблер. Моя реализация на Solod даже с Arm-интринсиками SHA-2 работает примерно на 10% медленнее. А если использовать только чистый Solod-код, то есть обычный C, она медленнее примерно в 7 раз. Криптография в Go сделана исключительно хорошо. 👉 @BackendPortal

5 советов по Docker, которые сэкономили бы мне полгода на борьбу с раздутыми образами. 1. Используйте slim-образы python:3.11-slim вместо python:3.11. Размер образа может сократиться примерно с 1 ГБ до 150 МБ. 2. Правильно располагайте инструкции в Dockerfile То, что меняется редко, размещайте в начале. Код приложения — ближе к концу. Так кэш Docker используется эффективнее, а сборка проходит быстрее. 3. `.dockerignore` — это не опция Добавьте туда node_modules, .git, тестовые файлы и всё лишнее. Никогда не копируйте их в образ. 4. Используйте многоэтапные сборки Собирайте приложение на одном этапе, а в финальный образ копируйте только готовый результат. Инструменты сборки не должны попадать в продакшен. 5. Проверяйте образ перед публикацией trivy image myapp:latest Это бесплатно, занимает около 30 секунд и помогает найти реальные уязвимости перед отправкой образа. 👉 @BackendPortal