Как быстро увеличивать счетчики в Кассандре без застоя

Ответ 1

Счётчики в C * имеют сложное внутреннее представление, которое позволяет избежать большинства (но не всех) проблем подсчета вещей в безликой распределенной системе. Мне нравится думать о них как о закрытых прилавках. Счетчик состоит из нескольких подзаголовков, идентифицированных идентификатором хоста и номером версии. Хост, который принимает операцию счетчика, увеличивает свой собственный счетчик, а также увеличивает версию. Затем он реплицирует все свое состояние счетчика на другие реплики, которые объединяют его со своими состояниями. Когда счетчик считывается, обработка операции чтения node определяет значение счетчика, суммируя общее количество отсчетов с каждого хоста.

В каждом node приращение счетчика похоже на все остальное в Cassandra, просто написание. Приращение записывается в таблицу заметок, а локальное значение определяется во время чтения путем слияния всех приращений из таблицы памяти и всех SSTables.

Я надеюсь, что это объяснение поможет вам поверить мне, когда я говорю, что вам не нужно беспокоиться об увеличении счетчиков быстрее, чем может справиться Cassandra. Поскольку каждый node хранит свой собственный счетчик и никогда не реплицирует операции с приращением, нет возможности потерять счеты по условиям гонки, например, как сценарий чтения-изменения-записи. Если Кассандра согласится на запись, вы почти гарантируете, что она будет считаться.

То, что вам не гарантировано, заключается в том, что подсчет будет отображаться правильно в любое время, если только. Если приращение записывается в один node, но значение счетчика, считанное с другого сразу после этого, не гарантируется, что приращение было реплицировано, и вам также нужно учитывать, что произойдет во время сетевого раздела. Это более или менее то же самое с любой записью в Cassandra, это в ее последовательной природе, и это зависит от того, какие уровни согласованности вы использовали для операций.

Существует также возможность потерянного подтверждения. Если вы делаете приращение и теряете соединение с Cassandra, прежде чем вы сможете получить ответ, вы не сможете узнать, получилась ли ваша запись. И когда вы получите соединение обратно, вы не можете сказать, так как вы не знаете, что счет был до того, как вы увеличили. Это неотъемлемая проблема с системами, которые выбирают доступность по сравнению с последовательностью, и ценой, которую вы платите за многие другие преимущества.

Наконец, проблема быстрого удаления, приращения, удаления является реальной и что-то, чего вам следует избегать. Проблема в том, что операция приращения существенно воскресит столбец, и если эти операции будут достаточно близки друг к другу, они могут получить одну и ту же метку времени. Кассандра - это строго последняя победа и определяет последний, основанный на отметке времени операции. Если две операции имеют один и тот же штамп времени, выигрывает "больше", что означает тот, который сортируется в строгом порядке байтов. Это реально, но я бы не слишком беспокоился об этом, если вы делаете очень быстрые записи и не удаляете их до одного значения (что, вероятно, является ошибкой в ​​вашей модели данных).

Вот хорошее руководство для внутренних счетчиков Cassandra: http://www.datastax.com/wp-content/uploads/2011/07/cassandra_sf_counters.pdf

Ответ 2

Текущая версия счетчиков просто не подходит для использования, которая требует гарантий без перерасчета и непосредственной согласованности.

Существуют операции с приращением и уменьшением, и они не будут сталкиваться друг с другом, и, запрещая любые потерянные мутации или переизданные мутации, даст вам правильный результат.

Возможно, вам будет интересно переписать счетчики Cassandra (https://issues.apache.org/jira/browse/CASSANDRA-6504), и он должен решить все текущие проблемы с получением правильный счет.

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

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

Ответ 3

Чтобы понять обновления/приращения, например, операции записи, я предлагаю вам пройти через Gossip, протокол, используемый Cassandra для связи. В Gossip каждый участник (node) поддерживает свое состояние, используя кортеж σ(K) = (V*N), где σ(K) - это состояние ключа K с V значением и N как номер версии.

Чтобы поддерживать единую версию правды для пакета данных, Gossip поддерживает механизм примирения, а именно Precise и Scuttlebutt (current). Согласно Scuttlebutt Reconciliation, перед обновлением любого кортежа они обмениваются данными друг с другом, чтобы проверить, кто держит самую высокую версию (новейшее значение) ключа. Тот, кто держит самую высокую версию, отвечает за операцию записи.

Для получения дополнительной информации прочтите статью .