Cassandra Archiтектура и фактор репликации
Редакционная коллегия
⚡ Умное резюме
Cassandra Архитектура распределяет данные между узлами-партнерами, исключая единую точку отказа, используя механизм обмена данными для координации и репликацию для обеспечения отказоустойчивости. На этой странице описаны все компоненты, стратегии репликации, уровни согласованности, а также внутренние пути записи и чтения.
Cassandra предназначен для обработки Big Data. CassandraОсновная особенность — хранить данные на нескольких узлах без единой точки отказа.
Причина такого рода CassandraАрхитектура 's была такова, что отказ оборудования мог произойти в любое время. Любой узел может быть отключен. В случае отказа могут быть использованы данные, хранящиеся в другом узле. Следовательно, Cassandra разработан с использованием распределенной архитектуры.
Cassandra хранит данные на разных узлах с использованием одноранговой распределенной архитектуры.
Все узлы обмениваются информацией друг с другом, используя Протокол сплетен. Сплетни – это протокол Cassandra с помощью которых узлы могут взаимодействовать друг с другом.
Компоненты Cassandra Archiтекстура
В состав входят следующие компоненты: Cassandra Archiтекстура:
Приведенная выше диаграмма показывает вложенность компонентов: узлы находятся внутри центра обработки данных, центры обработки данных находятся внутри кластера, а журнал фиксации транзакций, memtable и SSTable находятся внутри каждого отдельного узла.
Узел
Узел — это место, где хранятся данные. Это базовый компонент Cassandra.
Центр обработки данных
Совокупность узлов называется центром обработки данных. Многие узлы относятся к категории центров обработки данных.
Cluster
Кластер представляет собой совокупность множества центров обработки данных.
Журнал фиксации
Каждая операция записи записывается в журнал фиксации. Журнал фиксации используется для восстановления после сбоя.
Mem-таблица
После записи данных в журнал фиксации данные записываются в Mem-таблицу. Данные временно записываются в Mem-таблицу.
Таблица SSTable
Когда количество данных в Mem-table достигает определенного порога, данные записываются в дисковый файл SSTable. SSTable-файлы являются неизменяемыми, поэтому при обновлении записывается новая версия, а не редактируется старая, а фоновый процесс, называемый компактированием, позже объединяет эти версии и удаляет замененные строки.
Репликация данных в Cassandra
Поскольку в любой момент во время обработки данных может возникнуть проблема с оборудованием или соединение может быть отключено, необходимо найти решение, обеспечивающее резервное копирование в случае возникновения проблемы. Таким образом, данные реплицируются, чтобы исключить единую точку отказа.
Cassandra размещает реплики данных на разных узлах на основе этих двух факторов.
- Место размещения следующей реплики определяется Стратегия репликации.
- При этом общее количество реплик, размещенных на разных узлах, определяется Фактор репликации.
Один коэффициент репликации означает, что существует только одна копия данных, а три фактора репликации означают, что существует три копии данных на трех разных узлах.
Чтобы гарантировать отсутствие единой точки отказа, коэффициент репликации должен быть равен трем.
Существует два типа стратегий репликации. Cassandra.
SimpleStrategy в Cassandra
SimpleСтратегии используется, когда у вас только один центр обработки данных. SimpleStrategy размещает первую реплику на узле, выбранном разделителем. После этого оставшиеся реплики размещаются по часовой стрелке в кольце узлов.
Вот графическое представление SimpleStrategy:
Топология сетиСтратегия в Cassandra
NetworkTopologyСтратегия используется, когда у вас более двух центров обработки данных. В NetworkTopologyStrategy реплики задаются для каждого дата-центра отдельно. NetworkTopologyStrategy размещает реплики по кольцу по часовой стрелке, пока не достигнет первого узла в другой стойке. Эта стратегия пытается разместить реплики на разных стойках в одном центре обработки данных.
Это связано с тем, что иногда в стойке может возникнуть сбой или проблема. Тогда реплики на других узлах смогут предоставлять данные.
Вот графическое представление стратегии топологии сети:
Коэффициент репликации определяет количество существующих копий. Количество копий, которые должны отвечать на данный запрос, — это отдельная настройка, описанная далее.
Уровни стабильности в Cassandra
Уровень согласованности устанавливается для каждого запроса, а не для всего кластера, что и обеспечивает... Cassandra Настраиваемый параметр. Он определяет, сколько реплик должны подтвердить запись или ответить на чтение, прежде чем координатор ответит клиенту. Низкоуровневый параметр обеспечивает более быструю обработку; высокоуровневый параметр возвращает данные, которые с большей вероятностью являются актуальными.
| Уровень | Поведение | Типичное использование |
|---|---|---|
| ONE | Ответить должна одна копия. | Высокопроизводительная регистрация данных, где допустимо периодическое появление устаревших показаний. |
| QUORUM | Большинство всех реплик должны ответить, что рассчитывается как (RF / 2) + 1. | Универсальный вариант, обеспечивающий сбалансированную стабильность характеристик и доступность. |
| ЛОКАЛЬНЫЙ_КВОРУМ | Большинство реплик в локальном центре обработки данных должны ответить. | Кластеры, состоящие из нескольких центров обработки данных, позволяют избежать задержек между регионами. |
| BCE | Каждая копия должна ответить. | Редкое явление. При отключении одного из узлов запрос полностью завершается неудачей. |
| ЛЮБОЕ (только для записи) | Намек на передачу считается успехом, даже если получить копию невозможно. | Максимальная доступность записи при условии, что требования к надежности могут быть смягчены. |
Строгая согласованность гарантируется, когда сумма уровня чтения и уровня записи превышает коэффициент репликации. При коэффициенте репликации, равном трём, запись в КВОРУМЕ и чтение в КВОРУМЕ удовлетворяют этому правилу, поскольку два плюс два больше трёх. Запись в ЕДИНИЦЕ и чтение в ЕДИНИЦЕ не удовлетворяют этому правилу, и поэтому при чтении может быть возвращено более старое значение.
Когда реплика недоступна, координатор сохраняет намекать и воспроизводит его повторно, как только узел возвращается, именно так работает любой уровень и большая часть контента. CassandraСамовосстанавливающееся поведение работает.
Написать Operaция в Cassandra
Координатор отправляет запрос на запись репликам. Если все реплики работают, они получат запрос на запись независимо от их уровня согласованности.
Уровень согласованности определяет, сколько узлов ответят подтверждением успеха.
Узел ответит подтверждением успеха, если данные успешно записаны в журнал фиксации и мемТаблица.
Например, в одном дата-центре с коэффициентом репликации, равным трем, три реплики получат запрос на запись. Если уровень согласованности равен единице, только одна реплика ответит подтверждением успеха, а остальные две останутся бездействующими.
Предположим, если оставшиеся две реплики потеряют данные из-за сбоя узла или какой-либо другой проблемы, Cassandra сделает строку согласованной с помощью встроенного механизма восстановления в Cassandra.
Здесь объясняется, как происходит процесс записи в Cassandra,
- Когда на узел приходит запрос на запись, он в первую очередь записывается в журнал фиксации.
- Затем Cassandra записывает данные в mem-таблицу. Данные, записываемые в mem-таблицу при каждом запросе на запись, также записываются в журнал фиксации отдельно. Mem-таблица — это временно хранящиеся в памяти данные, а журнал фиксации регистрирует записи транзакций для целей резервного копирования.
- Когда таблица памяти заполнена, данные сбрасываются в файл данных SSTable.
Поскольку SSTable-файлы никогда не редактируются на месте, удаление не приводит к немедленному удалению строки. Вместо этого используется маркер, называемый надгробная плита Запись происходит, и строка исчезает только после запуска процесса компактирования по истечении льготного периода. Именно поэтому большие объемы операций удаления замедляют чтение до тех пор, пока процесс компактирования не завершится.
Читать Operaция в Cassandra
Существует три типа запросов на чтение, которые координатор отправляет репликам.
- Прямой запрос
- Запрос дайджеста
- Прочитать заявку на ремонт
Координатор отправляет прямой запрос на одну из реплик. После этого координатор отправляет дайджест-запрос на количество реплик, указанное уровнем согласованности, и проверяет, являются ли возвращенные данные обновленными данными.
После этого координатор отправляет дайджест-запрос всем остальным репликам. Если какой-либо узел выдает устаревшее значение, запрос на восстановление фонового чтения обновит эти данные. Этот процесс называется механизмом восстановления чтения.
Внутри реплики, получающей прямой запрос, порядок поиска разработан таким образом, чтобы по возможности избегать обращения к диску.
- мемтабл Проверка выполняется в первую очередь, поскольку самые новые записи еще не были сброшены.
- кэш строкЕсли эта функция включена, она может обработать весь запрос без дополнительных действий.
- A фильтр цветения Для каждого SSTable-файла выполняется проверка. В результате она выдает либо "определенно отсутствует", либо "возможно присутствует", что позволяет пропускать большинство SSTable-файлов без их чтения.
- индекс раздела а в сводке определяется точное смещение в байтах в любой SSTable-таблице, которая прошла проверку фильтра Блума.
- Фрагменты, совпадающие по времени с данными из нескольких SSTable-таблиц, объединяются, при этом для каждого столбца побеждает самая последняя метка времени.
Фильтр Блума — это этап, обеспечивающий высокую скорость чтения по мере роста объёма данных, поскольку он исключает из рассмотрения почти все SSTable-файлы до начала поиска на диске. Применение этих механизмов на нескольких машинах описано в соответствующем разделе. Cassandra кластер учебное пособие.
