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

Сделаю в нескольких частях во избежание лонгрида.

Погнали.

Что посетил
— Архитектура хранилища ВКонтакте. Достаточно лайтовый доклад о том, как ВК развивал хранилище от первых версий до текущей(в докладе говорится про два этапа, но есть ощущение, что их было больше). Рассказали о том, как на архитектуру повлияла частота просмотра старых файлов, как данные размазываются по ЦОДам и как с помощью XOR восстановить данные после инцидентов(отдельный доклад об использовании XOR в хранилище ВК видел в отдельном докладе года 3-4 назад, можете найти в сети). Без заумностей, для разгона самое то.
— Миллионы часов: поиск копий в VK Видео. Доклад уже чуть более запаристей, но все еще доступен для понимания. В целом слабо понимаю(и понимаю :) как работает поиск по видео, в докладе как раз про это и про то, как размеченные данные для поиска умещали в оперативную память.
— Надежность на масштабе в 45 млн клиентов — инструменты и практики цифрового банка. Так я и не понял если честно, полезен оказался для меня этот доклад или не очень. Мне он показался больше маркетинговым, поэтому рекомендовать не хочу.

Что хотел посетить и буду смотреть в записи
— Аномалии под нагрузкой в PostgreSQL 2.0. Ну куда же без любимой БД и ее оптимизации. Спикера ранее не видел, поэтому без каких-либо ожиданий, но посмотреть все же хочу.
— Динтаблицы YTsaurus — и ещё одна СУБД от Яндекса. Надеюсь доклад будет больше техническим, чем маркетинговым. Как никак аналог Hadoop.
— Движок распределённого SQL в СУБД Picodata: принцип его работы, принятые архитектурные решения и сравнение с аналогами. В целом интересно, что за новая БД такая и для чего ее можно будет использовать. Тут немножко кишок, возможно будет занудно и скучно, я предупредил :)
— Valkey 8 — релиз форка Redis про performance. Как известно, свежие версии редиса теперь проприетарные, а яндекс начал лить патчи для valkey. Для ознакомления с инструментом.

Оригинальный пост в tg по ссылке еще с новогодних праздников, выкладываю немного с запозданием :)

Салаты кончились, вино выпито, сидим формируем себе полезные новостные рассылки.
Кто хочет сделать себе подобную рассылку с материалами из интересующих вас областей, то для темы дизайна систем рекомендую ребят из blog.bytebytego.com (можете ознакомиться с их роликами вот тут, это проект автора вот этой знаменитой книжки.

Когда будете подписываться на рассылку, то указывайте мою рефералку. Посмотрим, насколько полезные плюшки ребята предлагают.

https://blog.bytebytego.com/?r=52wdox&utm_campaign=referrals-subscribe-page-share-screen&utm_medium=web

Окружение
Все так или иначе пришли с одной целью — что-то узнать:

• 💻 Кто-то узнать про новые продукты, которыми можно решать задачи(например Picodata, Valkey, otterbrix);
• 💻 кто-то про проекты, куда бы он хотел устроиться;
• 💻 а кто-то пришел собственно ради докладов :)

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

Здесь я вижу три выгоды для себя:

1. Ты можешь прикинуть свой уровень в сравнении с окружением.
2. Из разговоров можно понять, в чем ты плаваешь и что тебе подтянуть.
3. Собственно с людьми можно пообщаться, чтобы выяснить интересующую тебя инфу.

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

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

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

Нашел хорошие лекции от ШАДа по внутреннем устройству и принципам систем хранения, Александр Боргардт из @duckstax решил выложить их в открытую.

Обычно материалы по базам данных строятся вокруг изучения PG и что-то упоминается про Mongo и ClickHouse.
Что бросилось в глаза, кроме лекций про протоколы и JIT, так это рассмотрение Picodata в качестве индустриальной БД наряду с Cassandra & Tarantool. Picodata молодой инструмент, о котором кстати много говорили на прошедшем HL, поэтому есть ощущение, что ребята от курса к курсу актуализируют программу.

К своим хомячковым запасам материалов я добавил, теперь несу благодать в массы 🤓

https://t.me/SmotrovDev/37

Присоединяйтесь к блогу в телеграмме :)

карикатурный прогромист

Побывал на HighLoad 2-3 декабря в Москве. Я остался доволен, так что мне есть, что рассказать.

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

Но у ребят все круто продумано:

• ✔️На бейдже присутствует карта помещений, так что найти сундук с сокровищами шансы есть;
• ✔️Сами помещения понятно обозначены, но тут скорее особенность здания Школы Управления Сколково. Через часа 3 ты уже спокойно ориентируешься, хотя порой и тупишь;
• ✔️Между докладами перекусы и кофе в шаговой доступности;
• ✔️Обед по талонам(во время выдачи на стойке регистрации я невольно засмеялся :), без них был бы Ад и Израиль;
  3 декабря в здании было около 2 тысяч человек(или даже больше, @r0oxy, поправь меня), но места хватало всем.

Доклады и спикеры

• ✔️Доклады были подготовлены сильно лучше, чем на других конференциях, которые я посещал;
• ✔️Были спикеры, которые терялись от вопросов после доклада, но сами доклады ребята рассказывали хорошо. Слушать было приятно, запинок было мало.

Сами темы докладов сильно сложнее и комплекснее в среднем(привет докладу с темой «Почему Go лучше Python» с содержанием, пересказывающим статью на Хабре 5 летней давности, которое можно сократить до слова «Потому.») Аномалии Postgres под нагрузкой, устройство файлового хранилища ВК, их же система распознавания отрезков видео, замеры работы разных ДБ на больших RPS — лишь небольшая часть из тем, что были рассказаны.

Отдельный топ докладов с моей точки зрения выложу в следующих постах.

Когда полезно использовать

— В сложных доменных областях. Использование подхода позволит снизить сложность каждого конкретного контекста программы.
— Если в системе сильно различается частота запросов на чтение и запросов на БЛ составляющие системы. Например можно разместить Command & Queries в разных процессах, что позволит горизонтально масштабировать Queries часть системы, так как обычно запросов на чтение сильно больше запросов на запись.
— Если ваша система спроектирована по принципу EDA(Событийно-ориентированная архитектура). Событию системы соотносится конкретная модель данных. Позволяет БЛ не вытекать за пределы обработчика события.
— Когда вы собираетесь разделить базу данных на БД для записи и БД для чтения. Однако следует учитывать, что при разделение БД так же встает вопрос о конечной согласованности данных в базах.

Когда использование не даст преимуществ

— Модели Command & Queries совпадают. В таких случаях лучше использовать совместную(единую) модель.
— В случае, если доменная область неверно выделена в системе, то использование CQRS только запутает и без того слабо структурированный код.

Вернемся к основной теме

В проектах часто вижу, что ORM модель сущности используется во всех контекстах(доменных областях, которые по сути есть в программе, но по факту никто их явно не выделял) системы:
— как выходное отображение для ответа API;
— как DTO между разными модулями;
— для модуля работы с БД(orm модель по логике должно существовать только в рамках этого модуля);
— как модель для формирования тела сообщения в очередь сообщений.

В каждом контексте из перечисленных выше используется одна и та же модель, несмотря на то, что данные модели избыточны в каждом случае примерно на 40-50%(цифры вывел эмпирически, сухой статистики у меня нет, к сожалению). Имеем жирную модель данных на все случаи жизни.

CQRS предоставляет разделение жирной модели на Command model(модель для работы БЛ: создание, обновление, связывания с моделями других сущностей, и т. д.) & Query Model(отображаемая пользователю в запрашиваемом домене).

Названия украдены из концепции Command Query Separation (https://martinfowler.com/bliki/CommandQuerySeparation.html), ключевая идея которой в том, что требуется разделять действия над моделью на две категории:
— Queries — возвращает результат, но не меняет состояние системы(методы без сторонних эффектов)
— Command — Изменяет состояние системы, но не возвращает состояние системы.

Для каждой категории действий над сущностями приложения мы имеем конкретные модели. Если меняется логика создания сущностей — мы актуализируем модель для Command категории. Если меняется логика отображения пользователю — мы актуализируем модель для Query.

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

Или же Command Query Responsibility Segregation

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

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

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

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

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

Хочу подвести итоги темы модульного монолита.

1) Монолит — система, состоящая из одной единицы развертывания.
2) Монолит по умолчанию не комок грязи, в его определение такого нет в принципе
3) Модульный монолит — монолит, спроектированный с учетом модульности.
4) Модульный компонент — независим, автономен и имеет четкий интерфейс

Стоит помнить особенности разработки и эксплуатации монолитных систем:
1) Более легкий порог вхождения для разработки — думаю, тут все понятно.
2) Запуская проект для локальной разработки — вы запускаете ВЕСЬ проект. Был я на проекте, где с учетом размера кодовой базы и мощностей рабочего железа процесс локального развертывания мог занимать полчаса. Удовольствие очень сомнительное, скажу я вам. Желательно в таком случае иметь тестовые стенды, в которых вы можете подкинуть свои изменения и проверить выполненную работу на них.
3) Деплой монолита — это деплой всех его модулей. Опять же, с ростом кодовой базы процесс становится дольше, отсюда у разных компаний могут появляться свои системы сборки, с точечной оптимизацией процесса развертывания, свои отделы выпусков, которые будут следить за окончанием работ над каждым модулем и соблюдением режима тишины. Буду надеятся, что внутрь подобных систем сборки залить вам не придется :)
4) Иногда разработчикам двух разных модулей приходится ждать друг друга — ведь чтобы запустить сборку изменение второго разработчика, нужно будет дождаться сборки изменений первого. Обычно это касается работы в крупном энтерпрайзе.
5) Масштабируемость. Возможны ситуации, когда определенные модули потребляют ресурсов больше, чем все остальные. К сожалению, нельзя добавить мощностей только для нагруженных модулей, вернее вертикальное масштабирование сервера приложения позволит это сделать, но ВМ конечно. А при горизонтальном масштабировании, добавляя новый экземпляр приложения, мы так же закладываем ресурсы для модулей, которые не нуждаются в дополнительных ресурсах. Как итог — теряем деньги на лишние вычислительные мощности. Не факт, что подобные потери будут велики, но стоит это учитывать. (тут должна быть шутка про то, как AWS выставляет чек на крупную сумму, так как ты не отключил автомасштабирование облака).
6) Сломана нога — умирает весь человек. Если один из модулей падает с критической ошибкой, все приложение падает на пол, вся команда разрабов сидит и чинит прод на выходных, либо же просто сидит отдыхает, пока виновник торжества исправляет ситуацию, отбиваясь от дубликатов ошибок и нависшего над душой менеджера.
7) Использование сторонних технологий. В рамках монолита нельзя использовать разные ЯП(исключения есть, но не о них сейчас). Поэтому резко начать впихивать rust у вас не получится, как использовали php, так и используйте :)