CQLSSTableWriter: нужно ли уплотнение после загрузки с помощью sstablesloader? - PullRequest
0 голосов
/ 10 мая 2019

Я использую CQLSSTableWriter для записи соответствующих SSTables моих данных:

 writer.addRow(1, "test", ...);

Данные сортируются по ключу раздела и ключу кластеризации, затем я вызываю addRow для каждой строки отсортированных данных.

Данные для данного раздела записываются в один SSTables (или максимум два).

Два вопроса:

  1. Для конструктора CQLSSTableWriter () не требуется стратегия уплотнения. Это нормально?

  2. Уже созданная таблица имеет сжатие LCS. Но CQLSSTableWriter не поставляется с какой-либо определенной стратегией. Что касается того, что после проглатывания данные никогда не меняются (в моем случае!), И после того, как я принял SSTables на Cassandra с помощью sstablesloader, имеет ли смысл препятствовать запуску любого сжатия? Или мне всегда нужно запускать уплотнение после каждого приема с помощью sstablesloader?

Спасибо, чтобы сделать это немного яснее!

Ответы [ 2 ]

2 голосов
/ 10 мая 2019

1) Да, CQLSSTableWriter просто создает sstables.

2) Когда Кассандра получает sstable из sstableloader или nodetool refresh/import, она автоматически сделает все необходимые уплотнения. Вы не должны и не должны ничего делать.

Если вы действительно хотите, вы можете отключить уплотнения, если вы хотите

ALTER TABLE keyspace.table WITH COMPACTION = {'class': 'SizeTieredCompactionStrategy', 'enabled': 'false' }`

Тогда он ничего не сделает, и вы можете просто проигнорировать это, и sstables останутся как есть.

Наличие раздела только в 2 sstables не обязательно означает, что только 2 будут затронуты при чтении. Фильтры Блума на sstables будут по-прежнему давать ложные срабатывания, и если количество sstables продолжит расти, это в конечном итоге станет проблемой. Однако если ваш ключ кластеризации увеличивается с течением времени, его можно использовать для фильтрации ненужных sstables, а ключ кластеризации min / max хранится в метаданных и проверяется в пути чтения (именно так TWCS и большинство данных временных рядов предотвращают слишком много построить). Это также сильно влияет на ремонт и другие оперативные задачи по мере роста числа sstable.

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

1 голос
/ 10 мая 2019

Лучше оставить Кассандре решать, когда выполнять уплотнение, и не пытаться выполнить это вручную.

...