Кассандра уплотняет широкие ряды большими перегородками - PullRequest
0 голосов
/ 26 сентября 2018

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

Я проследовал по документу по следующей ссылке: https://www.safaribooksonline.com/library/view/cassandra-high-performance/9781849515122/ch13s10.html. Относительно "БОЛЬШИХ РЯДОВ С СЖАТИЕМ"LIMITS ", ниже указано:

" Значение по умолчанию для in_memory_compaction_limit_in_mb равно 64. Это значение установлено в conf / cassandra.yaml. Для случаев использования, имеющих фиксированные столбцы, ограничение никогда не должно превышатьсяУстановка этого значения может работать как проверка работоспособности, чтобы гарантировать, что процессы не производят непреднамеренную запись во многие столбцы с одним и тем же ключом. Ключи со многими столбцами также могут быть проблематичными при использовании кэша строк, поскольку для него требуется сохранение всей строки в памяти.. "

В /conf/cassandra.yaml я нашел конфигурацию с именем" in_memory_compaction_limit_in_mb ".

Определение в cassandra.yaml выглядит следующим образом: В Cassandra 2.0: in_memory_compaction_limit_in_mb (по умолчанию: 64) Предел размера для строк, сжатых в мЭмори.Большие строки проливаются на диск и используют более медленный процесс сжатия в два прохода.Когда это происходит, регистрируется сообщение с указанием ключа строки.Рекомендуемое значение составляет от 5 до 10 процентов от доступного размера кучи Java.

В Cassandra 3.0: (в cassandra.yaml такие записи не найдены) compaction_large_partition_warning_threshold_mb (по умолчанию: 100) Cassandra регистрирует предупреждение при сжатии разделов размером болеезаданное значение

Я ищу много, что именно делает настройка in_memory_compaction_limit_in_mb.В нем упоминается, что некоторое сжатие выполняется в памяти, а некоторое сжатие выполняется на диске.Насколько я понимаю, при запуске процесса сжатия: SSTABLE читается с диска ----> (по сравнению, надгробия удалены, устаревшие данные удалены) все происходит в памяти ---> новый sstable записывается на диск -> старая таблицабыть удаленным Эта операция приводит к высоким требованиям дискового пространства и дискового ввода-вывода (пропускной способности).Помогите мне, если мое понимание уплотнения неверно.Есть ли что-то в уплотнении, что происходит в памяти.В моем окружении in_memory_compaction_limit_in_mb установлен в 800. Мне нужно понять цель и последствия.

Заранее спасибо

1 Ответ

0 голосов
/ 27 сентября 2018

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

Теперь основная стоимость заключается в десериализации большого индекса в начале раздела, который происходит в памяти.Вы можете увеличить column_index_size_in_kb, чтобы уменьшить размер этого индекса (за счет большего количества операций ввода-вывода во время чтения, но, вероятно, незначительного по сравнению с десериализацией).Кроме того, если вы используете более новую версию (3.11+), индекс загружается слишком долго после превышения определенного размера, что немного улучшает ситуацию.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...