[2/3] Cassandra: The Definitive Guide, 3rd edition (Рубрика Architecture)
В этом посте я продолжаю рассказ об интересной книге по Cassandra (начало в предыдущем посте) и говорю только про шестую главу "The Cassandra Architecture" Эта глава начинается с определения архитектуры
Architecture—fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. —ISO/IEC/IEEE 42010 И дальше начинается интересное
-
Про топологию развертывания кластера, а точнее про датацентры и стойки (racks). Это важно для понимания того, а как обеспечивается отказоустойчивость - для этого в Cassandra есть сплетни (gossip protocols) и детекция сбоев (phi accrual failure detector). И про то и про другое прикольно рассказано в книге "Database Internals", которую мы обсуждали в "CoA" (выпуски раз и два).
-
Про механизм consistent hashing с токенами, кольцом и виртуальными нодами (насайте DataStax есть отличное описание и визуализация). Про то, как работает partitioner, который раскидывает наши партиции по нодам кластера и про стратегии репликации. Дальше наступает время обсудить consistency level и tunable consistency кассандры, которую мы можем выставлять на каждый запрос.
-
Про координацию запроса координирующей нодой, которая от имени клиента взаимодействует с репликами, чтобы обеспечить запрошенный уровень консистентности. Тут появляется такая штука как hinted handoff для write запросов, когда координирующей ноде не удалось записать данные, но она оставила себе напоминание, что надо надо услышав сплетню о возвращении реплики в строй отправить туда write запрос. Тут же появляются темы как бороться с энтропией (anty-entropy) и чинить реплицированные данные (подход Cassandra основан на подходе Amazon Dynamo, про который можно почитать в whitepaper от 2007 года). Тут и пригождается знание алгоритмов и структур данных, например дерева хешей или дерева Меркла (Merkle trees).
-
Про транзакции, точнее lightweight transactions (LWT) и протокол Paxos для достижения консенсуса. Собственно LWT нужно для достижения линеаризуемости, о которой речь шла в знаменитой CAP теореме (подробнее в прошлых постах: Про CAP теорему и Про формализацию CAP теоремы и ее доказательство). Автор объясняет, что чтение с кворума и запись в кворум, которые гарантируют strong consistency, не позволяют предотвратить состояние гонки (race conditions) в случаях, когда клиентам сначала надо прочитать, а потом записать данные. Именно для этого и появляется LWT, который базируется на Paxos (про который надо рассказывать отдельно). Но надо отметить, что
Cassandra’s lightweight transactions are limited to a single partition. А значит мы не можем гарантировать линеаризуемость, если делаем запрос по разным партициям.
- Про внутренее устройство движка хранения данных, где у нас есть Memtables, SSTables, and Commit Logs. Это работает так, что запросы на запись мы пишем в commit log и делаем это durable, а дальше записываем данные в in-memory структуру memtable, где каждая memtable содержит данные для специфичной таблицы Cassandra. Дальше при достижении определенного предела memtable записывается на диск (это уже называется sstable - sorted strings table или отсортированная таблица строк). Таких SSTable на диске много и Cassandra периодически их компактит, производя mergesort (опять тут пригодятся алгоритма для понимания).
Дальше интересно обсудить чтение данных, где нам помогают вероятностные структуры данных, а точнее фильтры Блума (Bloom filters). Они позволяют понять, а есть ли искомая запись внутри конкретной SSTable без full scan. Кроме того используются стратегии кеширования для производительности. Плюс удаление записей с append-only структурой хранения выглядит интересно - мы не можем просто удалить запись, так как надо сохранить tombstone о том, что она удалена. Если мы это не сделаем, то при compaction наши удаленные записи оживут ... и не в виде зомби, а полноценными записями:)
Финал обзора в следующем посте.
#Software #Architecture #DistributedSystems #SystemDesign