Кассандра возможная потеря узла

Question

Я довольно новичок в Кассандре и нашел этот сайтhttps://www.ecyrd.com/cassandracalculator/
Не уверен, насколько это точно, но у меня есть одно недоразумение.Рассмотрим следующий пример:

• размер кластера 8
• коэффициент репликации 5
• чтение, запись ONE
• запись, запись ONE

КакВ результате я получаю, что я могу потерять 4 узла без ущерба для приложения.Кто-нибудь знает, какой расчет приводит нас к такому результату?Заранее спасибо.
PS Я хотел бы отметить, что меня не интересует какой-либо другой аспект, кроме «сколько узлов я могу потерять, не влияя на приложение».Ответ, который я ищу, не в том, как работает согласованность или что-то еще, а исключительно в том, какое уравнение стоит за описанным результатом для «сколько узлов я могу потерять без влияния на приложение» и почему.

Answer 1

Вы можете настроить непротиворечивость на уровне запроса также на основе требований.SELECT * FROM пользователей WHERE state = 'ABC' ИСПОЛЬЗУЯ ПОСТОЯННЫЙ КВОРУМ;Да, CL ONE обеспечивает хорошую доступность, чем кворум, но кворум даст вам более согласованные данные.

Answer 2

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

Если вы используете local_quorum или кворум, тогда при RF = 5 вы можете иметь 2 узла набора реплик.потерпеть неудачу без какой-либо потери данных (исключая такие случаи, как несоблюдение ожидаемых правил эксплуатации при ремонте)Однако с CL.ONE ваше приложение может работать, даже если 4 из 5 реплик умерли, в некоторых случаях доступность важнее, чем долговечность и согласованность.Я бы рекомендовал всегда начинать с кворума, а затем изменять свою согласованность только в том случае, если существует неудовлетворительная доступность требования к производительности.