1. Обзор
Apache Cassandra — это NoSQL, высокодоступная и масштабируемая распределенная база данных с открытым исходным кодом. Для достижения высокой доступности Cassandra полагается на репликацию данных между кластерами.
В этом руководстве мы узнаем, как Cassandra предоставляет нам средства управления согласованностью данных при репликации данных для обеспечения высокой доступности.
2. Репликация данных
Репликация данных относится к хранению копий каждой строки на нескольких узлах. Причиной репликации данных является обеспечение надежности и отказоустойчивости. Следовательно, если какой-либо узел по какой-либо причине выйдет из строя, стратегия репликации гарантирует, что те же самые данные будут доступны на других узлах.
Коэффициент репликации ( RF ) указывает, сколько узлов в кластере будет хранить реплики.
Существует две доступные стратегии репликации:
SimpleStrategy используется для топологии с одним центром обработки данных и одной стойкой . Во-первых, Cassandra использует логику разделения, чтобы определить узел для размещения строки. Затем он помещает дополнительные реплики на следующие узлы кольца по часовой стрелке.
NetworkTopologyStrategy обычно используется для нескольких центров обработки данных и нескольких стоек. Кроме того, он позволяет указать разные коэффициенты репликации для каждого центра обработки данных. В центре обработки данных реплики распределяются по разным стойкам для обеспечения максимальной доступности.
3. Уровень согласованности
Согласованность указывает, насколько свежими и синхронизированными являются все реплики строки данных. При репликации данных в распределенной системе достижение согласованности данных является очень сложной задачей.
Cassandra предпочитает доступность согласованности. Он не оптимизируется для согласованности. Вместо этого он дает вам возможность настраивать согласованность в зависимости от вашего варианта использования. В большинстве случаев Cassandra полагается на окончательную согласованность.
Давайте посмотрим на влияние уровня согласованности во время записи и чтения данных.
4. Уровень согласованности (CL) при записи
Для операций записи уровень согласованности указывает, сколько узлов реплики должны получить подтверждение, прежде чем координатор успешно отправит отчет клиенту. Что еще более важно, количество узлов, которые подтверждают (для данного уровня согласованности), и количество узлов, хранящих реплики (для данного RF), в основном различаются.
Например, при уровне согласованности ONE и RF = 3, хотя только один узел реплики подтверждает успешную операцию записи, Cassandra асинхронно реплицирует данные на 2 других узла в фоновом режиме.
Давайте рассмотрим некоторые параметры уровня согласованности, доступные для успешной операции записи.
Уровень согласованности ONE означает, что требуется подтверждение только от одного узла реплики. Поскольку подтверждение требуется только для одной реплики, в этом случае операция записи выполняется быстрее всего.
Уровень согласованности QUORUM означает, что требуется подтверждение от 51 % или большинства узлов реплики во всех центрах обработки данных.
Уровень согласованности LOCAL_QUORUM означает, что требуется подтверждение от 51 % или большинства узлов реплик только в том же центре обработки данных, что и координатор. Таким образом, он позволяет избежать задержек при обмене данными между центрами обработки данных.
Уровень согласованности ALL означает, что требуется подтверждение от всех узлов реплики. Поскольку все узлы-реплики должны подтверждать, операция записи в этом случае будет самой медленной. Более того, если один из узлов реплики выйдет из строя во время операции записи, произойдет сбой, и доступность пострадает. Поэтому рекомендуется не использовать этот параметр в производственной среде.
Мы можем настроить уровень согласованности для каждого запроса на запись или на глобальном уровне запроса.
На диаграмме ниже показано несколько примеров CL при записи:
5. Уровень согласованности (CL) при чтении
Для операций чтения уровень согласованности указывает, сколько узлов реплики должны ответить последними согласованными данными, прежде чем координатор успешно отправит данные обратно клиенту.
Давайте рассмотрим некоторые параметры уровня согласованности, доступные для операции чтения, когда Cassandra успешно возвращает данные.
Уровень согласованности ONE означает, что только один узел реплики возвращает данные. В этом случае поиск данных происходит быстрее.
Уровень согласованности QUORUM означает, что отвечает 51 % или большинство узлов реплик во всех центрах обработки данных. Затем координатор возвращает данные клиенту. В случае нескольких центров обработки данных задержка связи между центрами обработки данных приводит к медленному чтению.
Уровень согласованности LOCAL_QUORUM означает 51 % или большинство узлов реплики в одном центре обработки данных. Когда координатор отвечает, координатор возвращает данные клиенту. Таким образом, он позволяет избежать задержек при обмене данными между центрами обработки данных.
Уровень согласованности ALL означает, что все узлы-реплики отвечают, после чего координатор возвращает данные клиенту. Поскольку все узлы-реплики должны подтверждать, операция чтения в этом случае будет самой медленной. Более того, если один из узлов реплики выйдет из строя во время операции чтения, произойдет сбой, и доступность пострадает. Лучше всего не использовать этот параметр в производственной среде.
Мы можем настроить уровень согласованности для каждого запроса на запись или на глобальном уровне запроса.
На диаграмме ниже показана пара примеров CL при чтении:
6. Сильная последовательность
Строгая согласованность означает, что вы считываете последние записанные данные в кластер независимо от того, сколько времени прошло между последней записью и последующим чтением.
В предыдущих разделах мы видели, как можно указать желаемый уровень согласованности ( CL ) для операций записи и чтения.
Строгая согласованность может быть достигнута, если W + R > RF , где R — количество реплик CL чтения , W — количество реплик CL записи , RF — коэффициент репликации.
В этом сценарии вы получаете строгую согласованность, поскольку все операции чтения клиента всегда извлекают самые последние записанные данные.
Давайте рассмотрим пару примеров сильных уровней согласованности:
6.1. Напишите CL = QUORUM и прочитайте CL = QUORUM
Если RF = 3, W = QUORUM или LOCAL_QUORUM, R = QUORUM или LOCAL_QUORUM , то W (2) + R (2) > RF (3)
В этом случае операция записи гарантирует, что две реплики будут иметь самые последние данные. Затем операция чтения также обеспечивает успешное получение данных только в том случае, если по крайней мере две реплики отвечают согласованными последними данными.
6.2. Напишите CL = ВСЕ и прочитайте CL = ONE
Если RF = 3, W = ВСЕ , R = ОДИН , то W (3) + R (1) > RF (3)
В этом случае, когда координатор записывает данные во все реплики, операция записи завершается успешно. Затем достаточно прочитать данные из одной из этих реплик, чтобы убедиться, что мы читаем самые последние записанные данные.
Но как мы узнали ранее, запись CL of ALL не является отказоустойчивой, и страдает доступность.
7. Заключение
В этой статье мы рассмотрели репликацию данных в Cassandra. Мы также узнали о различных вариантах уровня согласованности, доступных при записи и чтении данных. Кроме того, мы рассмотрели пару примеров, чтобы добиться строгой согласованности.