Я столкнулся со сценарием, когда счетчик выбора (*) в таблице каждую минуту (да, этого определенно следует избегать) вызвал огромное увеличение количества операций записи Cassandra примерно до 150 Кбайт в секунду.
Кто-нибудь может объяснить это странное поведение? Почему запрос Select значительно увеличивает количество записей в Cassandra?
Спасибо!
Если вы проверите
org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBackground
а также
org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlocking
метрики, вы можете увидеть, исправляет ли его чтение, отправляя мутации. Возможно, чтение всех данных для обслуживания счетчика (*) вызывает много исправлений чтения, если ваши данные несовместимы. В этом случае снижение read_repair_chance и dclocal_read_repair_chance на столе (ALTER TABLE) может снизить нагрузку.
Другие вероятные возможности:
Возможное объяснение можно найти в пути записи обновления < / а>:
Во время записи Cassandra добавляет каждую новую строку в базу данных, не проверяя, существует ли повторяющаяся запись. Эта политика делает возможным, что в базе данных может существовать много версий одной и той же строки.
потом
Большинство установок Cassandra хранят реплики каждой строки на двух или более узлах. Каждый узел выполняет уплотнение независимо. Это означает, что даже если устаревшие версии строки были удалены с одного узла, они все еще могут существовать на другом узле.
И наконец:
Вот почему Cassandra выполняет еще один раунд сравнений во время процесса чтения. Когда клиент запрашивает данные с определенным первичным ключом, Cassandra извлекает множество версий строки из одной или нескольких реплик.
