2016-11-10 3 views
0

Я испытал сценарий, в котором каждый раз подсчитывать счетчик (*) в таблице (да, это обязательно следует избегать) вызвало огромный рост в Cassandra, пишет около 150 тыс. Записей в секунду.Может ли выбрать счетчик (*) повлиять на записи в Cassandra

Может ли кто-нибудь объяснить это странное поведение? Почему запрос Select значительно увеличил количество записей в Cassandra?

Спасибо!

+0

Это немного странно. Я не вижу смысла в том, почему C * должен увеличить количество записей. Как вы это измерили? – xmas79

+0

Я не могу представить, почему это произойдет. Гораздо вероятнее, что есть еще один процесс, делающий вещи ... – RussS

+0

Можно ли прояснить термин «пишет», пожалуйста? Просто, чтобы различать записи диска и мутации Cassandra. Вы видите, что запросы на запись сохраняются в nodetool tpstats, и вы потеряли мутации? Или вы наблюдаете за очередью дисков? 150 тыс. Мутаций в секунду - это много трафика. – suiterdev

ответ

0

Если вы проверяете

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) может уменьшить нагрузку.

Другие вероятные возможности:

  • Вы трассировка включена (глобально или на столе) в какой-то%.
  • Или если вы используете DSE, и у вас включен медленный запрос.
+0

Спасибо Крису! Кассандра выполнила несколько исправлений для чтения во время этих запросов, и это, скорее всего, является основной причиной проблемы, с которой я столкнулся. – GPSS

0

Возможное объяснение можно найти в the write path of an update:

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

Затем

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

И наконец:

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

 Смежные вопросы

  • Нет связанных вопросов^_^