Пока искал статью Товеровского, решил почитать мысли Бирмана касательно баланса между жизнью и работой. У самого было странное ощущение от фразы «work life balance», ибо разделение работы, где ты тусишь треть своего дня(хотя скорее всего больше), от жизни в целом выглядит как-то странно. Тут наши мысли совпали, но мне приглянулся еще комментарий Жени Арутюнова , картинки украл из статьи.

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

Какие доклады посетил и могу сказать, что доклад был интересен, какие посетить хотел, но не посетил, что буду смотреть в записи. Посетить все в живую было и остается нереальным, поэтому записи в хорошем качестве — спасение.
Записи докладов будут в открытом доступе летом 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 в модели не будет вовсе, на главное странице оно не нужно.

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