MVCC в PostgreSQL и OrioleDB

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

PostgreSQL хранит в одном табличном пространстве все версии обновленных строк, пока вакуум не почистит этот мусор. Говорят, такой дизайн пришел из древности: когда клерки покидали офис, запирались двери, гас свет, все ИТ-системы прекращали обслуживать Транзакции Клиентов. В этот момент Инженер Ночной Вакуумной Очистки, в синем халате, очками и бороде, говорил “ну-с, приступим-с” и дергал красный вакуум-рычаг. Короче, на современных непрерывных нагрузках на запись этот подход приводит к куче проблем, деградации производительности, и кому интересно, могут освежить в памяти историю переезда многострадального Убера (статья старая, но показательная).

OrioleDB реализует концепцию UNDO-логов, такую же, какая была реализована в Oracle и MySQL: старые версии строк, которые нужны другим транзакциям, складываются отдельно, а в общем табличном пространстве хранятся только актуальные версии строк. Этот подход значительно ускоряет работу и упрощает очистку старых данных, особенно на больших нагрузках. Заодно в OrioleDB 64-битные счетчики транзакций, так что этот счетчик не переполняется по нескольку раз в неделю/месяц в большом проекте. Автор плагина - Александр Коротков, бывший сотрудник PostgresPRO и один из очень немногих коммитеров ядра PostgreSQL.

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

Не дожидаясь того момента, когда OrioleDB будет в PostgreSQL Коля Ихалайнен втащил OrioleDB в практикум по PostgreSQL к нашему курсу PostgreSQL 17: архитектура и тюнинг SQL-запросов. Так что все, кто запишется в апрельскую группу, смогут не только поработать с TPC-H data-сетом на обычном PostgreSQL 17 (миллионы юзеров и заказов ecom-проекта), но и проверить в деле OrioleDB. Старт - уже 24 апреля.

Devhands Радар: почитать на выходных (выпуск 20 апреля 2025)

🤩На этой неделе я провел интервью с Валентином Бартеневым (Angie), а подписчики любезно выложили mp3 в формате подкаста (см комментарии к посту).

Почти одновременно с этим вышла любопытная статья о тестировании производительности балансеров в режиме SSL. Тестировались 5 наиболее популярных серверов: HAProxy, Envoy, Nginx, Caddy и Traefik. Результаты меня несколько насторожили: HAProxy и Envoy самые высоко-производительные, Nginx внезапно заметно проихрывает, Caddy и Traefik с нагрузкой в 50K RPS вообще не справляются. У меня есть ряд сомнений в методике тестирования, но в целом автор прав: если мы не хотим разбираться в тонкостях, а просто взять контейнеры и собрать работающее решение - такой тест наиболее адекватен. Везде на стендах есть golang-бекенд, к которому собственно пробрасывется трафик, а я бы ожидал первый тест на статику без проксирования. KeepAlive к бекенду автор подкручивал, параменты SSL менял – nginx это не помогло.

До кучи поделюсь ещё парой ссылок. При подготовке к интервью я наткнулся на хорошую вводную статью Балансировка в Angie. Это хороший рефрешер базовых функций балансировщика.
Также предлагаю вашему вниманию свежую статью “Расширение возможностей веб-сервера при помощи WASM на примере Angie” об использовании WebAssembly для упрощения расширения Angie и интеграций.

🤩Из полей доносится: Valkey! (снова). Несколько недель назад вышел Valkey 8.1. Я не сделал ни анонса, ни обзора, за что меня в каментах “пожурил” Константин Ратвин (вместе с которым мы, кстати, очень скоро запускаем отдельный курс по Redis/Valkey). Короче, исправляюсь: вот подробная статья о том, но нового в Valkey 8.1. Обратите внимание на авторов, это оба сотрудники Percona. Если у вас Redis, и вы ещё игнорируете Valkey – присмотритесь. А ещё можно подумать, что будет с рынком, когда Valkey сделают ревью гарантий Redis и добавят Raft, например. Глядя на то, сколько народу наботает над проектом – это может случится скоро.

🤩Статья Павла Велихова «Стоимостной оптимизатор: сердце гибридной базы данных YDB» не то чтобы прям рассказывает о том, как конкретно в YDB реализован стоимостной (cost) оптимизатор запросов, но дает хорошее понимание, что это такое, и почему сложно, особенно для “универсальной” (аналитической и транзакционной) распределенной СУБД. Кост-оптимизатор — ключевой компонент, обеспечивающий эффективность выполнения как транзакционных (OLTP), так и аналитических (OLAP) нагрузок. В YDB оптимизатор учитывает стоимость различных операций, чтобы выбрать оптимальный план выполнения. Оптимизация запросов — NP-полная задача, требующая перебора множества вариантов, особенно когда при выполнении аналитического запроса нужно выполнить множество соединений таблиц. Об этих проблемах высокоуровнево, но очень доступно - в статье. Справка: YDB - открытая СУБД от Яндекса, разработка началась в 2012-м году, чтобы обеспечить не только масштабируемость, но и катастрофоустойчивость своих сервисов. В Яндексе и других бигтехах достаточно давно есть требование размещать все продукты в нескольких ДЦ и выдерживать отказ одного из ДЦ. Насколько оправдан этот подход для Яндекса - можно судить по последним новостям о выходе из строя одной из зон. Насколько оправдан этот подход вообще, а главное, для каких проектов - вопрос, как мне кажется, всё-таки пока дискуссионный.

На этом на сегодня всё. Если что-то интересное пропустил - пишите в комментариях! Всех с празником и хорошего воскресенья.

——
Наши ближайшие запуски: PostgreSQL 17: архитектура и тюнинг SQL, Highload-буткемп, Системный дизайн

Запись стрима с Валентином Бартеневым, Angie

https://www.youtube.com/watch?v=QeI5GMP4ukM&t=15s

Много поговорили про возможности Angie, отличия Angie от Angie PRO, прочую экосистему продуктов вокруг.

Ребята делают много всего, но если вам интеренсно, чем Angie лучше обычного nginx, то это:
🤩 мониторинг из коробки (есть веб-панель сбоку) вместо stub-status модуля
🤩 автоматическое получение сертификатов, поддержка ACME (кажется, владельцев vm-ок это задалбывает больше всего, так что я лично выберу Angie, а не заморский Caddy)
🤩 WASM (код на любом языке скомпилированный в WebAssemply и выполняемый директивой конфига)
🤩 пул аппликейшн-серверов (в разработке, хотя уже анонсировался на Хайлоаде).

Для тех, кто хочет больше подробностей:
🤩 https://angie.software/
🤩 https://angie.software/angie/docs/configuration/modules/http/http_acme/
🤩 Супер-свежая статья про WASM https://habr.com/ru/articles/898022/
🤩 Доклад Валентина на прошлом хайлоаде “PHP-FPM, (g)unicorn, Puma и uWSGI — будут больше не нужны”, есть презентация https://disk.yandex.ru/i/y_W7it4ACR92PQ
🤩 Маршрутизатор (SLB, GSLB) Angie ADC: https://angie.software/adc/ выпущен буквально пару недель назад

Хороших выходных!

Системный дизайн: проектирование социальной сети

Интересную фразу тут услышал: “не всё время же проектировать социальную сеть”. В том контексте, мол, что проектировать соцсеть неинтересно. Похожие дискуссии встречаются постоянно на хайлоаде, мол, зачем про это рассказывать - про это уже рассказывали.

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

Навыки, полученные при проектировании соцсети, применимы в других областях: e-commerce, мессенджеры, маркетплейсы и т.д. При проектировании соцсети всплывает миллион не только архитектурные проблем. Например, аутентификации и авторизация, безопасность личных данных, спам, боты, модерация. Даже систему аутентификации и авторизации сделать для по-настоящему большого проекта - очень большая задача. Новости, лента, stories, push-уведомления, realtime-события — всё это требует нетривиальных компромиссов между скоростью, ресурсами и UX. Так что проектируйте социальные сети, даже для собственной прокачки, это интересно.

А кто хочет потренироваться в группе - в следующие три дня последний шанс запрыгнуть на наш курс по системному дизайну хайлоад-проектов по текущей цене, за 3 месяца живых еженедельных созвонов – такой цены больше не будет. Ну а для тех, кто не боится консоли, есть хардкорный буткемп с linux, нагрузочным и кластерными решениями.

Стартовали, приходите!

live-stream сегодня в 18:00 MSK - роадмэп и экосистема Angie (клон nginx), и как это всё вписывается в современный микросервисный cloud/mesh контекст. Трансляция где обычно: https://www.youtube.com/@AlexeyRybak/streams

Делюсь презентацией и видео со вчерашнего стрима, где мы с Колей Ихалайненом выжали 1млн запросов из PostgreSQL и смотрели за этим безобразием в PMM (Percona Monitoring and Management).

https://www.youtube.com/watch?v=2heCzWHoXDI&t=60s

——
Ближайшие запуски Devhands: PostgreSQL 17: архитектура и тюнинг SQL, Highload-буткемп, Системный дизайн.

стартуем уже через 20 минут, приходите
https://www.youtube.com/@AlexeyRybak/streams

PostgreSQL: 1.000.000 RPS challenge + демо PMM (Percona Monitoring and Management)

Уже завтра, во вторник, 15-го апреля в 18:00 мы с Николаем Ихалайненом проведём открытое демо нагрузочного тестирования PostgreSQL и PMM, мониторинговой утилиты от компании Percona.

В прошлом году мы провели большое исследование, выжимая 1.000.000 RPS из наиболее популярных key-value и SQL СУБД и сервисов, и убедились, что все они в состоянии отдать около миллиона запросов в секунду при достаточно большом числе одновременных соединений. Во вторник мы повторим часть этого тестирования онлайн, без регистраций и смс. Подадим разную нагрузку на PostgreSQL, в том числе выжмем снова из него миллион запросов, и посмотрим, какую интересную аналитику сможет предоставить pmm.

Перед демо я покажу основные результаты прошлогоднего исследования и его выводы. Расскажу, куда “упирался” PostgreSQL при проводимых ворклоадах, какие были latency, и как примерно прикинуть, при каком количестве одновременных соединений PostgreSQL перестанет нормально работать без баунсера.

🤩 Как попасть
Стрим будет проходить там же, где обычно - на моем Youtube-канале: https://www.youtube.com/@AlexeyRybak/streams.

Мероприятие можно добавить себе в календарь
🤩 Google
🤩 Apple
🤩 ICS

До встречи во вторник

——
Ближайшие запуски Devhands: PostgreSQL 17: архитектура и тюнинг SQL, Highload-буткемп, Системный дизайн.

Паттерны неинвазивной починки интеграций

Принял участие сегодня в публичном интервью в рамках техлидского стрима Подлодки. Позвал меня на это действие и сделал всю подготовку Виталий Лихачев. Я был “со-интервьюером”, но по факту был очень необычный кейс, детали которого я видел впервые и поэтому пришлось “въезжать” в этот кейс просто на ходу.

Задача: есть готовая интеграция различных сервисов умного города. Нужно починить ряд проблем. Максимально “неинвазивным” методом, то есть с минимумом вмешательства в интегрируемые сервисы. Задача, типичная для больших “развесиситых” компаний, интеграторов, B2B. Что было особенного: вместо того, чтобы идти по привычному сценарию tabula rasa от сбора требований, была уже готова схема продуктов и интеграций с проблемами, которые нужно было расковырять и предложить решения.

Прошлись по многим болям интеграций. Не готов формулировать в терминах устоявшихся “паттернов”, поскольку такой список мне неизвестен - об этом и пост. Простыми словами это всё про: снижение нагрузки через промежуточные кеши либо релеи, плавная подмена запросов при изменении контрактов, решение проблем задваивания и обеспечение идемпотентности.

Как будто бы “паттерны микросервисов”, которые на слуху и активно пиарятся как обязательное знание, они в целом не для “неинвазивных” интеграций (все эти circuitbreaker, bulkhead, abmassador, sidecar и тд). И как будто должны существовать отдельный список паттернов, так и класс интеграционных подсистем, задача которых – повысить обзервабилити и снизить боли при интеграциях, когда наши возможности влезть вовнутрь интегрируемых сервисов крайне ограничены.

Знаете такие паттерны? Будет здорово их собрать. Любые идеи, книжки, статьи, доклады - пишите, пожалуйста, в комментарии.

🔥И кстати: большое спасибо всем, кто комментируют, я просто офигеваю от качества дискуссий тут в каментах.

----
Ближайшие запуски Devhands: PostgreSQL 17: архитектура и тюнинг SQL, Highload-буткемп, Системный дизайн.

Очереди в 2025м, что выбрать: Kafka, RabbitMQ, NATS или что-то ещё?

Готова статья-расшифровка нашего стрима с Владимиром Перепелицей. Она получилась очень длинная, никогда в жизни такого на Хабре ещё не публиковали, но это потому что видео длинное. Ну и просмотреть расшифровку всё быстрее, чем просмотреть видео.

Для затравки вот кусочек статьи, где Владимир критикует RabbitMQ.

Алексей Рыбак: Где “накосяпорили” разработчики Rabbit, что скейлинг настолько неудобный? В двух словах это можно каким-то образом описать?

Владимир Перепелица: Смотри, мое личное впечатление от Rabbit, где накосячили его разработчики.
Взяв Erlang, они не сделали архитектуру масштабируемой, при том, что Erlang вроде бы под это заточен, он должен уметь раскидывать все по разным хостам, но они под это не заточили всю систему. Они не сделали систему, как в Kafka, докинул брокеров, раскидал на них задачи и система тащит больше. То есть они предусматривают, что у тебя есть узел, вот он брокер, все, у тебя все задачи проходят через этот брокер. Ты можешь поставить запасной, ты можешь поставить реплики, но они тоже будут запасными.

Алексей Рыбак: Я не могу сделать proxy-брокер?

Владимир Перепелица: Ну, можешь.

Алексей Рыбак: Взять и сказать, типа, раунд-робином давай кидай на этот апстрим.

Владимир Перепелица: Это все сделано костылями. Там есть федерация, через которую можно это все раскидывать. Я пока в курсе был Rabbit, то есть хотел показать, как бы это можно масштабировать так, чтобы красиво. Красиво не получилось. А показывать гору костылей как-то не очень. То есть, в общем, из коробки, вот прям поставил кластер, и он у тебя скейлится. Этого нет. Да, сделать это можно, но это, опять же, уже что-то добавленное сбоку, расширениями, не всегда просто устанавливаемыми. И странно, при том, что сама платформа языковая, кажется, это могла бы дать.

Ну и вторая ошибка – это, собственно, да, выбор платформы. Дефицит разработчиков всегда сказывается на популярности инструмента. То есть найти Erlang-разработчика – это такой, скажем так, челлендж, который еще захочет поинвестировать свое личное время, потому что это open-source. Гораздо проще сейчас найти GO'шный или RUST'овый open-source, или Java'вый, собственно, Kafka – тому пример. Java у нас много. Ее можно недолюбливать, у нее есть куча проблем, но она чертовски популярна. Поэтому выбор Erlang как инструмента, скажем так, скорее затормозил его развитие. И сейчас, если человек приходит, смотрит, возможно, пытается что-то улучшить, такой: «Ой, там что-то, что сейчас не популярно», человек уходит.

Читайте полную версию на Хабре: https://habr.com/ru/articles/899670/

——
Наши ближайшие запуски: PostgreSQL 17: архитектура и тюнинг SQL, Highload-буткемп, Системный дизайн.

Встреча с Валентином Бартеневым, главой разработки Angie (сертифицированный российский форк nginx)

Ребят, на следующей неделе сабж - посмотрите, пожалуйта, накидал темы, вдруг вы предложете ещё какие-то интересные свои. Встреча вечером в четверг 17-го апреля, онлайн. Анонс со ссылками будет чуть позже.

Темы встречи с Валентином:
🤩Эко-система веб-серверов, основные вызовы для современных “серверов”, облачная и CI/CD конъюнктура, mesh, балансировка, управление сертификатами. Как “отстал” nginx, почему рванули envoy и другие. Что Angie делает, чтобы не отставать.
🤩Основные “фишки” эко-системы Angie, которых нет в nginx: балансировка, интеграция acme api / let’s encrypt, интеграция с промстэком, WASM, эмбеддинги других ЯП.
🤩Компания на open source продукте, модель. Как ищется баланс между бесплатным и платным. Платная версия: что умеет, кто покупает. Тренд на “анти-облачные” лицензии.

🔥 если всё нравится, ну и дополняйте темы в каментах

——
Наши ближайшие запуски: PostgreSQL 17: архитектура и тюнинг SQL, Highload-буткемп, Системный дизайн.

Пришел сегодня в Сколково на DevOpsConf - а там сисадмины и клауд-провайдеры!

Ещё книжка по постгресу бесплатно, важная статья Е.Дюкова (YandexCloud) про Valkey

На прошлой неделе как ни странно было мало достойных новостей. PostgresPro выпустили очередную бесплатную книжку, “PostgreSQL. Профессиональный SQL” (Евгений Моргунов).
Информация о книге: https://postgrespro.ru/education/books/advancedsql
PDF: https://edu.postgrespro.ru/advanced_sql.pdf
Обратите внимание, что PostgresPro распространяет также образ виртуальной машины VirtualBox, который можно поднять у себя локально, и у вас будет собственный 17й PostgreSQL. Напомню, что если Вы хотите более интенсивного обучения, то возможно вам будет интересен наш курс по архитектуре итюнингу SQL для PostgreSQL, мы как раз собираем очередную группу. И сервер при этом выдаём настоящий, облачный, самим ничего поднимать не нужно.

А ещё вышла наконец статья Евгения Дюкова (YandexCloud) про Valkey:
https://habr.com/ru/companies/oleg-bunin/articles/893680/
Эволюция Redis в Valkey 8.0: разбираем архитектурные изменения с точки зрения производительности

Это статья – пересказ доклада с зимнего Хайлоада. Что важно в этой статье: это фактически чуть ли не единственная статья на русском языке, в которой достаточно подробно описана архитектура Redis, и что конкретно было сделано в Valkey. Напомню, что он формально многопоточный, но работает по схеме main thread + io threads, и это его “родовая” травма, которая определяет его слабый скейлинг по CPU.

Так же в статье приводится бенчмарк сравнение с Redis 6 и Redis 7. И вот этот бенчмарк выглядит как, мне кажется, странно. По этому бенчмарку кажется, что Valkey лишь слегка опережает Redis. Возможно, приведена одно-ядерная конфигурация (мы получали цифры в 160K на Xeon Gold 6312U в одно-ядерных режимах, и эти 160K RPS похожи на то, что в статье). Хочу напомнить, что в наших тестах с 8 io-threads и достаточном количеством свободных ядер Valkey выдавал производительность примерно 1.000.000 RPS, в то время как Redis - меньше 400.000 RPS. Разница примерно в 2.5 раза! Я попытаюсь связаться с Евгением и узнать про условия именно этого тестирования.

Вообще, мы давно не тестировали на производительность новые версии Valkey и Redis, поэтому на следующей неделе проведем открытое демо, где постараемся показать миллион запросов в секунду в режиме реального времени, а так же посмотрим, что смогут Valkey и Redis в кластерном режиме. Но об этом вскоре будет отдельный анонс в предверии старта нашей якорной программы с кластерной практикой.

——
Ближайшие запуски Devhands: PostgreSQL 17: архитектура и тюнинг SQL, Highload-буткемп, Системный дизайн.

Типология программистов

Антон Поваров, с которым мы сто лет проработали вместе в Badoo/Bumble, напомнил мне в комментариях мой же давнишний пост. В Телеге пост не публиковался, но он стоит того, чтобы скопировать его сюда хотя бы частично.

Итак, типология программистов глазами стартапера. Внимание! Присутствует ненормартивная лексика.

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

1) Тупой программист: в горы? ну значит в горы.
2) Всех заебавший программист: какие нахуй горы ебаныйврот! ну какие ещё нахуй в пизду блядь горы вы под стол блядь ходить научитесь а они уже в горы блядь долбоебы блядь. В горы они собрались олухи блядь. Пидарасы блядь.
3) Старый программист (про себя): гоооры... вот ведь блядство. затем, обращаясь к манагеру (ну или кому там) - голосом, как разговаривают с румяной пятнадцатилетней соседкой: друг мой, а что мы собираемся делать в горах? как долго? какие у нас будут горы? высокие? низкие? какие погодные условия?
4) Угарный программист поворящиваясь к монитору, открывая vim, занося руки над клавой как моцарт, с взъерошенниыми волосами, в пол-оборота оглядываясь с ухмылкой: Итак, нарисуем горы v0.1 ...

В команде с двумя последними работать - и эффективнее, и куда приятнее. Заметьте - в подавляющем большинстве случаев вам будет абсолютно наплевать, умеет ли ваш коллега за пять минут в незнакомой и напряженной атмосфере делить двенадцать монет тремя взвешиваниями, или нет.

––––––––––––––

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

Запись стрима по очередям готова! Обсудили Владимиром Перепелицей:
🤩 Что нового в 4й кафке?
🤩 Что такое рафтизация, tiered storage и почему это супер-важно
🤩 Насколько уже “зрелый” NATS, с кем он в первую очередь конкурирует - с RabbitMQ или c Кафкой?
🤩 Где накосячили разработчики RabbitMQ?
🤩 Насколько стандартно использование Кафки в качестве primary/first storage и для каких классов систем это ОК?

https://www.youtube.com/watch?v=2vSj-HHu-wo

Ребят, Владимир - человек с уникальной экспертизой, и всего 2-3 раза в год он читает у нас интенсив по очередям Kafka и NATS. Этот курс системно получает самые высокие отзывы - и 8-го апреля у нас старт очередного потока. Приходите, получите кучу полезной информации. Считаю этот интенсив обязательным для всех, кто интересуется очередями, распределденными системами, гарантиями и надежностью в микросервисных системах.

Сегодня в 18:00 MSK ждём всех на открытую встречу Devhands: выбор брокера и системы очередей в 2025м.

Kafka, Rabbit, NATS или что-то ещё?

Своро выясним! Уже через час начнется очередная открытая встреча Devhands.

У меня в гостях будет Владимир Перепелица, эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload.

Будем обсуждать:
- выбор брокера и системы очередей 2025м году, что поменялось?
- NATS, его особенности, перспективы, кого он “подвинет” в первую очередь, Kafka или RabbitMQ?
- что нового в свежей Apache Kafka 4?
- насколько популярны архитектуры, где, например, Kafka основной storage (IoT, сбор метрик и тд)

Бесплатно, без регистрации и sms:
https://www.youtube.com/@AlexeyRybak/streams. Запись будет - там же в стримах.

Приходите, будет интересно.

Неструктурированные мысли про стартаперство.

Смотрите какие золотые слова. Слышал эту мысль давно, но у Табунова получилось очень емко и кратко: “В любом проекте регулярно кто-то ебланит. Если тебе кажется, что не ебланит, значит ебланишь ты.”

Стартапы не любят, потому что если стартап нормальный, то там нельзя сесть ровно на жопе и сидеть так годами. Но вообще “стартаперский” вайб куда-то уходит.

Бигтехи полны “аналитиков”. Програмисты ждут ”формальных описаний”. Аналитики считают, что их описания – “гарант независимости от программистов”. Как только появились аналитики, некоторые продакты стали “стратегами“ - все детали аналитик распишет. Хотя продакт на то и продакт, чтобы с дизайнером придумать продукт. А не написать несколько строчек сторей, и куда-то отдать их голубиной почтой в “нижний мир”. И только спрашивать туда регулярно: “алё, внизу, в нижнем мире! ну чё, ребзя, скоро сделаете”? Аналитики теперь считают, что это они должны уметь в системный дизайн. Тестировщики намертво встраиваются в пайплайн и добрую половину времени задача теперь проводит в тестировании, на тестировщиках. NoQA звучит примерно так же как массовые сокращения. Про фронт вообще писать не хочу.

Важнейший софт-скилл - уход от ответа на вопрос “скоро сделаете”. Вообще, этот вопрос неприличный. Сроки – это давление и фашизм, а наука давно доказала, что мотивация внутренняя должна быть, а не внешняя.

Вообще кто-то должен всё это организовать, это же ваша работа, а моя работа – программировать. Вообще, может у вас мудак СТО? У нормального СТО такой херни не бывает!

Объективно много организационных задач. Значит нам нужен проджект. Так, нет, проджект – это нафталин вотерфолл. У нас не проджекты. У нас – “деливери-менеджеры”.

Чтобы сделать классный продукт теперь нельзя просто собрать условную “пицца-тим”. Мамбу сделали 5 человек. Баду сделали 15 (но там сначала продали Мамбу, так что денег было побольше). А если денег на 5 человек - забудь. Хочешь 5 фуллстэков? Хрен там: будет два бекендера, один фронт, один мобила андроед и один айос. На тестировщиков не хватит. Если любой из этих 5 заболел, запил, уволился - ты отстал на недели.

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

Devhands Open Session:
Как выбрать систему очередей в 2025-м: Kafka, RabbitMQ, NATS или что-то ещё?

3-го апреля в четверг в 18:00 мск

Пройдет очередной открытый онлайн-митап Devhands Open Sessions.

Будем обсуждать:

🤩 Выбор брокера или системы очередей 2025м: что поменялось?
🤩 NATS, его особенности, перспективы, кого он “подвинет” в первую очередь — Kafka или RabbitMQ?
🤩 Что нового в свежей Apache Kafka 4?
🤩 Насколько популярны архитектуры, где, например, Kafka основной storage (IoT, сбор метрик и тд)

🤩 Гость — Владимир Перепелица, эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload.
Ведет беседу — Алексей Рыбак (devhands.io).

Узнаете тренды, чему и как учиться в 2025, сможете напрямую спросить эксперта все интересующие вас вопросы.
Для разработчиков, архитекторов и devops-инжереров.

Ссылки для добавления в календарь:

🤩 Google
🤩 Apple
🤩 ICS-файл

Приходите, будет интересно.

Радар Devhands: выпуск 30-го марта 2025

🤩 IngressNightmare: 9.8 Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX
На прошлой неделе самой громкой новостью было обнаружение IngressNightmare. Это уявзимость класса zero-day, т.е. необходимы мгновенные шаги по устранению. Уязвимость позволяет с большой долей вероятности получить доступ ко всему кластеру через балансер.

По сообщению wiz.io уязвимы 40% облачных кластеров, в которых используется Ingress NGINX Controller for Kubernetes, один из самых популярных ingress controllers и часть экосистемы Kubernetes с 18000 звездами на гитхабе. Сама уязвимость – это RCE (remote code execution), но состоит из последовательность шагов.

Общий сценарий настолько захватывающий, что всем интересующимся рекомендую посмотреть статью wiz.io, они подробно всё расписывают. Если очень кратко: у злоумышленика уже должен быть доступ к сети атакуемого кластера, сначала посылается специальный запрос к nginx размером больше 8к, который приводит к сохранению тела файла на диск. Во внутренней сети можно грузить безо всякой авторизации. Ну и грузим на диск shared library раз такое дело.

А параллельно составляется специальный запрос к основной фиче обновления конфигов ingress: трансформировать некоторую ingress-конфигурацию в nginx-конфиг. Только вот из-за недостаточной валидации можно подать запрос, который приводит к неверному конфигу nginx с injection, который затем тестируется через nginx -t и в этот момент если сделать инъекцию ssl_engine, то происходит загрузка shared library, которую предварительно залили через запрос размеров 8+K.

🤩 It's five grand a day to miss our S3 exit
Сага cloud exit (побеге 37 signals из AWS) продолжается. Сейчас упомянуто, куда они переезжают. Они взяли вендора Pure Storage (https://www.purestorage.com/). Pure Storage comes with an S3-compatible API, so no need for CEPH, Minio, or any of the other object storage software solutions you might need. То есть они взяли вендора, который втаскивает им всё онпреп-решение вовнутрь сам. А ещё это мотивирующий пост от DHH: каждый день нам приносит $5000 экономии, так что, чуваки, не затягивайте сроки.

🤩 Introducing DuckDB
Если ты дата-саентист, то скорее всего пишешь на питоне. Если ты вдруг не слышал о embedded подходе к обработке и о DuckDB - то тебе уже и туториал сделали.
DuckDB — это встраиваемая OLAP-база данных, оптимизированная для быстрых аналитических запросов на больших данных. В отличие от традиционных СУБД, она работает внутри приложения без отдельного сервера, что делает её удобной для интерактивного анализа и встраивания в конвейеры обработки данных. DuckDB использует колоночное хранение, векторизированное выполнение и автоматический параллелизм, обеспечивая высокую производительность на современном оборудовании. Она решает проблемы медленных аналитических запросов в классических СУБД, сложности развертывания OLAP-систем и неэффективной работы с большими данными в Python, R и других средах.

🤩 Lua в Nginx: динамическая маршрутизация запросов
Годная статья-сборник рецептов lua nginx - фактически сборник фич, которых не хватает nginx (и причин, по которым в облачном окружении вместо nginx что-то ещё). Как я понимаю, почти всё взято из материалов OpenResty (https://openresty.org), но достаточно компактно, в одном месте и по-русски.

🤩OpenStack на автопилоте: GitOps-подход к созданию виртуальных машин
Еще февральская статья Yadro - несмотря на мудреное название - про то, что из себя представляет OpenTofu (замена Terraform), хотя и посвящена созданию виртуалок в OpenStack.

🤩 Я устал возиться с кучей VPN и поставил Xray на роутер
Подробная инструкция для всех гиков, которых задолбало объяснять домашним, как смотреть на YouTube через VPN новости Собчак или школьные туториалы.

Будь в курсе новостей разработки вместе с Devhands.
Еженедельно мы просматриваем сотни источников и выпускаем в Телеграме дайджест публикаций, чтобы вам было что почитать на выходных. Тренды, новые релизы, перспективные проекты, обсуждения с экспертами. А ещё у нас есть отличное обучение.

Радар Devhands, спецвыпуск. Самое инересное с P99

Хотел сделать обзор основных докладов с недавнего Monster Scale Summit, но как будто там не было ничего настолько яркого, как на P99. А вот как раз в марте организаторы выложили довольно много материала на YouTube. И поскольку обзора P99 я не делал, я решил поделиться с вами тремя на мой взгляд важными выступлениями: Майкла Стоунбрейкера, Энди Павло и Керри Осборна.

За 3 недели у всех видео невысокое количество просмотров, количество лайков, что в целом конечно говорит и о качестве аудитории, и о маркетинге организаторов - но не обращайте на это внимания, доклады - золото, особенно первый.

🤩 The Next Chapter in the Sordid Love/Hate Relationship Btwn DBs & OSes // Andy Pavlo (Carnegie Mellon University)
https://www.youtube.com/watch?v=vD-0dw4gUhw

Это доклад стоило назвать “как eBPF может помочь базам данных”, но вообще там космос. Фокус делается отдельно на stateless (прокси-пулеры-баунсеры) и stateful (собственно субд) приложения. В лаборатории Павло сделали два прототипа, в докладе рассказывается что сделано и какие результаты. По прокси это продукт под названием Tigger, форк баунсера с оптимизациями, в сравнении и с оригинальным баунсером, и с Yandex Odyssey (про который кстати Павло отозвался позитивно) - работает быстрее. Коллеги из Яндекса, если вы друг пропустили - посмотрите. По СУБД - они сделали проект BPF-DB и позиционируют его как потенцильный сторадж-бекенд для более сложных СУБД. Там внутри прям кернел-матан, они сделали прототип и ресерч, очень похожий на то, что мы в devhands сделали в 2024м году: сравнили performance KV решений со своим, Redis, KeyDB, Dragonfly, BPF-DB. Посмотрите, если интересно, там сюрприз, там супер-круто выглядит Dragonfly. Valkey и Memcached там нет.

🤩 You’re Doing It All Wrong // Michael Stonebraker (MIT)
https://www.youtube.com/watch?v=Rzwift2iJlM

Этот доклад - промоушен проекта Стоунбрейкера DBOS, эдакий “Temporal на хранимках, только хранимки на js или питоне”. Доклад интересен в любом случае – тем, что это Стоунбрейкер. Тем, как он смотрит на проблему workflow, конситенстности, саг. Что предлагает для решения и что считает важным. Некоторые утверждения спорны, но в целом не снижает ценности. Из него я кстати узнал про Firecracker, потому что в нашем облаке старт vm за секунды стоит супер-остро (и мы эту задачу пока не решили).

🤩 How to Improve Your Ability to Solve Complex Performance Problems // Kerry Osborne (Google)
Part 2: https://www.youtube.com/watch?v=vvDnaISGCPI
Part 1: https://www.youtube.com/watch?v=F57m48x4OZ0 (это 2023, “предыстория”)

Доклад про то, как работают люди в области тюнинга производительности. Совсем не технологический доклад, но на супер-важную тему: что за функция мозга “умение решать сложные проблемы”, как её прокачивать. Интуиция и Анализ, две системы мышления, что и когда лучше работает. Какие упражнения могут помочь задействовать “дополнительные способности” мозга. Докладчик работает в группе производительности СУБД, он конечно бьет просто в точку: in performance tuning world there’s a lot of pressure. Так что ещё одна из тем это адреналин/кортизол, какие техники могут уменьшить влияние гормонов на способность думать в стрессовой ситуации. Здорово было бы конечно им коллаборацию с нейрофизиологом. Но в целом Music beats Valium, я согласен. Вообще, Music is the best, как говорил Заппа.

Enjoy! Новости тоже выпустим, но позже, хотелось бы поглубже разобраться, что за косяк посадили в nginx ingress, что дошло аж до 0-day IngressNightmare.

Раз в месяц будем постить анонсы по обучению на будущий месяц. Чтобы вы или ваши команды могли всё спланировать. Кстати, для физиков: если приводите друга, у нас теперь есть постоянная скидка 20% обоим.

Итак, наши старты в апреле.

🤩 1-го апреля: 🔥last call! 🔥Михаил Курмаев, “Производительность и наблюдаемость бэкенда. Поиск проблем в продакшене”. Практически курс по сбору метрик бекенда, разбор серверных архитектур бекенда, знакомство с телеметрией, инструментами Prometheus/Grafana, SigNoz, Pinba.

🤩 8-го апреля: Владимир Перепелица, “Интенсив по очередям: Kafka и NATS”. Практика использования очередей, включая архитектуру, свойства, гарантии и практический разбор пограничных кейсов, намеренного вывода из строя части кластера и реакции систем на аварии.

🤩 15-го апреля: Алексей Рыбак, “Производительность и масштабируемость”, “Системный дизайн высоконагруженных проектов”. Хадкорный хайлоад-курс с обширной практикой на инфре, и “облегченный” версия с теорией и проектированием “у доски”. Маштабирование всех слоёв приложеия, шардинг, кластерные решения, CAP/PACELC и вот это всё.

🤩 24-е апреля: Николай Ихалайнен, “PostgreSQL 17: архитектура и тюнинг SQL-запросов”. Курс, сочетающий фундаментальную теорию и практику, архитектура СУБД вообще и PostgreSQL в частности, типы и особенности индексов, MVCC, ваккума, типы SQL и практический алгоритм использование EXPLAIN для оптимизации запросов.

Приходите сами, приводите друзей! Все курс с практикой, преднастроенную инфру выдаем на всё время курса.

Пушкин и предвосхищение AI

Позвольте мне разбавить вам ленту гуманитарным.

Работая с ChatGPT, постоянно вспоминаю цитату из неоконченной пьесы Пушкина “Египетские ночи”. Кто по собственной воле мог читать эту пьесу? Я её не читал. Я знаю её по великому фильму Михаила Швейцера “Маленькие трагедии”. Если вы его смотрели – тогда вам тоже известен сюжет. Хотя в фильме сюжет передан не совсем точно.

Для всех остальных. Сюжет такой. Поэт Чарский знакомится с итальянским импровизатором. Импровизатор – это такой стихотворец, который на любую тему, без всякой подготовки, не делая и не имея перед собой каких-либо заметок, может сочинить и продекламировать стихотворение. На любую тему. Без всякой подготовки. Как на рэп-баттле, только темы совсем не для дебилов.

Короче, Чарский устраивает “квартирник”, на котором импровизатор демонстрирует своё искусство. А предварительно Чарский проводит “закрытое тестирование” способностей своего нового знакомого. Он предлагает ему импровизацию на давно занимающую его тему «поэт и чернь».

Итальянец безо всякой подготовки так мощно качает, что Чарский молчит, “изумленный и растроганный”. Далее идёт диалог:
— Ну что? — спросил импровизатор. Чарский схватил его руку и сжал ее крепко.
— Что? — спросил импровизатор, — каково?
— Удивительно, — отвечал поэт. — Как! Чужая мысль чуть коснулась вашего слуха и уже стала вашею собственностию, как будто вы с нею носились, лелеяли, развивали ее беспрестанно. Итак, для вас не существует ни труда, ни охлаждения, ни этого беспокойства, которое предшествует вдохновению?.. Удивительно, удивительно!..

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

Microservices Thoughts (Александр Федькин, Яндекс)

В Телеге есть несколько каналов с регулярным, полезным, оригинальным контентом.

🤩 Один из самых крутых каналов для разработчиков, которые интересуются архитектурой, хайлоадом, базами данных, сервисами и микро-сервисами - канал Александра Федькина из Яндекса, называется “Microservices Thoughts” https://t.me/MicroservicesThoughts.

Александр публикует посты либо обще-развивательного характера, либо про разного рода паттерны и тонкости, которые не лежат на поверхности, но понимание которых прокачивает и развивает.

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

🤩Потери данных в Redis https://t.me/MicroservicesThoughts/94
🤩Geohash https://t.me/MicroservicesThoughts/98
🤩Верхнеуровный принцип работы полнотекстового поиска https://t.me/MicroservicesThoughts/110
🤩Tail latency и hedged запросы https://t.me/MicroservicesThoughts/117
🤩Где может помочь Circuit Breaker https://t.me/MicroservicesThoughts/108
🤩Про что подумать, когда пишете свой outbox https://t.me/MicroservicesThoughts/125
🤩Как искать боттлнеки https://t.me/MicroservicesThoughts/115
🤩Как чему-то учиться https://t.me/MicroservicesThoughts/111

👍🏻 Лайк – если понравился контент.
🔥 Огонь – если уже подписан на Microservices Thoughts.

Делюсь записью стрима с Михаилом Курмаевыем (21 марта).
Тема встречи: Телеметрия и стандарт Open Telemetry, состояние, боли, перспективы.

🤩 https://www.youtube.com/watch?v=dCvf1OvMxs8

Встреча чуть больше часа, на скорости 1.5 можно прослушать основное за сорок минут.

Таймлайн (есть в комментариях к видео):
🤩 01:17 Observablity: что это, и почему это не просто собрать логи/метрики/трейсы. Observability как Путь.
🤩 05:00 Кто в компании отвечает за Observability? Классический подход SRE и секретный соус наблюдаемости.
🤩 10:50 Cтандарт OpenTelementry. Из чего состоит. Вчера, сегодня, завтра, развитие и внедрение стандарта.
🤩 22:23 На github 80 репозиториев, что там? Demo-франкенштейн астрономического магазина.
🤩 24:33 Обсуждение бекендов, standalone signoz, honeycomb cloud.
🤩 26:03 Действительно ли мы в начале пути? Что ещё предстоить решить?
🤩 30:33 Родовая травма OpenTelemetry: перфоманс. Что делают компании, чтобы обработать громадные потоки данных. Грубая оценка предельных пропускных способностей одной бэкенд-ноды телеметрии.
🤩 43:43 Как изучать инструменты телеметрии, какая практика на курсе у Михаила?
🤩 48:23 Troubleshooting кейсы из практики Михаила
🤩 54:33 Сбор перфоманс данных: особенности и боли сбора, насколько Otel-стэк готов для перехода, являются ли текущие трудности фундаментальными.
🤩 1:06:30 Вопросы

Enjoy!

И сразу тизер: следующая встреча будет с нашим экспертом по очередям, Владимиром Перепелицей, темы встречи - Kafka 4 и Kafka vs NATS.

Радар DevHands: выпуск 22 марта 2025

🤩Вышла Apache Kafka 4.0!
https://www.confluent.io/blog/introducing-apache-kafka-4-0/
Теперь Kafka по умолчанию работает без Apache ZooKeeper (технология KRaft), упрощая развертывание и управление, повышая масштабируемость и снижая операционные издержки. Введен поднабор допустимых реплик, синхронизированных с ведущим, которые гарантированно содержат все данные до отметки высокого уровня, обеспечивая более безопасные выборы лидера и предотвращая потерю данных. Механизм предварит
ельного голосования позволяет узлам проверять свою пригодность для лидерства перед запуском выборов, сокращая ненужные выборы лидера KRaft и минимизируя перебои, вызванные сетевыми разделениями или временными проблемами. Новый протокол групп потребителей (counsumer groups) повышает эффективность ребалансировки, сокращает время простоя и задержки, а также улучшает надежность потребительских групп, особенно в крупных развертываниях. Фреймворк логирования был перенесен с Log4j на Log4j2 (больше возможностей и производительность)

🤩На сайте Postgres Professional можно свободно скачать очередное издание книги Егора Рогова «PostgreSQL 17 изнутри» 
https://postgrespro.ru/education/books/internals

🤩Инженеры Skyscanner пишут про то, как меняли свой подход к Observability.
https://medium.com/@SkyscannerEng/skyscanners-journey-to-effective-observability-655167a49d2f
В 2020 году Skyscanner провел масштабное обновление своей платформы наблюдаемости, чтобы повысить надежность системы и упростить работу инженеров. Прежняя инфраструктура состояла из разрозненных инструментов и поставщиков, что усложняло управление затратами и снижало эффективность. Для реализации этих задач компания внедрила OpenTelemetry и выбрала New Relic в качестве основного хранилища данных. Пишут, что упростили операции, изменили культуру работы инженеров, улучшиши качество наблюдаемости и, конечно, пользовательский опыт (куда без него).

🤩Вышла Java 24: накопители (gather) в Stream API, меньше размер JDK, подготовка к строгому ограничению использования JNI и др.)
https://habr.com/ru/companies/tbank/articles/891798/

🤩И (почти вышел) .Net 10:
Унификация .NET, улучшение в GC/JIT/AOT и др.
https://devblogs.microsoft.com/dotnet/dotnet-10-preview-2/


🤩Defining a Great Engineering Culture
https://mgrebler.substack.com/p/defining-a-great-engineering-culture
Очередной обзор, можно использовать как шпаргалку для анкетирования (внутри, сторонний аудит):
🤩 у нас есть понятные общие ценности и принципы?
🤩 мы все находимся в психологической безопасности?
🤩 мы стремися к высоким стандартам и техническому совершенству?
🤩 у нас осуществляется сотрудничество и обмен знаниями?
🤩 насколько самостоятельны команды?
🤩 происходит ли непрерывное улучшение хотя бы методом регулярного задавания вопроса “а не херню ни я делаю”?
🤩 насколько наши задачи соответствуют бизнес-целям?

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

Привет! Через 30 минут начинаем стрим с Михаилом Курмаевым про observability и open telemetry.
Стримим на YouTube: https://www.youtube.com/@AlexeyRybak/streams

Открытая встреча по Open Telemetry, пятница 21 марта 18:00 МSК

🤩 Друзья, уже в эту пятницу 21 марта 18:00 МSК состоится очередная открытая встреча DevHands. На этот раз в гостях будет Михаил Курмаев (Т-Банк), мы обсудим стандарт Open Telemetry.

Программа насыщенная:

🤩 Технологии и внедрение. Что такое OpenTelemetry и почему это важно. Ключевые компоненты: трассировки (Traces), метрики (Metrics), логи (Logs). Связь с CNCF (Cloud Native Computing Foundation) и экосистемой наблюдаемости. Как компании внедряют OpenTelemetry. Лучшие практики интеграции OpenTelemetry в существующие приложения. Примеры успешного внедрения.

🤩 Инструменты. Инструменты, поддерживающие OpenTelemetry (Jaeger, Prometheus, SigNoz, Elastic Stack и др.). OpenTelemetry SDK для различных языков программирования. Независимые решения vs. решения от поставщиков.

🤩 Вызовы. Нагрузка на производительность из-за инструментирования OpenTelemetry. Работа с распределёнными трассировками в облачных и мульти-облачных средах. Вопросы безопасности и соответствия требованиям регуляторов. Управление крупными объёмами телеметрических данных.

🤩 Будущее. Новые возможности и планы по развитию. Как OpenTelemetry изменит наблюдаемость в ближайшие пять лет. Q&A-cессия (вопросы/ответы).

Будет стриминг в YouTube: https://www.youtube.com/@AlexeyRybak/streams.

Ссылки для удобного добавления в календарь
🤩 Google
🤩 Apple

🤩В рамках стрима Михаил также расскажет про свой курс, “Производительность и Наблюдаемость бэкенда. Поиск проблем в продакшене”.

Zoom-комната будет для участников программ Devhands

QA-сессия с Мартином Клеппманном и Крисом Риккомини

Вместо выпуска новостей, который обязательно состоится, но позже, делюсь содержанием и ссылкой на 30-минутную Q&A-сессию с Мартином Клеппманом и Крисом Риккомини. Это они сейчас пишут “второго кабанчика”.

- Мартин Клеппман - автор Designing Data-Intensive Applications. Исследователь в области распределённых систем и безопасности в Кембриджском университете. Ранее работал инженером-программистом и предпринимателем в интернет-компаниях, включая LinkedIn и Rapportive, где занимался разработкой инфраструктуры для обработки данных в больших масштабах.
- Крис Риккомини - соавтор The Missing README. Инженер-программист, инвестор в стартапы и консультант с более чем десятилетним опытом работы в крупных технологических компаниях, таких как PayPal, LinkedIn и WePay. На протяжении всей своей карьеры он активно участвовал в развитии open-source проектов, является автором Apache Samza, сейчас работает над SlateDB
- Беседу модерирует Цах Ливятан, VP of Product в ScyllaDB
Темы: 2-е издание «кабанчика» Designing Data-Intensive Applications, эволюция систем управления данными, влияние облачных технологий и будущие тренды.

Саммари составил ChatGPT (а DeepSeek провалил тест, “абсолютно, совершенно, херня полная” IYKWIM).
https://www.youtube.com/watch?v=T-d1wR7adB8

Сотрудничество Мартина и Криса
• Мартин и Крис познакомились в LinkedIn в 2013 году, работая над Kafka и Samza.
• Мартин начал писать Designing Data-Intensive Applications во время работы в LinkedIn, а затем покинул компанию, чтобы сосредоточиться на книге.
• Крис работает над вторым изданием, привнося свежий взгляд на современную инфраструктуру данных.

Почему сейчас выходит второе издание?
• Основные концепции баз данных развиваются медленно, но облачные технологии серьёзно изменили архитектуру данных.
• Главное изменение — рост популярности объектных хранилищ (например, S3) в качестве основного способа хранения данных.
• Разделение управления, данных и вычислений стало доминирующей архитектурной моделью.

Эволюция облачных технологий и баз данных
• Облачные технологии привели к модели SaaS-баз данных, которая даёт большую гибкость в развертывании и управлении.
• Набирают популярность edge computing и встроенные базы данных (DuckDB, расширения PostgreSQL).
• Дискуссии о компромиссах между облачными и самостоятельными (on-premise) моделями продолжаются.
• Экосистема расширений PostgreSQL (PG Vector, PG DuckDB) позволяет универсальным базам данных поддерживать специализированные нагрузки.
• Компании могут начинать с расширений, но со временем переходить на узкоспециализированные решения.
• Рынок одновременно консолидируется вокруг универсальных баз и поддерживает рост нишевых высокопроизводительных решений.

Вызовы при написании второго издания
• Основная структура книги осталась прежней, но текст серьёзно обновлён и переработан.
• Важно было найти баланс между необходимыми изменениями и избежанием избыточных добавлений.
• ИИ использовался для исследований, но не для написания текста.

В конце обсуждения участники рассказали о своих текущих проектах:
• Мартин исследует локально-ориентированное ПО, где основное хранилище — устройство пользователя, а облако — резервный вариант.
• SlateDB, open-source проект Криса, движок, разработанный для использования облачного объектного хранилища, обеспечивая масштабируемое и надёжное управление данными. Построенный на основе структуры LSM-дерева (log-structured merge-tree), он отличается от традиционных движков хранения тем, что записывает все данные непосредственно в объектные хранилища, такие как Amazon S3, Google Cloud Storage, Azure Blob Storage, MinIO и Tigris.

Пошли в вестибюль, сделаешь мне кастдев

При проведении кастдевов для нашего обучения выяснилось, что некоторым опытным инженерам непонятны наши тексты с описанием курсов, поскольку они написаны жаргонно, как будто для тех, кто уже “в теме”, а не для тех, кто хочет стать “в теме”. Поэтому я решил написать несколько заметок про темы, которые мы сейчас “качаем” благодаря сотрудничеству с Мишей Курмаевым: производительность бекендов и телеметрию. Начнем с заметки с определениями.

Телеметрия — фонарик в тёмном подвале твоего продакшена, помогает найти «неведомую херню» до того, как она найдёт тебя. Сбор, передача и анализ данных о работе системы.
Трейсы — это следы, оставленные запросом по всей системе, чтобы не заблудился и не потерялся в клубке твоих микро-сервисов. Последовательность событий, показывающая путь запроса через систему.
Распределенный трейсинг — это как гео-метка твоего девайса, но для запросов, показывающая, как они путешествуют через все сервисы, не заблудившись и не застряв в пробках. Отслеживание пути запроса через несколько сервисов в распределенной системе.
Спан — это как одна остановка в путешествии запроса, запись в дневнике, где фиксируются время, важные детали и связь с соседними станциями. Одна операция в трейсе, содержащая временные метки, метаданные и связи с другими спанами.
OpenTelemetry — это стандарт для телеметрии (трейсы, метрики, логи). За стандарт OpenTelemetry отвечает Cloud Native Computing Foundation (CNCF) при участии сообщества разработчиков и компаний.
APM — это аббревиатура для Application Performance Monitoring
Основные инструменты, предоставляющие возможности для сбора и анализа трейсов: OpenTelemetry Collector, Jaeger, Zipkin, Signoz, Elastic APM, Datadog APM, New Relic, Lightstep, Honeycomb
Кастдев (Customer Development) — это изучение клиентов и их потребностей.
Вестибюль (“vestibulum” , на латыни означает “прихожая” или “передняя комната”) — входное помещение здания перед основными комнатами или залами. Школьники на перемене мчались в вестибюль делать кастдев.

Сделаем онлайн-встречу про телеметрию на следующей неделе, напишу про это отдельно.

Блокировки при работе с СУБД

Badoo (нынче Bumble, единственный серьезный конкурент Tinder на мировом рынке) когда-то был полноценной социальной сетью. Например, у меня в профайле были сотни фотографий. Лента обновлений была полна всяких событий, по разнообразию совсем не уступающих Фейсбуку, особенно в теперешние времена (кто с кем подружился, что поделал, кого полайкал - с кучей свистоплясок вокруг privacy настроек). И конечно, был мессенжер, и с мессенжером была куча проблем. Мы всё делали на базах, и одна из типичных проблем подобных проектов - битые денормализованные счетчики непрочитанных сообщений. Мы избегали частых операций count и старались все счётчики денормализовать. Бывало, где-то косячили, счетчики начинали биться, а отлаживать большую систему, в которой обновления могут прийти из разных кусков – непросто. Косячили не так чтобы много, и вроде работали достаточно стабильно, но время от времени счетчики всё равно бились. Это не только была наша проблема - хорошо помню минимум два крайне неприятных косяка с битыми счетчиками в Телеграме и мессенжере Фейсбука, на которые напарывался сам как юзер.

Самый простой и прямолинейный способ побороть такие проблемы - пессимистичные блокировки в начале транзакции (select get_lock(), например, и select … for update). Первая транзакция получает блокировку, а вторая транзакция просто не стартует, тк вначале попытается получить блокировку на уже заблокированй ресурс.

А ещё есть метод оптимистичных блокировок через версионирование. Кажется, мы его использовали редко, хотя метод прикольный. Суть в следующем. Куда-то в базе добавляется версия, и обновление идёт не просто по ключу, а по ключу с дополнительным условием, которое гарантирует, что транзакция изменяет “свою” версию. После обновления можно проверить количество обновленных рядов, и если 0 - обработать эту ситуацию как ошибочную.

Однако, вдумчивый читатель мог насторожиться: ведь СУБД бывают разные уровни изоляции. И действительно, в зависимости от уровня изоляции в описанном выше сценарии могут появиться нюансы. Уровень READ UNCOMMITTED рассматривать несерьезно. Если у нас уровень изоляции READ COMMITTED, то оптимистичные блокировки работают, как описано выше: вторая транзакция, которая пытается обновить данные с указанием устаревшей версии, не сможет этого сделать, так как версия уже поменялась. В этом случае никаких ошибок нет, но количество обновленных строк равно 0, и вот эту ситуацию (0 affected rows) нужно поймать и обработать.

Но READ COMMITTED default уже не у всех баз: MySQL, например, в отличие от PostgreSQL, уровень по умолчанию – REPEATABLE READ. И вот если у нас уровень изоляции REPEATABLE READ или даже SERIALIZED, то ситуация может быть совсем другой. На этом уровне движок базы самостоятельно отслеживает конфликтыи лочит данные более агрессивно, и теоретически может быть разное поведение. Например, такое: блокировка до коммита первой транзакции с последующим 0 affected rows. И тогда будет парадокс: я “вижу” старую версию, но не могу её обновить. А ещё транзакции могут быть сложнее, и например для SERIALIZED конфликт разрешится откатом. Поэтому сложные транзакции с оптимистичными блокировками могут работать по-разному для уровней изоляции READ COMMITTED, REPEATABLE READ или SERIALIZED, и это нужно учитывать. Чуть позже напишу пост, как это работает в MySQL и PostgreSQL подробнее.

Не является финансовой рекомендацией ;) Кстати, насчет финансов: именно в биллинге постоянно ловили проблемы с блокировками в MySQL, и там был смешной косяк. Старые версии движка блокировок get_lock() не поддерживали множественные блокировки, но это полбеды. Настоящая беда была в том, что предыдущие блокировки просто сбрасывались молча, что могло приводить к неприятным косякам с деньгами на проде. Мы тогда просили Костю Осипова исправить это поведение, причем я изначально просил Костю не просто пофиксить поведение, но и “пропушить” его в апстрим Оракла, так как самостоятельно поддерживать кастомные сборки базы ну совсем не хотелось. Дело было давно (см. скрин), но с тех пор вроде в MySQL get_clock() работает корректно.

99% не мереяет P99, а зря.

Астрологи объявили неделю перфоманса и обзервабилити на этом канале. Monster Scale Summit (начинается сегодня) звучит конечно понтовее, чем P99 (тоже конференция). Потому что ну кто ж в массе знает, что такое P99, и почему это лучше P50? Gil Tene в свое время сделал многое, чтобы объяснить народу важность “высоких” перцентилей, это было ещё в домикросервисную эпоху. А с микросервисами это ещё более актульно. Но об этом – в конце поста.

А пока для всех, кто интересуется производительностью. У кого, бывает, тормозит, но сходу непонятно, где. Или логи/трейсы есть, но в них можно утонуть. Или подняли Sentry, а он не тянет (а он не тянет, его ж фронтендеры придумали). Мы хотим стать самым крутым провайдером обучения по перфомансу для бекендеров, и стартуем новый трек, “Производительность и наблюдаемость бэкенда”. Про телеметрию в частности и измерения в широком смысле, про “как” и “что” мерять, и, главное, “чем”. Автор программы – Михаил Курмаев, Т-Банк.

Больше десяти лет мы проработали с Михаилом в Badoo/Bumble, с первого дня основания компании. Всё это время Михаил занимался “платформенными” задачами. За это время проект вырос с нуля до 15млн DAU, сотен миллионов зарегистрированных пользователей (сейчас называется цифра в миллиард) и ~200K RPS на бэкенд-приложения в 5 датацентрах по всему миру. Сейчас Михаил развивает data-платформу в Т-Банке. Работать с такими чуваками для любого образовательного центра – большая радость. Очень рекомендую трек Михаила всем, кто развивается как эксперт или руководитель в командах, где бэкенд-технологии играют центральную роль. Мы сделаем открытую встречу с Мишей в ближайшее время, об этом я объявлю отдельно.

Вернемся к P99. Итак, причем тут вообще P99 и микросервисы? P99 - это 99й перцентиль. Самые медленные запросы, не попавшие в остальные 99% запросов. Обычно считается, что там мусор, какие-то случайности, которые портят нам всю статистику. Это большая ошибка. Чем больше в системе движущихся частей, тем больше актов взаимодействия между юзерами и сервисами. Тем выше вероятность “напороться” на тормоза. Если у вас тормозит 1% запросов, но за одну сессию пользователя его действия порождают 100 запросов к микросервисам, то вероятность того, что пользователь не будет замечать тормозов - (1 - 0.01)^100 = 0.37. 63% юзеров вашей системы на самом деле могут постоянно страдать от тормозов, хотя ваши приборы будут показывать, что всё в системе идеально. Меряйте, друзья, P99.

StarRocks DB в Grab, FerretDB 2.0 c DocumentDB и другие новости от DevHands-радара (неделя 1-8 марта).

Всех дорогих девушек, и прекрасных разработчиц в частности – с восьмым марта!

Инженеры Grab рассказывают о том, как в одной из стриминговых подсистем перешли от стека Telegraf/InfluxDB/Grafana (TIG) к решению на основе StarRocks. StarRocks - это колоночная база для реалтайм-аналитики: внутри Massively Parallel Processing (MPP) и векторный движок (ссылку на лекцию Энди Павло прилагаю). У StarRocks интерфейс MySQL, что приятно само по себе и облегчает многие интеграции. Говорят, используется в WeChat. Интересно, использует ли кто-то StarRocks у нас, кто знает?

Мажорный релиз FerretDB 2.0.0. FerretDB - документная база поверх движка PostgreSQL, опенсорсная альтернатива MongoDB. В этом релизе используется постгресовский DocumentDB движок. Внезапно (на самом деле нет), от Microsoft.

У Grafana Labs вышла обзорная статья про то, как визуализировать данные из Google Sheets не убогими встроенными средствами, а самой Графаной.

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

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

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

#devhandsradar

UPDATE. Совсем забыл! На следующей неделе Monster Scale Summit от Scylla, и по промокоду SCALE25 O’Reilly раздают second edition Кабанчика (Martin Kleppmann, “Designing Data-Intensive Applications” 2nd Edition). Но только первые шесть глав. Так что вся книга целиком будет нескоро, а русский перевод и подавно.

Вышел большой 2х-часовой стрим, где обсуждали с Кириллом Мокевниным (сооснователь Хекслета) про “хайлоад” и всё такое. Есть таймлайны. Почему показывается обложка про кубернетес - не знаю, видимо, закешировлся какой-то косяк продакшена.

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

https://www.youtube.com/watch?v=hU1VOEcU7Ig

Альтернативные платформы: ВК Видео | Аудио
https://www.youtube.com/watch?v=hU1VOEcU7Ig

Devhands радар: почитать на неделе 21 - 28 февраля 2025

Gen AI Patterns. Martin Fowler и Bharani Subramaniam продолжают труд по паттернам генеративного AI. В январе я уже писал про эту статью, а сейчас они дополнили её разделом о файн-тюнинге.

Anomaly detection. Всем, кто мониторит и выстраивает алертинг на аномалии. На ycombinator закинули ссылку на проект Merlion (реп Salesforce, крупнейший американский CRM SAAS): На заметку, вдруг пригодится + солидное сравнение фич по предсказаниям и поиску аномалий, а в комментариях еще и указали другие проекты, которые добавить к сравнению. Вообще если интересна тема поиска аномалий, то рекомендую вам доклад Евгения Россинского (CTO ivi.ru) “Как из Python и палок собрать детектор аномалий для highload”.

Memcached. Ещё прошлой неделе на LWN.net вышла отличная обзорная статья про Memcached, но полностью в паблик её выложили только сейчас. В статье подробно рассказывается об истории memcached (забыли, правда, про avva), и о таких фичах, как новый протокол, дисковый сторадж (не знал об этой фиче!), прокси. В каментах с поправками отметился dormando, текущий мейнтейнер мемкеша.

OAuth2: cпасибо, подучил. В конце января Роман Глушко опубликовал на английском огромную статью про OAuth2. Недавно она была переведена на Хабре - не самым лучшим образом, но зато по-русски. Если вдруг вы знаете статьи проще и лучше - напишите, пожалуйста, в комментариях. Помимо академического у меня шкурный интерес: мы готовим секьюрити-курс для бекендеров, и я пока не могу определиться, в каком обьеме там дать OAuth2, тема просто широченная.

Вышел Yandex GPT 5, а претрейн модель выложена в свободный доступ. По этому поводу Сергей Марков из Сбера написал: «Яндекс» перешёл на дообучение Qwen. Какая разница с Китаем, который делает десяток своих собственных моделей. (…) Экономят в моменте — а на долгосроке проиграют, и мы проиграем тоже без нормального соревнования. Я так считаю: подсесть на чужие веса при обучении это как подсесть наркоману на иглу. [1], [2].

Майкрософт закроет Скайп. Просто дань эпохе. Про скайп внезапно вспомнил не так давно, когда майкрософт добавил туда OpenAI GPT бота, это был самый простой способ пообщаться с ChatGPT без установок и антисанкционных приседаний. А так уже сто лет не заходил. Еще Skype был одним из первых проектов, кто использовал PostgreSQL, и даже законтрибутил в экосистему несколько культовых проектов (pgBouncer и PgQ, например). Пару ссылок олдам всплакнуть (1) DB Tools, (2) Scaling PosgtreSQL to 1 Billion Users

HashiCorp all-cash acquisition. Хашикорп всё, с IBM закрыли сделку на $6.4 млрд. Вклад в индустрию выдающийся: Vault, Vagrant, Terraform, Consul, Packer, Nomad, и что-то наверняка забыл. Этой сделке предшествовало долгое падение стоимости акций, но к сожалению вы вряд ли найдёте про это много информации и lessons learned. Кажется, инвесторов попросту нагрели невероятно высоким мультипликатором на IPO. Впрочем, не Хашикорп первый, и не Хашикорп последний.

20 лет заниматься одним софтом. Пост инди-разработчика тулзы для управления рассадками PerfectTablePlan. Всё началось с задачи рассадить 60 гостей на собственной свадьбе. Как пишет автор, это была непростая задача даже без учета “семейных распрей”. И как только я прочел про семейные распри, я начал понимать глубину проблемы. Вообще, если вы думаете, что рассадить сотни человек – это простая вещь, то вы точно не были на дагестанских свадьбах. Но учитывать ещё и распри - это прям серьёзно. Короче, софт живет до сих пор, а у программиста несколько инди-проектов. Сейчас ему 59, и он планирует программировать и «на пенсии».

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

#devhandsradar

Радар DevHands: что почитать на неделе 14-21 февраля 2025

🤩 MultiPaxos и архитектура Neon
Возможно вы слышали о проекте Neon, распределённом PostgreSQL. В этой статье рассказывается об архитектуре Neon, построенной на модифицированной версии MultiPaxos для реализации удаленного распределенного write-ahead лога (WAL). Neon использует разделение ролей Paxos для создания распределенной системы. Postgres выполняет функции Пропозера, Safekeepers – Акцептора, а Pageservers – Лернера. Такой подход позволяет гибко управлять системой, оптимизируя каждый компонент для своей задачи: обработка запросов, надежное хранение данных и управление логами.

🤩 Программирование и рассуждения Генеративного
Общий принцип работы больших языковых моделей основан на распознавании шаблонов и статистическом предсказании следующего токена. Однако одним из неожиданных свойств такого подхода стало то, что модели способны до некоторой степени “рассуждать” при решении задач ( “o1” и “o3” от OpenAI, “R1” от DeepSeek). На сайте Мартина Фаулера (который давно превращен в площадку ThoughtWorks) концептуальная статья о применении и применимости генеративного AI в программировании. На мой взгляд, статья излишне пессимистична: по моему опыту LLМ отлично работают в роли “советчика” при обсуждении планов имплементации.

🤩 Об Redis и об DragonFly
На этой неделе вышло две новости, которые было вселили в меня надежду на то, что в экосистеме кеш-сервисов намечается серьёзная конкуренция. Во-первых вышел третий майлстоун релиза Redis 8, в котором заявлены много-численные улучшения производительности. Во-вторых, DragonFly обьявил о продукте DragonFly Swarm, своём аналоге Redis/Valkey Cluster. Ну началось, подумал я, Valkey пушнул конкуренцию.

По факту оказалось что: Redis, похоже, просто обращает внимание пользователей на возможность включить io-threads, которая была всегда, и говорит, что так можно увеличить производительность в 2 раза. Ну мы это прекрасно видели на своих тестах, 2 раза это конечно хорошо, но это слабый скейлинг по ядрам (продиктованный родовой травмой Redis).

В свою очередь DragonFly похоже пока делает закрытый продукт - в анонсе предлагается потестировать Swarm либо в их облаке (супер-промоушен своего облака), либо обратиться к сейллзам.

🤩 Эмпатия Генеративного
Harvard Business Review рассказиывает, как искусственный интеллект (ИИ) может помочь руководителям стать более “сострадательными лидерами”. Используя ИИ, лидеры могут улучшить коммуникацию, повысить эмоциональный интеллект и создать более эмпатичную рабочую среду, что способствует повышению удовлетворенности сотрудников и эффективности работы. Короче, “напиши то же самое, но корпоративным языком и чтобы не обидеть меньшинства”. Во проблемы у людей, да?

🤩 Миллион, миллион, миллион Эр-Пэ-Эс
Ну а наше исследование, о котором я уже писал подробно, попало в лучшие статьи Хабра, и это не может не радовать. Если ещё не читали про миллион “простых” RPS на PostgreSQL и MySQL на сравнительно недорогом железе - читайте.

🤩 Что такое Devhands Радар?
Будь в курсе новостей разработки вместе с Devhands. Еженедельно мы просматриваем сотни источников и выпускаем дайджест публикаций, чтобы вам было что почитать на выходных. Тренды, новые релизы, перспективные проекты, обсуждения с экспертами.

#devgandsradar

Запись стрима с Филом Дельгядо готова

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

И КСТАТИ: Фил согласился прочитать приглашенную лекцию по микросервисам для слушателей нашего хайлоад-потока (сисдизайн, производительность и масштабирование). Это прям очень круто, я жду этого события с нетерпением и завидую, что у меня просто не было возможности так учиться. Группы у нас почти сформированы, так что это сообщение – last call.

На встрече с Филом обсуждали:
- является ли секция по системному дизайну (system design) необходимым этапом или нет
- почему design-секции могут приносить больше вреда, чем пользы
- чем их можно заменить и масштабируется ли этот подход для больших компаний
- как готовиться тем, для кого design-секция неизбежна

Таймкоды:
1:00 Определяемся с терминами, в целом что не так с дизайн-интервью
3:00 Углубляемся в сценарий интервью: что плохого в том, чтобы за час попытаться спроектировать "саджестер" или "укорачиватель урлов"
11:00 Обсуждаем собственно навыки и виды проектирования
16:00 Что нам нужно проверять на интервью, и что проверяет Фил?
18:22 Как нанять человека, который сразу же должен будет заниматься проектированием?
19:58 Какие дизайн-документы пишут программисты в компании Фила
23:45 Фил не соглашается со взглядом на дизайн-секцию как на погружение вглубь, под капот разрабатываемых систем и компонент
26:18 Обсуждаем дизайн-секцию с позиции "продуктовой" компании: как проверить, что человек умеет быстро "схватить" продуктовую идею и выдать решение в первом приближении, поработав самостоятельно с продуктовой позиции
31:35 Компания растет: как поставить пайплайн интервью "на поток" и стандартизировать найм? Нужно ли это?
38:00 Фил противопоставляет "эффективность" "прозрачности", и рассказывает, почему не верит в чек-листы и вообще формализм в найме, а Алексей сомневается, что идеальный процесс Фила вообще можно организовать
50:00 Как решать проблему ухудшающего отбора, держать высокую планку и защититься от "протухания", если отказаться от формальных процессов и стандартов найма по всей компании
54:25 Нужна ли компании "единая культура"?
1:00:00 Можно ли нанять человека за 1-2 интервью? Обсуждаем короткие серии интервью, кто его должен проводить, что проверять. Почему бигтехи делают 4-5-6 интервью?
1:07:40 Проектирование как скилл, который всё равно придется демонстрировать: как готовиться к интервью? Как разузнать детали, что спрашивают и что ожидают в процессе интервью в конкретной компании?
1:14:00 Что читать? Есть ли альтернативы книжке Сюя?
1:15:00 Мок-интервью (в том числе публичные) имеют ли они смысл в подготовке?
1:16:00 Какие области знания были для Фила важными в процессе профессионального роста?
1:21:00 Фил вспоминает свои ошибки в начале карьеры
1:23:00 Ответы на вопросы, которые задавали в чате: самая сложная задача, самый сложный архитектурный выбор и тд

https://www.youtube.com/watch?v=Fd5uwfmZjRM

——

Last call! 24 февраля старт хайлоад-потока
- Системный дизайн высоко-нагруженных проектов (3 месяца, онлайн): учимся проектировать и масштабировать большие проекты, разбираем и проектируем системы, рассчитанные на 100M DAU.
- Производительность и масштабирование (3 месяца, онлайн), хардкор с инфрой: управляем своим Linux-сервером, “выжимаем" 100K RPS, работаем с кластерами Redis, CockroachDB, SPQR+PostgreSQL

Напоминаю, сегодня стрим с Филом Дельгядо, обсуждаем системный дизайн, встречаемся через 45 мин, 18:00 MCK.

Наконец вышла наша статья с комментариями по исследованию кешей и СУБД. Redis, Valkey, Memcahed против PosgtreSQL и MySQL. Кстати, вы знаете, что Redis готовит ответный удар? Они выпустили релиз-кандидат со “значительными улучшениями производительности”. Напишу про это позже - и потестим это дело.
https://habr.com/ru/companies/oleg-bunin/articles/883422/

Радар DevHands: почитать на неделе 8-15 февраля 2025

Yandex: Как главная страница Яндекса переезжала на Go
Это уже отшумевшая статья (ей целых три дня) из которой можно узнать, что в Яндексе есть Группа Бекендеров Главной Страницы, что до сих пор Яндекс жил с Perl на главной, но титанически смог смочь пересилить себя.
Зацените! Запретить у себя безобидный похапе, но иметь в хозяйстве такое:

sub respond ($;$$@) {
my ($req, $headers, %args) = @_[0, 2 .. $#_];
return undef unless ref $_[1]
}

Все, кто помнит, что значит my и $_[1] приглашаются в комментарии ещё раз вспомнить, за что же мы ненавидели перл (вот за таких перлописателей главных страниц) и что же блин, мать его, значило $#_. Brainbench Master Perl 2000 не помнит.

Atlassian: How we migrated Bitbucket Cloud to Envoy proxy
Bitbucket (Git-хаб от Atlassian) обрабатывает миллиарды запросов и петабайты данных в день. У них был Amazon Global Accelerator, это было очень дорого, плюс они упирались в лимиты по пропускной способности. Заменили это дело на связку network-балансеров и envoy и написали про это.

Graphana learning journeys
Графана запускает новый раздел - мини-туториалы для пользователей. Интересный пример работы с сообществом, может быть интересен как кейс менеджерам и дев-адвокатам.

JetBrains/Ktor: Релиз Ktor 3.1.0
Вышла очередная версия Ktor, в целом минорная, но возможно, интересная тем, кто как и я, “приглядывается” к связке Ktor+Kotlin. Из интересное: Ktor поддерживает из коробки SSE (server side events) и постоянно что-то в них улучшает, они добавили поддержку WebAssembly (Wasm) и анонсировали поддержку gRPC.

Rust: 2024 State of Rust Survey Results
Сам опрос мне не очень нравится, но я считаю, что все survey такого уровня надо смотреть и изучать: это прикольные инсайты и кейсы, как по маркетингу, так и по работе с сообществами. Итак, что там интересного по фактам? Россия - на восьмом месте по числу опрошенных. Англия на 3-м, Франция на 4м (WTF?). Израиль с кучей стартапов и университетов на 24-м. Прод-рантаймы на винде у 44%. VS Code 62%, vim/neovim 31%. Но главный график закопан в середине, на Rust как на основном языке на работе пишет, внимание, 30%. Топ-3 вызова за два последних года: не достаточно популярный в технологичной среде (43%), становится более сложным (43 %), разработчики языка не получают достаточно поддержки (32%). Но это мне не помешает начать писать на Rust в 2025-м, а если вы вдруг Rust хорошо знаете и хотите запустить или уже запустили свой курс – напишите мне, возможно, я предложу вам интересное партнёрство.

Enjoy

Интервью по системному дизайну: хайп или необходимость?

TL;DR: приходите на очередной митап в среду 19-го февраля, в 18:00 МСК (Youtube).

🤩Мы уже привыкли, что design-секцию на программистские senior-позиции проходят все. C удивлением даже можно обнаружить, что design-секции теперь проходят не только бекендеры, но аналитики, и даже продакты. Однако есть сомнение, что эта секция приносит пользу и решает эффективно задачи нанимающей компании. Я позвал на разговор Фила Дельгядо (lekton.io), который придерживается этой точки зрения.

🤩Фил Дельгядо – архитектор и java-бекендер, и в карьере своей чем только не занимался, от двухзвенок на Visual Basic до хардкорного SQL. Последние годы делает разные платежные системы, рассказывает про это на митапах и конференциях, в частности, является одним из регулярных спикеров конференции Хайлоад. Помимо прочего Фил является активным участником, наверное, всех архитектурных Telegram-чатов, которые я знаю, обладает потрясающе широкой эрудицией и непревзойденным полемическим талантом. Касательно архитектуры в целом и design-интервью в частности у Фила вполне здравые рассуждения, которые он последовательно отстаивает.

Мы обсудим:
🤩 почему design-секции могут приносить больше вреда, чем пользы
🤩 чем их можно заменить и масштабируется ли этот подход для больших компаний
🤩 как готовиться тем, кто всё равно понимает, что design-секция неизбежна?

Ссылки:
🤩 вещание на Youtube: https://www.youtube.com/@AlexeyRybak/streams.
🤩 календарь Google: https://calndr.link/e/sUWoUsLgGx?s=google
🤩 календарь Apple: https://calndr.link/e/sUWoUsLgGx?s=apple

Радар: почитать на неделе 1 - 7 февраля 2025

Уж не знаю, как так получается, но теперь в фокусе LLM.

LLM ищет баги в софте Фейсбука. Блин, это уже не из области фантастики. Короче, цель: иметь систему, которая сама находит баги. Сначала учим систему искать баги. Инженер написал сервис. Написал текстом, о каких багах он “беспокоится”, обычным естественным языком. Софт это прочитал, и нагеренил баги – в отдельную ветку, чтобы не ушло в прод. Инженер отсмотрел, отметил годное. Далее нагенерил тест-кейсы, чтобы найти эти баги. И это всё повторяется на этапе тренировки. После чего софт генерит тест-кейсы, чтобы найти неизвестные баги по тестовым описаниям. Статья попсовая, но есть ссылка на статью в arXiv c результатами (ACH was used by Messenger and WhatsApp test-athons where engineers accepted 73% of its tests)
https://engineering.fb.com/2025/02/05/security/revolutionizing-software-testing-llm-powered-bug-catchers-meta-ach/.

Яндекс написал огромный лонгрид про оптимизацию и ускорение в LLM-задачах: https://habr.com/ru/companies/yandex/articles/878230/

Интересный обзорный рассказ Мичила Егорова на Хайлоаде про то, как в X5 запустили с нуля AI-отдел со своей инфрой. Будет интересно, если думаете строить свою инфраструктуру. Мотивация, стэк, компоненты, архитектура, фейлы. Доклад полугодовой давности, но открыли вот прям сейчас: https://www.youtube.com/watch?v=EEi0eO8ztaY

Redis системно “качает” тему RAG и GenAI, но я пока не понимаю, действительно ли они видят в этом рынок (а я нет), или это просто хайп: https://redis.io/blog/you-need-more-than-a-vector-database/

Ну и ссылка от Олега Волчкова для любителей оптимизации запросов — https://www.pgmustard.com/blog/index-scan-doesnt-mean-its-fast: “Не всегда достаточно убедиться, что запрос использует индекс. Можно и нужно покопать дальше, если видим всякие bitmap index scan, много записей удалённых фильтром и т.п.” А если кто хочет прокачаться в оптимизации запросов PostgreSQL – подсказываю, что делать.

Если что ещё интересное выходило - скидывайте в каменты.

P.S. Специально для Романа: если кого-то тошнит от моих постов, можно теперь не сдерживать себя. На сверкающую фиолетовую какашку 💩 буста не хватило, добавлю, если забустите: https://t.me/boost/rybakalexey.

Запись стрима про СУБД и саммари

Готова запись стрима: https://www.youtube.com/watch?v=8x3lgZoV7EA

Шикарный был стрим, за что огромное спасибо экспертам, Леше Копытову и Коле Ихалайнену (MyDB), и Антону Герасимову (Гиперус), и всем остальным, кто пришел. Мне кажется, это один из лучших наших стримов.

Знатно (хоть и слегка сумбурно) зарубились под конец про лицензии. Всего обсудили три темы:
- Тренды на рынке СУБД. Никто из экспертов не верит, что в экосистему открытых традиционных баз всё-таки “завезут” готовые cloud-native/кластерные решения. Думаю, это обязательно произойдет, вопрос срока.
- Обучение бекендеров: ORM – только для MVP. Знаю, что тема мега-флеймовая, но это мнение экспертов, если интересно – послушайте.
- Обсуждение лицензий: основная рубка была вокруг “тонкостей” удовлетворения GPL, есть по сути два мнения на этот счет: мнение “корпоративное” - даже не надо пытаться, риски не оправданы, поэтому венндорская модель с GPL-компонентом невозможна. Второе мнение: в большом количестве случаев GPL не диктует открывать код и не является блокером для вендорской модели, а все опасения и терминология “вирусная” от юридической неграмотности. К соглашению так и не пришли, все остались при своих.

Как мы резюмировали на стриме, хорошим результатом этой дискуссии мог бы стать (а) набор легальных приёмов, которые наглядно демонстрируют, как именно можно распространять закрытый софт с GPL-компонентами (линковка с открытым рантаймом, использование LGPL-версий или вовсе открытых клиентских библиотек и др). Примеры коробочного софта битрикса, ispmanager и многих других хорошо показывают: есть компании, которые не бояться строить вендорскую модель с GPL-софтом. (б) обзор судебных и (самое сложное) не дошедших до суда кейсов, когда использование GPL приводило к последствиям (отказ от модели, выплата лицензионных отчислений, судебные компенсации издержки). Если знаете такие кейсы - кидайте в каменты.

Напоминание: сегодня в 18:00 стрим за СУБД!

Знаете ли вы:
* когда завезут planet-scale в PostgeSQL/MySQL и закончится ли уже этот бесконечный парад planet-scale СУБД с хер пойми какими лицензиями?
* что будет в тренде СУБД через 5 лет? действительно ли будущее за разделённым compute/storage и есть ли уже PostgreSQL/MySQL поверх S3?
* кто из СУБД лучше готов к гонке открытых много-слойных архитектур? превратится ли СУБД как продукт в конструктор из открытых компонент?
* зачем компаниям типа Visa, UBER, Facebook консультанты СУБД и с какими проблемами эти компании обращаются к консультатам?
* что важно для облачного вендора при выборе СУБД?

Это дело и многие другие вопросы обсудим сегодня с замечательными гостями. Приходите.

https://t.me/rybakalexey/192

Встречайте нового эксперта DevHands и курс по PostgreSQL

Важная новость: с января к нам присоединился Николай Ихалайнен, проработавший более 10 лет в Percona.

Николай консультировал и помогал исправить баги и проблемы производительности СУБД для крупнейших интернет-игроков планеты: Facebook, Uber, Booking, Broadcom, United Healthcare, Nokia и многих других проектов с много-миллионной аудиторией. До этого Николай работал в “старом” Кинопоиске, сделав возможным масштабирование крупнейшего российского сайта о кино “Кинопоиск” с 60 тыс до 20 М уников в сутки.

Наша основная политика – работа с топовыми экспертами по модели revenue share. Это исключает ставки 5 т.р. за лекцию (или 4 т.р.?), ухудшающий отбор, и прочие перекосы, убивающие индустрию качественного профессионального образования. Если вы обладаете уникальным опытом в топовых российских и мировых компаниях, продолжаете работать “руками” и следить за трендами, если у вас уже есть курс или идея запуска крутого курса, вы готовы разработать его и запускать хотя бы 3-4 группы в год на нашей площадке – напишите мне, поможем с запуском и поделимся выручкой (рассчитываем на доход в 300-700 т.р. в месяц для авторов).

Николай фактический сделал возможным запуск направления Баз Данных с DevHands. Месяц назад мы проводили голосование о направлениях в области СУБД, которые могли быть вам интересны – и ожидаемо с большим отрывом победил PostgreSQL. И уже в марте мы стартуем первый курс, посвященный PostgreSQL: “PostgreSQL 17: архитектура и тюнинг SQL-запросов”. Мы верны своей традиции: с первого дня каждый слушатель получает в управление неслабую виртуалку (8 vCPU, 12G RAM, 100G NVMe) с настроенным PostgreSQL, чтобы вы могли погрузиться как можно глубже в архитектуру и особенности работы этой СУБД.

Подробную программу можно посмотреть на странице курсе, и обратите внимания на нашу совместную с Николаем вводную лекцию: “Знакомство с основными концепциями СУБД через наивную попытку спроектировать СУБД самостоятельно (повторять не рекомендуется)”. Это из разряда “я всегда хотел, чтобы такой материал мне кто-то прочитал на заре карьеры, но его не было, и поэтому мы его сделали”. Приходите. Старт курса Николая - 6-е марта 2025.

TechFounders и питерский Highload

TechFounders — новая конференция от команды Highload, объединяющая инвесторов, IT-стартапы и предпринимателей. Нам нужны клёвые доклады на темы:
- Финансы и юридические вопросы
- HR
- Технологии и инфраструктура
- Маркетинг и продажи
- И любые другие темы, которые могут быть полезны сообществу будущих и настоящих технологических предпринимателей

Подавайте заявки.

А в это время питерский Highload скоро закроет приём докладов.

Если сомневаетесь в теме, приходите на встречу с программным комитетом 6 февраля в 19:00 в офис Nexign (Санкт-Петербург, ул. Уральская, 4). Сбор с 18:30, возможен онлайн-формат (ниже ссылки). Будет обсуждение актуальных для 2025 года тем, разбор заявок и обратная связь по ним в режиме реального времени.

Мне лично особенно интересны доклады про внедрения: кластерные стораджи и базы, шардинг-прокси - чем больше кровища, говна и палок, тем интереснее.

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

Радар: почитать на неделе 24-31 января

Сегодня в фокусе технология eBPF (Extended Berkeley Packet Filter) — это технология в ядре Linux, которая позволяет выполнять безопасный и эффективный профайлинг в ядре без необходимости вносить изменения в код прикладных приложений. То есть вы включаете такой профайлер на “хуках” для сисколов ядра, который без установки софта анализирует всё, что происходит. Дополнительных костов, типа, минимум. Применения широкие: сбор метрик, трассировка вызовов, анализ задержек, обнаружение аномалий и анализ трафика и многое другое. Всё - без модификации приложений.

🤩 Perforator: открытый eBPF-инструмент + описание проблем профилирования в линухе
Яндекс выпустил в open source систему непрерывного профилирования Perforator, ранее использовавшуюся для анализа производительности внутренних сервисов. Perforator позволяет детально изучать работу приложений, выявлять узкие места и оптимизировать их, что приводит к значительному повышению эффективности работы сервисов. Система доступна на GitHub под лицензией MIT и может быть развёрнута в кластере Kubernetes или использоваться локально как замена perf record с меньшими накладными расходами. Perforator также поддерживает профилирование JIT-компилируемых языков и может применяться для автоматической оптимизации программ с использованием Profile-Guided Optimization (PGO), что, по результатам тестов, обеспечивает ускорение около 10% в различных сценариях.

🤩 Для справки. Другое интересное решение на базе eBPF, если вы вдруг не слышали – Coroot. Это observability-инструмент, opensource (open core, если точнее), разработанный для упрощения мониторинга и диагностики микро-сервисных архитектур. Ключевые особенности:
🤩 Автоматическое обнаружение сервисов и их зависимостей: Coroot строит топологию микросервисов, отображая их взаимодействия и состояния, что облегчает понимание структуры приложения.
🤩 Использование eBPF для сбора данных: собирает метрики и трассировки без необходимости внесения изменений в код приложений, что снижает накладные расходы и упрощает интеграцию.
🤩 Интеграция с OpenTelemetry: умеет собирать и анализировать распределенные трассировки, предоставляя детальную информацию о производительности и задержках в системе.
Короче, такое решение с акцентом на простоту, быструю установку, чтобы ничего не настраивать, поставил - и работает. Делают “наши” - Николай Сивко и Петя Зайцев сотоварищи.

Еще больше почитать:
🤩 Martin Fowler и Bharani Subramaniam популярно обьясняют, как интегрироваться с LLM от прямых промт-запросов к эмбеддингам (и очень простая иллюстрация, что такое эмбеддинги)
🤩 В новом выпуске CTO-craft помимо кучи воды любопытная статья “Продуктивность разработчиков в 2025 году: больше ИИ, но неоднозначные результаты”. Джунам напрячься, Синьорам снова учиться.
🤩 Если вы бекендер, зачем-то сидите на винде и вам зачем-то понадобился нативный Redis под винду без виртуализации - теперь есть такая шняга Memurai (девелоперам бесплатно).

Если я что-то интересное пропустил - скидывайте в комментарии.

🤩 Enjoy

Стрим Devhands 6-го февраля 18:00 MSK про СУБД

Рад сообщить, что в следующий четверг, 6-го февраля 2025 года в 18:00 МСК, в YouTube будет очередной стрим, посвященный базам данных, тенденциям, открытому ПО, лицензиям, облачным СУБД.

Тема: Тренды в мире открытых СУБД: ламповый обмен мнениями
Обсудим следующие вопросы:
🤩 Тренды развития СУБД, комментарии экспертов по статье Эндрю Павло и Майкла Стоунбрейкера
🤩 Коммерциализация open source СУБД: как на этом заработать
🤩 СУБД со стороны облачного вендора: что его бесит и чего не хватает?
🤩 Нужно ли учить СУБД бекендерам, или всё запилит ORM, а DBA за ним «разгребёт»?
🤩 Что происходит с лицензиями и как это затронет нас всех?

Придут супер-эксперты:

🤩 Алексей Копытов. Основатель и генеральный директор MyDB. В разработке MySQL и родственных проектов участвует с 2004 года в таких компаниях, как MySQL AB (впоследствии Oracle), Percona и Huawei. Автор многих функций и оптимизаций производительности в MySQL, Percona Server и Percona XtraBackup. Руководил лабораторией баз данных в российском R&D центре Huawei, где разрабатывались облачные решения на основе MySQL и других СУБД. Один из организаторов митапа Database Internals.

🤩 Николай Ихалайнен. Со-основатель MyDB. Энтузиаст открытого програмного обеспечения, провел больше десятка лет, консультируя и поддерживая проекты, использующие MySQL, PostgreSQL, MongoDB на реальном железе, в облаках и Kubernetes в компании Percona. Автор ведущий нового курса Devhands “PostgreSQL 17: архитектура и тюнинг SQL-запросов”. Построил инфраструктуру и работал над оптимизации LAMP в старом Кинопоиске. Участвовал в разработке биллиновых систем для ISP/IPTV разработчиком на C++. Внедрял e-commerce в России в составе e-House как сисадмин и программист.

🤩 Антон Герасимов — Гиперус, CTO. Специализируется на разработке облачных решений, масштабируемых системах, сетевой безопасности. Cейчас Антон – CTO в компании Гиперус, занимающейся разработкой коробочного решения для on-prem облаков (продукт, реализующий гиперконвергентную ИТ-платформу внутри компаний). Ранее работал в компаниях МойОфис, Спутник и Rambler.

🤩 Ссылки для удобного добавления в календарь
Google: https://calndr.link/e/5oYHlpYS5G?s=google
Apple: https://calndr.link/e/5oYHlpYS5G?s=apple

В рамках стрима заодно расскажем с Николаем про наш новый курс, “PostgreSQL 17: архитектура и тюнинг SQL-запросов”. Zoom в этот раз будет только для участников программ Devhands (в прошлый раз какие-то анонимные задроты нам пытались сорвать эфир).

Вы все уже знаете про DeepSeek? Это китайский ChatGPT, который вчера наделал кучу шума и это привело к грандиозному снижению стоимости акций NVidia. Пока я этот текст писал, процентов до 17%, и это в общем просто дохера (это предложение можно спеть на мотив восьмиклассницы).

По наводке чата бывших коллег обнаружил занятный эффект. На вопрос “Can Chinese government make mistakes” дипсик сначала отвечает, что, да, может совершать ошибки (как и любое правительство), но потом меняет ответ (ой это выходит за рамки, давайте о другом)!

Такое впечатление, что там другая сетка поверх проверяет, а не является ли утверждение негативным по отношению к Китаю и разным уважаемым товарищам, и если да - ставится заглушка. Хак грязный, но работает!

Саммари делает нормально, президент в США – Байден (у ChatGPT уже нет), русские IP не блочит. Говорят, дешевый API. Срыв стэка на Расте продемонстрировал с unsafe. Больше кода генерить пока не пробовал.

Что ещё сказать? Слава великому китайскому народу, завоевавшему свободу, независимость и счастье.