Понять коэффициент репликации кассандры по сравнению с уровнем согласованности

Ответ 1

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

В качестве примера у вас может быть коэффициент репликации в 2. Когда вы пишете, две копии будут всегда сохранены, предполагая, что достаточно узлов. Когда node выключен, записи для этого node будут спрятаны и записаны, когда он вернется в исходное состояние, если он не будет достаточно длинным, чтобы Кассандра решила, что он ушел навсегда.

Теперь скажите в этом примере, что вы пишете с уровнем согласованности ONE. Клиент получит подтверждение успеха после записи на один node, не дожидаясь второй записи. Если вы сделали запись с CL ALL, подтверждение клиенту будет ждать, пока не будут записаны обе копии. Есть очень много других вариантов уровня согласованности, слишком много, чтобы охватить все варианты здесь. Прочтите Datastax doc, но он хорошо объясняет их.

В том же примере, если вы читаете с уровнем согласованности ONE, ответ будет отправлен клиенту после ответа одной реплики. Другая реплика может содержать более новые данные, и в этом случае ответ не будет актуальным. Во многих контекстах этого достаточно. В других случаях клиенту потребуется самая свежая информация, и вы будете использовать другой уровень согласованности для чтения - возможно, для ВСЕГО. Таким образом, согласованность Cassandra и других пост-реляционных баз данных настраивается таким образом, что реляционные базы данных обычно не являются.

Теперь вернемся к вашим примерам.

Пример один: Да, вы можете писать в и читать из B, даже если B не имеет своей собственной реплики. B попросит A для вас от имени вашего клиента. Это справедливо и для других случаев, когда все узлы. Когда они все встанут, вы можете написать одно и прочитать от другого.

Для записи с WC = ONE, если node для одной реплики вставлен и является тем, с которым вы подключаетесь, запись будет успешной. Если это для другого node, запись не удастся. Если вы используете ЛЮБОЙ, запись будет успешной, если вы говорите об этом с node. Я думаю, вы также должны были намекнуть, что передача обслуживания включена для этого. Внизу node будут получены данные позже, и вы не сможете прочитать их до тех пор, пока это не произойдет, даже с node, которые были вверх.

В двух других примерах коэффициент репликации будет влиять на то, сколько копий в конечном итоге написано, но не влияет на поведение клиента, кроме того, что я описал выше. QUORUM повлияет на поведение клиента в том, что вам нужно будет иметь достаточное количество узлов и отвечать на записи и чтения. Если вам повезет и по крайней мере (узлы/2) + 1 узел вышел из нужных вам узлов, записи и чтения будут успешными. Если у вас недостаточно узлов с репликами, чтение и запись не удастся. В целом некоторые чтения и записи QUORUM могут быть успешными, если node не работает, считая, что этот node либо не нужен для хранения вашей реплики, либо если его отключение все еще оставляет достаточно доступных узлов реплики.

Ответ 2

Проверьте этот простой калькулятор, который позволяет вам моделировать различные сценарии:

http://www.ecyrd.com/cassandracalculator/

Например, с двумя узлами, коэффициентом репликации 1, константой чтения = 1 и константой записи = 1:

Your reads are consistent 
You can survive the loss of no nodes. 
You are really reading from 1 node every time. 
You are really writing to 1 node every time. 
Each node holds 50% of your data.

Ответ 3

Этот веб-форма позволяет вам попробовать разные значения для вашего кластера Apache Cassandra и посмотреть, какое влияние на ваше приложение.