Почему Netflix может стримить 200М пользователей одновременно, а твоя очередная фича задыхается? 🎬 Знакомьтесь, Cassandra


В канале время от времени рассказываю о способах спроектировать систему или каких-то фишках. Но понял, что не хватает ОТ И ДО😎

Вот взять какую-то рабочую систему и препарировать разные концепции. Причем что-то СУПЕР крутое. Что работает во многих Big Tech (Netflix, Apple, Spotify etc) и доказало валидность примененных архитектурных принципов🤨


Apache Cassandra...🙋


Представь, что твоя фича сначала запустилась на маленький город, а потом сразу на всю РФ и весь мир. Пользователи растут быстрее, чем time complexity у двойного цикла😧

До поры до времени можно сделать вертикальное масштабирование. Далее в бой идет горизонтальное. Но тут мы упираемся в сложности масштабирования SQL БД и ограничения движка (B+ Tree)

А теперь представь Netflix. У них сотни миллионов пользователей, которые каждую секунду генерируют данные: что смотрели, где остановились, какие оценки поставили. Ни один, даже самый мощный, сервер в мире этого не выдержит🦉

Именно для таких задач и была создана Cassandra. Вот её суперсилы:

💡 Почти бесконечное горизонтальное масштабирование. Кластеру не хватает мощности? Не нужно покупать сервер-монстр. Просто добавляешь еще одну обычную машину. И еще одну. И еще💪 Cassandra сама распределит данные и нагрузку.

💡 Высочайшая доступность. Cassandra спроектирована так, чтобы не падать. Вообще. В ней нет "главного" узла (master), который мог бы стать единой точкой отказа. Любой сервер может отказать, но кластер продолжит работать как ни в чем не бывало. Для пользователей это выглядит как магия. Для нас, инженеров, — как грамотный дизайн.

💡 Молниеносная запись. Архитектура Cassandra (о ней поговорим отдельно) оптимизирована для экстремально быстрой записи. Данные пишутся последовательно, что является одной из самых быстрых дисковых операций. Её архитектура записи обходит ограничения, с которыми сталкиваются классические B+-деревья в SQL-базах при огромном потоке данных


Конечно, за всё приходится платить. Цена — это другой подход к моделированию данных и так называемая "итоговая согласованность" (eventual consistency).

В ряде следующих постов:
🟣Заглянем под капот и разберемся, как она хранит данные (LSM-деревья)
🟣Поговорим о "сплетнях" между узлами (Gossip-протокол)
🟣Постигнем магию настраиваемой согласованности (QUORUM)
🟣Узнаем, как кластер сам себя лечит (Hinted Handoff, Read Repair)
🟣И, конечно, разберем главные ошибки, которые могут убить твой перформанс

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


😎 - если зашло и ждешь next post

Когда SQL DB больше не справляется: Наследие Amazon Dynamo

В прошлом посте мы с тобой глянули, что Cassandra — это ответ на проблемы экстремального масштаба. Но чтобы понять её гениальность, нам нужно вернуться в прошлое⌛️

Прародителем Cassandra является Amazon Dynamo

И сразу важнейшая ремарка, чтобы ты не запутался:
🟡Dynamo — внутренняя БД Amazon, которая была представлена аж в 2007 году
🟡DynamoDB — это уже современный коммерческий сервис от AWS, который является реализацией и развитием идей из той самой статьи

Cassandra — open-source реализация, вдохновленная именно принципами из статьи Dynamo

Проблема, которую решал Amazon

Представь себе Черную Пятницу на Amazon. Миллионы покупателей одновременно добавляют товары в корзину. Если база данных корзин "моргнет" хотя бы на пару секунд, компания потеряет миллионы долларов.

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

🧷Это привело к созданию системы, построенной на нескольких революционных принципах.


1️⃣ Принцип Always-On Availability (Приоритет доступности)

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

2️⃣ Consistent Hashing и Virtual Nodes

Как тебе распределить данные по 1000 серверов? Наивный подход hash(key) % N (где N — число серверов) ужасен. Как только ты добавляешь или убираешь один сервер, тебе приходится перемещать почти ВСЕ данные 💣

Consistent Hashing решает эту проблему изящно. Представь себе кольцо, на которое помещаются и ID твоих серверов, и хэши ключей данных. Данные сохраняются на ближайшем по часовой стрелке сервере.

Проблема: При таком подходе нагрузка может распределиться неравномерно.
Решение — Virtual Nodes (Vnodes): Вместо того чтобы каждый твой физический сервер был одной точкой на кольце, он представляется множеством "виртуальных" точек.

Что это тебе дает?
🟡Равномерное распределение нагрузки
🟡Гибкое управление кластером при добавлении/удалении узла

3️⃣ Quorum NWR (Настраиваемая согласованность)

Это сердце гибкости Dynamo-подобных систем. Эту концепцию мы с тобой разберем в отдельном посте максимально подробно, с примерами и формулами. Сейчас важно запомнить саму идею:
🟡N — Replication Factor. Сколько копий (реплик) данных ты хранишь.
🟡W — Write Quorum. У скольких из N реплик ты должен дождаться подтверждения записи.
🟡R — Read Quorum. Со скольких из N реплик ты должен прочитать данные.

Если R + W > N, ты получаешь strong consistency (строгую согласованность). А если тебе важна скорость записи, можно выбрать W=1, R=1. Так мы можем управлять балансом между скоростью и согласованностью.

4️⃣ Разрешение конфликтов: Vector Clocks vs. LWW

И вот тут пути Cassandra и Dynamo разошлись😮

Что делать, если из-за проблем с сетью два клиента одновременно изменили один и тот же объект?

🟡Оригинальный Dynamo использовал векторные часы (Vector Clocks). Если конфликт нельзя было разрешить автоматически, обе версии отдавались твоему приложению для ручного разрешения.
🟡Cassandra выбрала более простой путь: Last Write Wins (LWW).

Это правило «побеждает последний» имеет одно огромное последствие, о котором мы тоже поговорим отдельно и очень подробно


🦉Итог

Статья Dynamo — это настоящий манифест распределенных систем. Cassandra взяла эти идеи за основу, адаптировала их и сделала доступными тебе в виде мощного open-source инструмента.


🟡 Оригинальный paper про Amazon Dynamo
🟡 Короткая статья про consistent hashing и vnodes

В следующий раз посмотрим, как именно Cassandra реализует эти принципы в своей masterless-архитектуре и как узлы "сплетничают" друг с другом
🤯 — если мозг немного вскипел, но было интересно
😨 — если плохо разбираешься в моделях консистентности

Архитектура Cassandra: Masterless

В прошлом посте мы с тобой разобрались в принципах из статьи Dynamo. Сегодня посмотрим, как Cassandra превратила эти идеи в реальность.

Готовься, мы погружаемся в самую суть её отказоустойчивости 👨‍🚒

Главный принцип архитектуры Cassandra — Masterless (или Peer-to-Peer). В кластере нет "главного" узла. Все узлы равны. Ты можешь отправить запрос на любой из них, и он будет обработан. Это исключает единую точку отказа и делает систему невероятно живучей.

Держится всё на трёх китах: The Ring, Gossip и Snitch 🐳


1️⃣ The Ring: Как Cassandra понимает, где лежат твои данные

Давай на конкретном примере. Представь, что у нас есть кластер из 4-х узлов: A, B, C, D.


1️⃣ Создание Кольца: Cassandra берет диапазон всех возможных значений хэша (например, от 0 до 2^64-1) и сворачивает его в кольцо

2️⃣ Размещение узлов: Каждому узлу назначается один или несколько токенов (если не читал прошлый пост про VNodes, то глянь). Токен — это просто число из этого диапазона. Допустим, наши узлы получили токены:
🔘Узел A: токен 100
🔘Узел B: токен 400
🔘Узел C: токен 700
🔘Узел D: токен 900

3️⃣ Определение ответственности: Каждый узел становится ответственным за диапазон хэшей от предыдущего токена на кольце до своего собственного
🔘Узел A отвечает за диапазон (901 - 100)
🔘Узел B отвечает за диапазон (101 - 400)
🔘Узел C отвечает за диапазон (401 - 700)
🔘Узел D отвечает за диапазон (701 - 900)

4️⃣ Приходит запрос: Твое приложение хочет сохранить данные пользователя с user_id = 'alex'. Ты отправляешь запрос на любой узел (пусть это будет узел А, он станет координатором)

5️⃣ Вычисление: Координатор берет Partition Key (в нашем случае user_id = 'alex'`), вычисляет от него хэш: `hash('alex') -> допустим, получилось 550

6️⃣ Поиск на кольце: Координатор смотрит на кольцо и определяет, в чей диапазон попадает значение 550. Это диапазон (401-700), за который отвечает узел С.

Вывод: узел C будет хранить первую копию данных (эту копию и называют репликой, replica). Если твой Replication Factor (фактор репликации) равен 3, то Cassandra должна сохранить еще две копии этих же данных. Она разместит их на следующих по часовой стрелке узлах — D и A. Таким образом, узлы C, D, и A являются узлами-репликами для данных пользователя 'alex'.

2️⃣ Gossip Protocol: Как узлы "сплетничают" друг о друге

Окей, но откуда узел A (наш координатор) вообще знает о существовании узлов B, C, D и их токенах? Они "сплетничают" (gossip).

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

Gossip — это децентрализованный и очень надежный механизм обнаружения и мониторинга

3️⃣ Snitch: "Стукач", который делает кластер умнее

Вот ты знаешь, что реплики для 'alex' должны храниться на узлах C, D и A. Но если все они находятся в одной серверной стойке, то при ее отказе ты теряешь данные. Это плохо.

Snitch — это не отдельный сервис и не какой-то "мастер". Это внутренний, настраиваемый модуль внутри каждого узла Cassandra. Его единственная задача — предоставлять информацию о топологии сети. Он как GPS-модуль в твоем телефоне: он не управляет тобой, а просто сообщает твои координаты другим приложениям

Snitch решает эту проблему. И вот как именно работает эта магия:

1️⃣ Шаг 1: Самоопределение. На каждом узле Snitch определяет его физическое местоположение. Например, самый популярный GossipingPropertyFileSnitch читает простой файл cassandra-rackdc.properties, где ты сам прописываешь: dc=dc1 и rack=rack1. Теперь узел знает: "Я в первом дата-центре, в первой стойке".

Продолжение ниже 👇

2️⃣ Шаг 2: Распространение информации. И что дальше? А дальше эта информация о местоположении (`dc1`, `rack1`) добавляется в Gossip-сообщения

Когда узел "сплетничает" с другими, он не просто говорит "я жив", но и "кстати, я нахожусь в dc1, rack1".

3️⃣ Шаг 3: Глобальная карта. Поскольку Gossip-сообщения распространяются по всему кластеру, через несколько секунд каждый узел в кластере имеет полную карту топологии: Узел A: dc1, rack1, Узел B: dc1, rack2, Узел X: dc2, rack5 и так далее.

4️⃣ Шаг 4: Умное размещение реплик. Теперь, когда координатор должен разместить реплики, он использует эту глобальную карту. Он видит, что первая реплика должна быть на узле C (dc1, rack1). Затем, следуя правилам, заданным в Стратегии Репликации (Replication Strategy), он использует эту глобальную карту. Стратегия репликации смотрит на расположение первой реплики (узел C в dc1, rack1) и дает команду разместить остальные копии на узлах в других стойках и дата-центрах


Итог 🏁

🟢The Ring определяет *первичный* узел для данных
🟢Snitch предоставляет информацию о топологии сети
🟢Gossip распространяет всю необходимую информацию на все узлы
🟢Replication Strategy (стратегия репликации) использует эту глобальную карту для умного размещения остальных реплик по разным стойкам и дата-центрам

Все вместе это создает самоорганизующуюся и невероятно живучую систему без единого master


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

Если есть какие-то вопросы, то пиши в комментах💬

В остальном жмакай огонек, если вкатило🔥

Как стать team lead/senior к 25 годам?

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

Так и появился эфир. А самое ценное с эфира расскажу ниже по пунктам

Ты: "Даня, как мне максимально эффективно развиваться, чтобы к X годам стать лидом или сеньором?"


1️⃣ Делаем разнообразные задачи

Иначе говоря: зона комфорта тебя убьет.

Вот скажи мне, ты 100% видел чуваков, которые вроде бы долго работают уже, но все сидят на своем грейде (и чаще всего это не какой-нибудь senior+ с супер крутыми скиллами и ЗП 600к+)

Поэтому уже в зеленые джунские годы нужно просить разные задачи:
🔵На этой недельке делаем API
🔵На след настраиваем стенды для dev/prod и копаемся с helm
🔵Затем проводим нагрузочное тестирование и устраняем недостатки нашего сервиса

Кстати, пункты выше это прям реальные примеры, чем я занимался как junior специалист

Сложно было п**дец, но зато скилуха росла, как на дрожжах

И да, время будет уходить больше, но если ты настроен на быстрый рост (особенно это актуально для junior/middle позиций), то такова цена


2️⃣ Не учимся просто так

Вернее так: не нужно учится всему, так как инфы в IT ну слишком много

Бери разные задачи и в рамках них читай статьи/книги, смотри видео или даже можешь глянуть какой-то курсец.

Но прошу тебя, без типичной ошибки (которая кста была и у меня): "Ща пройду курс на 100 часов по фреймворку и потом начну его использовать"

Как говорил один сеньор: открыл quickstart и погнали

Допом можно проходить курсы, чтобы углубиться в какие-то темы (например, больше узнать про system design или быстро качнуться в каком-то ЯП)


3️⃣ Не сидим ровно, а заявляем о росте

Формула такая: въ*быч + заявление о росте

Если в компании есть performance review, то на них должны быть подвижки. Если получаешь ответы из серии: "ну посмотрим", "давай подождем", то это красный флаг 🚩, что о долгосрочном росте сотрудников не парятся. Тут либо ротироваться, либо искать другую компанию


4️⃣ Учиться в коммуникацию

Это одно из моих любимых

Почему-то ребята в ИТ считают, что коммуникация это не для них. Но вот что я тебе скажу:

Без умения в коммуникацию ты будешь дольше расти. А на ряде позиций вообще не сможешь выполнять задачи

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

Как я качал коммуникацию в свое время:
🔵Проводил внутренние митапы на команду/отдел. Изучил что-то новое, сделал интересную фичу - рассказал. В начале будет сложно, но потом начнешь ловить кайф от умения кристально четко доносить информацию
🔵Сходить на курсы ораторского мастерства

Также используй паттерн: проблема - решение

Многие начинают накидывать, как они решили проблему, не погрузив человека в ситуацию


5️⃣ Если хочется в лида, то есть 2 путя

№1: заявить о желании своему руководителю или skip-level (руководитель +1). И если текущий руководитель уйдет или будет расширение - ты кандидат на эту позицию

№2: зайти в компанию на разработчика с треком роста в лида (обсуждается на финальных секциях)

Я шел по второму этапу

Совет: ищи команды, которые развиваются. Так как у ребят "на поддержке функционала" маловероятно, что будут такие возможности

6️⃣ С точки зрения лида опыт прям супер важен

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

Безусловно, есть много полезных книг/курсов, но сугубо мое мнение: все упирается в умение решать кейсы:
🔵Найм
🔵Увольнение
🔵Нехватка ресурсов (время, люди)
🔵Факапы

И у каждого из пунктов может быть большое кол-во комбинаций. Так что самое крутое это ворваться и на собственной шкуре все понять + получать ОС от опытного руководителя в компании


7️⃣ Заграницей также можно кайфово жить

Не хватает букв в посте ТГ...


Если пост наберет 50 ♥️, то напишу вторую часть

А если есть вопросы, то пиши в комментах💬

gRPC медленнее REST? Кейс из прода

Лови недавний прикол из прода. Внедрили gRPC, ждали космос по перфомансу, а тайминги... выросли по сравнению с обычным REST 🤦‍♂️

Начали копать. Оказалось, мы забыли включить сжатие. В gRPC оно по дефолту ВЫКЛЮЧЕНО

И это не баг либы, а фича и осознанное проектное решение gRPC

Все дело в трейд-оффе: CPU 💻 vs Сеть 🌐. Но на решение, сжимать или нет, влияют два главных фактора:

1️⃣ Скорость сети
Внутри одного дата-центра на 40 Gbit/s и в мобильной сети 3G — это две разные вселенные. Для медленных сетей (интернет, мобилки) сжатие — почти всегда must-have, потому что сеть — главное узкое место.

2️⃣ Объем данных (payload)
А вот это — ключевой момент, который мы тоже упустили!
🟣Если ты гоняешь мелкие, частые запросы типа ping или getUser_by_id, выигрыш от сжатия может быть съеден затратами CPU.
🟣Но если ты передаешь большой объем данных (список на 1000 объектов, файл, JSON на мегабайт), то сжатие даст огромный буст ДАЖЕ на сверхбыстрой сети. Выигрыш во времени от уменьшения payload (с 10 МБ до 1 МБ) всегда больше, чем траты CPU на сжатие этих данных


🤔 «Но ведь там Protobuf, он же и так компактнее JSON?»
Да, Protobuf — это эффективный формат. А Gzip — это алгоритм сжатия поверх него. Для маленьких сообщений разница будет невелика. Но на больших объемах Gzip находит и сжимает повторяющиеся последовательности в данных, и экономия будет колоссальной. Это два разных, дополняющих друг друга уровня оптимизации.

TL;DR

🟣Это не баг, а фича для тонкой настройки производительности
🟣Когда включать сжатие (Gzip):
- Связь идет через интернет/WAN/мобильную сеть
- Передаются большие объемы данных (даже в быстрой сети)
🟣Когда можно не включать (и протестировать)?
- Сервисы в одной быстрой сети (ДЦ, Kubernetes) и гоняют друг другу много мелких, частых сообщений

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

Если не сталкивался раньше с таким, то ставь🔥

Как добиться молниеносных записей в БД

Мы с тобой уже разобрались в прошлом посте, что Cassandra — это децентрализованная система без единого master. Мы много говорили о том, что она оптимизирована для молниеносной записи. Сегодня пора разобраться, как именно достигается эта магия.

Почему B-Tree не всегда подходит?

В большинстве реляционных баз данных (PostgreSQL, MySQL) используется структура данных B+-Tree. Она отлично подходит для сбалансированного чтения и записи. Но когда тебе нужно обновить строку, B-Tree-движку часто приходится:

1️⃣ Найти на диске нужный блок данных (random read).
2️⃣ Загрузить его в память.
3️⃣ Изменить данные.
4️⃣ Записать обновленный блок обратно на диск (random write).

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


LSM-дерево

Cassandra говорит: "Давай не будем ничего изменять на диске. Будем просто дописывать новое в конец!". Эта концепция лежит в основе Log-Structured Merge-Tree (LSM-дерева).

Давай посмотрим на путь запроса на запись

1️⃣Шаг 1: Запись в Commit Log (Гарантия надежности)

Как только узел-реплика получает данные для записи, он первым делом дописывает их в специальный файл на диске — Commit Log

🟡По сути, это "черный ящик" самолета. Простой файл, в который последовательно дописываются все входящие операции. Последовательная запись — это самая быстрая операция с диском.

🟡Зачем? Только для одной цели: восстановления данных в случае сбоя. Если узел внезапно перезагрузится, он при старте прочитает Commit Log и восстановит в памяти все данные, которые не успел сохранить на диск в основном хранилище.

2️⃣ Шаг 2: Запись в Memtable

Одновременно с Commit Log, данные записываются в структуру в оперативной памяти — Memtable
🟡Что это? Отсортированная по ключу таблица в RAM. Все новые данные и обновления попадают сюда. Поскольку все происходит в памяти, это невероятно быстро.
🟡Зачем? Чтобы собирать и сортировать данные перед их записью на диск.

3️⃣Шаг 3: Подтверждение клиенту

И вот он, ключевой момент!

Как только данные записаны в Commit Log (на диск) и в Memtable (в память), узел отправляет твоему приложению подтверждение: "ОК, я всё сохранил"

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

Данные уже находятся на диске, но только в виде быстрой, последовательной записи в Commit Log. Этого достаточно, чтобы Cassandra могла гарантировать, что данные не потеряются даже при внезапном отключении питания. Узел знает: "Если я упаду, я проснусь и восстановлю все из этого лога"

Но при этом данные еще не лежат в своей финальной, структурированной форме — в отсортированном файле SSTable.

Сложная и медленная работа по организации данных в SSTable откладывается на потом и выполняется в фоновом режиме.

Аналогия: Представь, что тебе нужно разобрать тонну почты.
🟡Медленный путь (как B-Tree): Взять каждое письмо, найти нужную папку на полке, положить письмо, вернуться за следующим
🟡Быстрый путь (как Cassandra): Сначала быстро скидать всю почту в один большой ящик (Commit Log + Memtable) и сказать начальнику "Вся почта принята!". А уже потом, когда будет время, спокойно разобрать этот ящик по папкам (SSTable)

Cassandra дает "ОК" сразу после первого, самого быстрого шага. В этом и заключается ее "обман", позволяющий достичь феноменальной скорости записи.

4️⃣Шаг 4: Сброс на диск в SSTable (The Flush)

Рано или поздно Memtable в памяти заполнится. Когда это происходит, Cassandra:
1️⃣ "Замораживает" текущую Memtable (она перестает принимать новые записи).
2️⃣ Создает новую, пустую Memtable для обработки поступающих запросов.
3️⃣ Асинхронно, в фоновом режиме, сбрасывает данные из замороженной Memtable на диск в виде нового файла.

Этот файл называется SSTable (Sorted String Table)

Продолжение ниже

У него два свойства:
🟡Неизменяемый (Immutable): После того как SSTable создан, он больше никогда не изменяется. Никогда. Если тебе нужно обновить или удалить данные, Cassandra просто создаст новый SSTable с более свежей версией или специальной меткой удаления (tombstone).
🟡Отсортированный (Sorted): Данные внутри SSTable отсортированы по ключу, что в будущем ускорит их чтение.

✏️Итог: Путь записи целиком

1️⃣ Запрос на запись -> Узел-реплика.
2️⃣ Commit Log (последовательная запись на диск для надежности).
3️⃣ Memtable (запись в RAM для скорости).
4️⃣ Подтверждение клиенту ("ОК").
5️⃣ (Позже, в фоне) Memtable заполнена -> Сброс на диск в новый, неизменяемый SSTable.

Но подожди... если мы постоянно создаем новые и новые файлы (SSTable) и никогда их не изменяем, то:
1️⃣ Как потом читать данные, если они размазаны по десяткам или сотням файлов?
2️⃣ Что происходит при удалении?
3️⃣ Дисковое пространство не забьется ими до отказа?

На все эти вопросы отвечает фоновый процесс, который называется Compaction. И это — тема нашего следующего поста.

👍 - если все усвоил и теперь понимаешь, как работает LSM

Compaction: механизм в любых соверменных write-heavy БД

В прошлом посте мы оставили Cassandra в интересном положении: она постоянно создает новые, неизменяемые файлы (`SSTable`) на диске. Это обеспечивает молниеносную запись, но порождает три серьезных вопроса, которые ты, возможно, уже себе задал:

1️⃣ Как читать данные?
Если одна и та же строка обновлялась 10 раз, ее версии размазаны по 10 разным SSTable-файлам. Чтобы найти последнюю версию, придется заглянуть во все 10? Звучит медленно

2️⃣ Куда девается мусор?
Старые версии данных и удаленные строки просто лежат на диске и занимают место. Это неэффективно

3️⃣ Как работают удаления?
Если SSTable-файлы неизменяемы, как вообще можно что-то удалить?


Ответ на все эти вопросы один: Compaction

Кстати, данный механизм используется во всех современных БД и Engine DB, нацеленных на распределенность и большую нагрузку: ScyllaDB, RocksDB, Google Bigtable

Что такое Compaction?

Compaction — это фоновый процесс, который занимается слиянием и уплотнением SSTable-файлов. Это внутренняя "уборщица" и "оптимизатор" Cassandra.

Процесс выглядит так:
1️⃣ Cassandra берет несколько SSTable-файлов
2️⃣ Читает их содержимое, строка за строкой
3️⃣ "На лету" сливает данные, следуя простым правилам:
- Данные с одинаковым ключом? Берем только версию с самой свежей временной меткой (timestamp). Все старые версии выбрасываем
- Встретили метку удаления (Tombstone)? Если мы нашли и саму метку, и данные, которые она помечает к удалению, мы можем их безопасно выбросить (при условии, что прошло достаточно времени — gc_grace_seconds — чтобы эта информация разошлась по кластеру)
4️⃣ Записывает результат в один, новый, чистый SSTable
5️⃣ После успешного создания нового файла, старые, "грязные" SSTable удаляются

Аналогия: Представь, у тебя есть 5 версий одного и того же документа Word. Чтобы навести порядок, ты открываешь их все, копируешь самые свежие параграфы из каждого в новый, шестой документ, а старые 5 удаляешь. Compaction делает то же самое, но с данными.


Зачем это нужно? Ключевые цели Compaction:

✅ Улучшение производительности чтения. Вместо того чтобы искать данные в 50-ти маленьких файлах, Cassandra будет искать их в одном большом, что гораздо быстрее
✅ Освобождение дискового пространства. Старые, ненужные версии данных и окончательно удаленные строки физически стираются с диска.
✅ Обеспечение целостности данных в долгосрочной перспективе.


Не все compaction одинаковы:

Compaction — это не просто "взять и слить". Это ресурсоемкая операция (I/O, CPU). Поэтому Cassandra предлагает разные стратегии для разных типов нагрузки. Выбор неправильной стратегии — один из верных способов "убить" производительность кластера.


Краткий обзор трех основных:

🔵SizeTieredCompactionStrategy (STCS): Стратегия по умолчанию. Сливает SSTable примерно одинакового размера. Хорош для write-heavy load
🔵 LeveledCompactionStrategy (LCS): Организует данные по "уровням", где каждый следующий уровень в 10 раз больше предыдущего. Более затратное по I/O, но делает чтение более эффективным
🔵TimeWindowedCompactionStrategy (TWCS): Группирует данные по временным окнам (например, день). Идеально для time-series


Итог 👍

Compaction — это критически важный фоновый процесс, который поддерживает "здоровье" кластера Cassandra. Он борется с фрагментацией данных, освобождает место и делает чтение быстрым. Понимание и правильная настройка стратегии compaction — это ключ к стабильной и производительной работе с Cassandra

Теперь, когда мы знаем, как Cassandra пишет и убирает за собой, пришло время разобраться, как она все это находит. В следующем посте мы пройдем полный путь чтения (релевантный для многих современных БД)

💯 — если стало понятнее, как устроен "движок" Cassandra

Уволен из Яндекса за 1 косяк с БД

И это реальная история, которая произошла на неделе в Яндекс Такси 🚕

Вот тебе нужно сделать изменения в реплику MongoDB. Под репликой имеется в виду не master-slave, а прям отдельное хранилище, в которое уезжают все данные

Внешняя реплика - частое решение в Big Tech. Оно позволяет:
🟡Другим разработчикам изучать структуру данных сервиса
🟡Аналитикам проводить расчеты без ssh в твой сервис
🟡Повышает отказоустойчивость: если с основной БД какие-то проблемы
🟡Заложить ряд процессов на эту реплику. Тут надо быть осторожнее, но иногда для скорости решения идут на такие действия


Одному разработчику нужно было добавить колонку в эту реплику. И по определенной причине стандартные настройки правил репликации в эту реплику (делается через .yaml файлы) не работали

Поэтому он сгонял к maintainers и спросил: "А можно дропну и заново накачу?". Ответ был получен положительный.

А ТЕПЕРЬ ВНИМАНИЕ: по сути он сделал мини-PR, в котором удаляется реплика, а потом опять стартует наливка из MongoDB.

Но за ОК пошел в чат к человеку из своей же команды, а не maintainers. Второй чувак сделал "ок не глядя"


И что по итогу?

Ну, в Южной Америке 70% бизнеса Яндекс Доставки не работали полдня. Был ряд сложностей с Яндекс Такси в Узбекистане. А еще Таксопарки не получали инфу о штрафах машин, не могли смотреть отчеты по тачкам около 2-ух дней

Думаю, что все осознают потенциальные потери бизнеса от этой поломочки... 🪙

Почему все рухнуло: разработчик ожидал, что реплика нальется быстро. Но просчитался в объеме данных и скорости переливки. По итогу вместо посчитанных пары часов все происходило около пары суток.


А еще НЕ fun fact:

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

В то же время чуваки из Доставки📦 экстренно вносили фиксы. Вторая часть моей команды также не была в курсе и поэтому экстренно вносили фиксы по Узбекистану и тачкам


Что нужно было сделать иначе ✏️

1. Перепроверить свои расчеты по объему данных в БД и реплике. Далее еще раз понять, какая скорость синхронизации данных между этими сущностями

2. Проверить, что нет учений на ближайшие дни. Так как на время учений часто закрывают какой-то ДЦ. И это тоже может выстрелить при синхронизации данных. Почему? Так как в Яндексе есть правило, что ОК по INSERT/UPDATE будет получен только после синка данных на 2-ух ДЦ

3. Нести PR не своей команде, а maintainers

Здесь еще был косяк с ролями. Почему-то не только maintainers могли окнуть его. Но это уже разбирали после

Почему это критично: если бы ОКнули maintainers, то это их головная боль и косяк. А так получается, что косяк создателя PR и ОКающего PR

4. В момент осознания инцидента: создать чат по инциденту

5. После инцидента заполнить тикет с подробностями о причинах, тригерах, приложить всю необходимую доп инфу

6. Придти на разбор инцидентов и проговорить с коллегами, как такое могло произойти и как не допускать такого в будущем

Есть такой термин: blameless culture😳

В инциденте виноват не кто-то 1, а группа людей. Допустим, у нас упал прод. Кто виновать? Разработчик написал такой вот код, но его проревьюил другой разработчик. Затем QA плохо проверил. И еще руководитель, что нанял таких людей

И в целом так часто и бывает, что не ищут "козла отпущения". В данном случае, допустим, был косяк с ролями. И не только maintainers могли окать. Но вот отсутствие чата с инцидентом и сокрытие - жесткий косяк для опытного разработчика.

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

PS: Этого разработчика и "окаря" по итогу не стали увольнять, но оценку "ниже ожиданий" на ревью могут получить как нефиг

Секция с кодом захватила весь РФ Big Tech

Именно под таким слоганом пройдет следующий открытый урок.

TL;DR секция с кодом это «Язык и Платформа», «Кодинг секция» и прочие варианты названий

Уже 3 дня готовлюсь к уроку, так как инфы супер много (особенно вокруг БД и работы с конкурентностью). И это я еще не начинал разбирать примеры задач из красного поисковика🖥

Буду рассказывать про
🟡Особенности секции в разных Big Tech
🟡Какие задачи спрашивают. Причем не просто ответы, а почему именно такое решение. Чтобы прокачать слушателей как инженеров
🟡Как тебя будут оценивать

Если стало интересно и послушал бы потом данный урок, то ставь ❤️

Путь чтения в LSM индексах: как найти иголку в стоге сена

В прошлом посте мы выяснили, что Cassandra ради скорости записи создает на диске десятки файлов - SSTable. Это порождает главный вопрос: "Окей, а как потом эффективно все это читать?"

Давай пройдем путь твоего SELECT запроса и посмотрим, чего стоит эта скорость.

1️⃣ Шаг 1: Поиск ответственных реплик

Ты отправляешь запрос SELECT * FROM users WHERE user_id = 'alex'; на любой узел кластера (он становится координатором)

Координатор не ищет данные "по всему миру". Он использует The Ring (разбирали в этом посте), чтобы по ключу alex мгновенно определить, какие именно узлы отвечают за эти данные. Это узлы-реплики. Именно им (и только им) он и отправляет запросы на чтение.

2️⃣Шаг 2: Сбор данных внутри узла-реплики

Каждый узел-реплика должен найти данные для alex у себя. А они могут быть в двух местах:
- В Memtable в памяти
- В десятках SSTable-файлов на диске

Просто сканировать все SSTable — это катастрофа для производительности. Поэтому Cassandra использует арсенал хитростей, чтобы минимизировать чтение с диска.

Как избежать сканирования диска

🟡 Фильтр Блума (Bloom Filter)

Прежде чем трогать SSTable-файл, Cassandra задает вопрос его Фильтру Блума: "Есть ли ключ alex в этом файле?"

Ответ "Точно нет" ▶️ Cassandra пропускает этот файл и экономит кучу дисковых операций

Ответ "Может быть, да" ▶️ Это не 100% гарантия, но сигнал, что нужно проверить этот файл внимательнее

🟡Кэши и "оглавление" — ищем точный адрес

Итак, Фильтр Блума сказал "может быть". Теперь нужно найти ключ внутри SSTable

Сначала Cassandra проверяет Partition Key Cache. Это кэш в памяти для "горячих" ключей, где хранятся их прямые адреса на диске. Если повезло — мы сразу прыгаем в нужную точку файла.

Если в кэше пусто, Cassandra смотрит в Partition Summary. Это как "оглавление" для SSTable, тоже в памяти. Оно не дает точный адрес, но помогает определить небольшой диапазон на диске, который нужно просканировать.

И только после всех этих оптимизаций Cassandra обращается к диску и читает один небольшой блок данных.

3️⃣Шаг 3: Финальное слияние

1️⃣ Каждый узел-реплика собирает все найденные версии данных для alex из Memtable и SSTable и отдает их координатору
2️⃣ Координатор получает ответы от всех реплик
3️⃣ Он применяет правило Last Write Wins (LWW): из всех полученных версий он выбирает одну — с самой свежей временной меткой
4️⃣ Эта финальная версия возвращается твоему приложению

Смотри схему в посте, которая наглядно показывает процесс чтения

Финал 👌

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

Теперь ты видишь, почему для Cassandra так важны правильная модель данных (чтобы запросы были по Partition Key) и настроенный Compaction (чтобы SSTable-файлов было поменьше)

А в следующем посте этой серии поговорим про согласованность данных в кластере

〰️〰️〰️〰️〰️〰️〰️〰️〰️

Именно понимание согласованности критически важно для работы с распределенными системами.

А если ты не понимаешь проблем распределенных систем или же не работал в прошлом - звоночек, что пора что-то менять. Именно по этой причине большая часть кандидатов не проходит финальные секции в Яндекс

Большинство распределенных БД не гарантируют заявленный уровень надежности

Есть ребята из Jepsen — они профессионально ломают распределённые системы: делают перебои сети, имитируют сбои и смотрят, что реально происходит с данными (Kafka, Cassandra, Zookeeper etc)

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

Почему это важно для тебя как разработчика/архитектора:
🔵Ты строишь поверх БД бизнес-логику, которая не должна ломаться
🔵“eventual consistency” vs “linearizability” — это не теоретическая разница, а реальные баги в деньгах, заказах и транзакциях
🔵Выбор БД сводится к пониманию гарантий БД и требований твоей системы

Поэтому если хочешь заиспользовать какое-то решение для распределенных систем - изучи кейсы внедрения и какие ошибки были найдены

Одна из самых сложных систем, которую спрашивают в Ru Big Tech

Недавно гонял на собес в один Big Tech и был на секции system design. Решил рассказать про систему, которую давали😼

Очень часто на собеседовании тебя просят задизайнить что-то eventual consistency подобное. Где данные в одной части системы могут временно отличаться от другой.

Или же, где механики позволяют делать запросы к мастеру. Допустим, твоя страница ленты идет к мастеру, а у остальных пользаков - к slave

Но что если тебя просят задизайнить что-то, где требование строгой согласованности важнее доступности?

Вот здесь и выступают на первый план
🟢CAP теорема
🟢Понимание репликации внутри 1 ДЦ и кросс-ДЦ
🟢Что такое rack в ДЦ и почему важно реплицировать данные между разными стойками внутри 1 ДЦ
🟢Модели консистентности: weak, eventual, causal, strong
🟢Распределенные блокировки


Тема достаточно сложная, но распишу ряд шагов, которые упростят твое проектирование

0️⃣Обстучали функциональные требования
Не сразу бросились считать что-то, а проговорили с интервьюером, правильно ли понимаем задачу

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

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

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

1️⃣Посчитали нефункциональные требования

Хоть мы и создаем счета и переводим деньги - запрос текущего баланса является гораздо более частой операцией.

read / write = 2/1

2️⃣Раскидали домены
База, про которую уже много раз говорили.
Не кидаемся проектировать слепо

3️⃣Проектируем все в рамках 1-го ДЦ и даже 1 сервера
Не нужно бросаться делать сложную систему на весь мир.

Идем поступательно
🟢Как гарантировать синхронизацию данных в рамках 1 инстанса БД. А как в рамках двух инстансов? Тут вспоминаем про синхронные и полусинхронные репликации. А также про ack от хотя бы 2-ух ДЦ
🟢Как делать блокировки в рамках 1-го инстанса и далее в рамках 2 и более? Для 1-го можно обойтись optimisitc или pessimistic locking. Но вот для распределенных систем такое решение уже не подойдет
🟢Как данные могут потеряться при переводах?

4️⃣Масштабируем систему
Здесь погружаемся в сложности, которые упомянули в прошлом пункте.

Также не забывай, что данные нужно синхронить между ДЦ. Будем ли использовать MirrorMaker, встроенные решения у NewSQL (CockroachDB, YDB) или самописные велики?

Не забываем про majority rule для машин в кластере

Также смотрим на профиль нашей системы: можно выделить в разные сервисы чтение и запись и масштабровать их отдельно.

5️⃣Помним про безопасность
Не паримся и используем готовые IdP решения по типу Keyсloak

6️⃣Как будем раскатывать?
По регионам/юзерам или как-то еще? Здесь лучше взять canary release и продумать механику плавного открытия

7️⃣Метрики, надежность и все вокруг этого


Сохрани эти заметки для проектирования подобных систем

Принцип, которому следуют все распределенные БД

Продолжим серию постов про устройство больших систем на примере Cassandra.

По дефолту Cassandra - AP система (Availability > Consistency). Но ее крутость в том, что она дает тебе возможность управлять этим компромиссом. Это можно делать благодаря Consistency Level (CL, Уровень Согласованности)

Вспоминаем базу

🟡Replication Factor (RF): Сколько всего копий данных хранится в кластере. Обычно 3
🟡Координатор: Узел, который получил твой запрос и управляет его выполнением на других узлах. Прочитать подробнее можешь в этом посте

Consistency Level — это правило для координатора: от скольких реплик нужно дождаться ответа, чтобы считать операцию успешной.

Давай разберем самые популярные уровни на примере RF = 3

🚀 CL = ONE: быстро и просто

🟡Как работает: Координатор ждет ответа от одной ближайшей реплики и сразу говорит "ОК"
🟡Плюсы: Максимальная скорость. Запрос успешен, даже если 2 из 3 реплик лежат
🟡Минусы: Ты можешь записать данные, а при следующем чтении попасть на узел, который еще не успел их получить, и увидеть старую версию
🟡Когда использовать: Лайки, счетчики просмотров, логи — там, где скорость важнее 100% точности в моменте.

🐢 CL = ALL: надежно, но долго

🟡Как работает: Координатор ждет ответа от всех реплик
🟡Плюсы: Гарантия, что все копии данных идентичны прямо сейчас
🟡Минусы: Если хотя бы одна реплика недоступна, запрос упадет
🟡Когда использовать: Крайне редко. Например, при изменении пароля, но и то с оговорками. В 99% случаев есть варианты получше

⚖️ CL = QUORUM: золотая середина

🟡Как работает: Координатор ждет ответа от большинства реплик. Формула: (RF / 2) + 1. Для RF=3 это 2
🟡Плюсы: Отличный баланс. Кластер переживет отказ одной реплики
🟡Минусы: Медленнее, чем ONE

Есть и другие уровни (TWO, THREE, LOCAL_QUORUM), но эти три — основа, с которой ты будешь работать чаще всего. Можешь более подробно глянуть про них вот здесь


Главная суть в формуле: R + W > N

Вот тут важный момент. Cassandra — это eventual consistency система. Но с помощью CL ты можешь добиться поведения, очень похожего на строгую согласованность, для конкретных операций.

Формула проста: R + W > N
🟡N — твой Replication Factor (например, 3)
🟡W — CL для записи (Write)
🟡R — CL для чтения (Read)

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

Пример:
N = 3
🟡Ты пишешь данные с W = QUORUM (ждешь ответа от 2 реплик)
🟡Ты читаешь данные с R = QUORUM (читаешь с 2 реплик)

Подставляем: 2 (R) + 2 (W) > 3 (N). Условие выполняется.

Почему это работает?

Из-за пересечения множеств. Если ты успешно записал данные на 2 из 3 узлов, а потом читаешь с 2 из 3, эти два множества гарантированно пересекутся как минимум на одном узле. А значит, ты обязательно зацепишь узел с самой свежей версией данных

Итог 🏁

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

🟡Нужна скорость? W=ONE, R=ONE
🟡Нужен баланс и надежность? W=QUORUM, R=QUORUM

Данный принцип используется во многих БД и системах (MongoDB, CockroachDB)

В следующий раз поговорим о том, что происходит, когда узел все-таки падает, и как Cassandra лечит сама себя с помощью Hinted Handoff и Read Repair

🔥 - если понял про устройство quorum

Одна из самых подлых ошибок в распределенных системах

Сегодня расскажу про один из самых подлых классов отказов в распределённых системах — metastable failures. Изначально кажется, что это редкое событие, но на самом деле систематичное и предсказуемое, если знать, на что смотреть


Что это? 🙋

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

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

Ключевой момент: это не обычный overload системы. Система может запросто работать при той же нагрузке в нормальных условиях.

Проблема в цикле ошибок, которые не дают системе выбраться.


Три фазы коллапса

1️⃣Stable — система работет стабильно. Какие-то сбои/ошибки не выводят систему
2️⃣Vulnerable — система работает эффективно, но есть явные риски, что может что-то пойти не так
3️⃣ Metastable — триггер кинул систему в цикл проблем, из которого она уже не вылезает сама


Классический пример: Retry storm

Система обрабатывает 280 RPS нормально. Клиенты при таймауте делают 2 retry.

Случается короткий сетевой сбой. Когда связь восстанавливается, все пакеты ретранслируются, нагрузка скачет до 560 RPS. БД начинает отвечать долго, запросы таймаутят... и вместо 280 RPS система получает 560+ RPS в виде волны retry

БД не может справиться, latency растёт, timeout timeout timeout — система заходит в цикл. Даже если сетевой сбой уже прошёл, система остаётся перегруженной потому что сама себе создаёт нагрузку

Клиенты получают только таймауты.


Другие примеры

🔵Cache cold start: теплый кэш даёт 90% hit rate, но если процесс крэшнулся и кэш потерян? Вдруг 10x нагрузка на БД → БД захлёбывается → кэш так и не заполняется. Тут стоит сказать, что базово решение "поставил кеш → спас БД от перегруза" - плохое. БД должна выдерживать нормальную нагрузку системы

🔵Slow error handling: когда система начинает падать, код начинает выполнять дорогие операции (stack traces, DNS lookups, логирование). Это требует ресурсов, которых уже не хватает → система падает быстрее → еще больше ошибок → еще больше ресурсов на обработку ошибок.


Почему это опасно?

🔵Не предсказать: проверяется только в production под высокой нагрузкой
🔵Не очевидна причина: в архитектуре не всегда понятно, какой узел вызвал проблему
🔵Каскадная: может распространяться через весь стек микросервисов


Как защищаться?

1️⃣Load shedding — отбрасывай лишние запросы, когда overload

2️⃣Adaptive retries — умные retry с token bucket

3️⃣Goodput monitoring — смотри на полезную работу, которую систему выполняет, а не только на сухой RPS

4️⃣Chaos engineering — специально убивай дата-центры, перезагружай кэши, создавай сетевые задержки. Если система не восстанавливается без вмешательства → metastable failure

🤝 Prioritization — важные запросы обслуживай первыми даже при overload системы

6️⃣Fast error paths — оптимизируй не только happy path, но и error handling (batch logging, sample stack traces)


TL;DR

Metastable failures — это когда система попадает в цикл проблем и долго выбирается/не выбирается сама. Триггер может быть маленький, а последствия — часовые сбои

Если раньше не знал о metastable failures и зашло, то ставь 👨‍💻

Ходи раз в год на собесы

Вчера проводил эфир “Самая важная секция в Big Tech”, где разбирали секцию про прошлый опыт и в целом как записывать свой опыт, как правильно делать задачи

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

Я сам недавно проходил собесы на Team Lead в один Big Tech РФ.

И это не так сложно, как кажется. Если ты идешь "в разведку"

1️⃣Можно не готовиться. Тебе не страшен провал. Ты скорее импромпту проходишь секции и смотришь на свой уровень

2️⃣Ты не тратишь много времени, так как не готовишься

3️⃣Да, после собеса ты чуток выжатый (вчера был собес, а потом через час открытый урок😑 ). Но в целом это терпимо

В конце 2024 я таким образом получил оффер от VK на 600к+ net совокупного. В 2025 от Авито. Сейчас еще один потенциальный оффер💸

Так что будь в рынке и делай "диагностику" своих знаний и опыта

В следующем посте расскажу основные моменты с вчерашнего открытого урока. Поставь 🔥и пост выйдет раньше 🙂