Кассандра ТТЛ VS. Вращение ключевых пространств для очереди данных

Я использую Касандру 2.0.

Моя нагрузка записи чем-то похожа на упомянутый здесь антишаблон очередей: данные

Я планирую загружать 30–40 ГБ данных в cassandra каждые 24 часа и истечения срока действия этих данных в течение 24 часов. Мой текущий подход заключается в том, чтобы установить TTL для всего, что я вставляю.

Я экспериментирую с тем, как я разделяю свои данные, как показано здесь: тонкие ряды

У меня есть две семьи столбцов. Первое семейство содержит метаданные, а второе — данные. Есть N метаданных для 1 данных, и метаданные могут быть перезаписаны M раз в течение дня, чтобы указать на новые данные.

Я подозреваю, что отток метаданных вызывает проблемы с чтением, поскольку поиск правильных метаданных может потребовать сканирования всех M элементов.

Я подозреваю, что отток данных приводит к чрезмерному уплотнению работы и сбору мусора.

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

Помимо необходимости обрабатывать проблемы с тем, из какого пространства ключей пользователь читает запросы, которые перекрывают пространства ключей, есть ли какие-либо другие серьезные недостатки в этом плане?


person cs_alumnus    schedule 14.03.2014    source источник


Ответы (1)


Из моей практики использование разбиения на разделы намного лучше, чем использование ttl.

  1. Снижает нагрузку на процессор
  2. Он разделяет ваши данные по принципу Oracle, поэтому поиск выполняется быстрее.
  3. Вы можете передумать и оставить старые данные; с помощью ttl сложно(вижу один вариант - мигрировать данные перед удалением)
  4. Если у вас широкие ряды, их можно сузить.
person pavel    schedule 14.03.2014