TTL надгробия в Кассандре с использованием LCS указываются на одном уровне данных TTLed данных?

Question

Я использую LCS и относительно большой TTL в 2 года для всех вставленных строк, и меня беспокоит момент, когда C * удалит соответствующие надгробия (не выполняется ни явное удаление, ни обновление).

Из Отсутствует руководство по стратегии выравнивания с выравниванием , Уплотнения надгробий в Кассандре и Удаляется без надгробий или TTL Я понимаю, что

• Все уровни, кроме L0, содержат неперекрывающиеся SSTable, но ключ раздела может присутствовать в одной SSTable на каждом уровне (он же распространяется на всех уровнях).
• Чтобы уплотнение могло отбросить надгробную плиту, необходимо убедиться, что уплотняются все таблицы SS, содержащие данные de, для предотвращения данных зомби (это делается проверкой фильтров цветения). Также учитывается gc_grace_seconds

Итак, для моего конкретного случая использования (TTL 2 года и большая нагрузка при записи) я могу заключить, что данные TTL будут на самых высоких уровнях, поэтому мне интересно, когда эти SSTables с данными TTLed будут сжаты с SSTables, который содержит соответствующие SSTables.
Главный вопрос будет: Где создаются надгробия (из ттл)? Создаются на уровне 0, поэтому потребуется много времени, пока он не окажется на самом высоком уровне (следовательно, освобождение места на диске займет много времени)?

В комментарии от Об удалениях и надгробиях Ален говорит, что

Тем не менее, использование TTL помогает уменьшить вероятность фрагментации данных между SSTable, которые в ближайшее время не будут сжаты вместе. Используя любую стратегию сжатия, если удаление происходит относительно поздно в истории строк, как это и происходит, «вставка» / «вставка» надгробного камня перейдет в новый SSTable. Это могильному камню может потребоваться время, чтобы добраться до нужного «ведра» уплотнения (с остальной частью ряда) и чтобы Кассандра смогла наконец освободить место.
Насколько я понимаю, с помощью TTL надгробия создаются на месте , поэтому часто и по многим причинам легче и безопаснее избавиться от TTL, чем от удаления.
Другим ключом к исследованию будет использование TTL в качестве значения по умолчанию, если это хорошо подходит. TTL, установленные на уровне таблицы с параметром default_time_to_live, вообще не должны создавать никаких надгробий в C * 3.0 +. Не проверял на моей руке, но я читал об этом.

Я не уверен, что означает " на месте ", поскольку SSTables являются неизменяемыми.
(У меня также есть некоторые сомнения относительно того, что он говорит об использовании default_time_to_live, о котором я спрашивал в Как default_time_to_live удаляло строки без надгробий в Кассандре? ).

Я предполагаю, что это относится к надгробиям, создаваемым на том же уровне (но с разными SStables), что данные TTLed во время сжатия, вызванные одной из следующих причин:

1. «Начиная с самого высокого уровня, любой уровень, имеющий балл выше 1.001, может быть выбран потоком уплотнения» Пропущенное руководство по стратегии выравнивания с уплотнением
2. «Если мы пройдем 25 раундов без уплотнения на самом высоком уровне, мы начнем вводить sstables с этого уровня в уплотнения более низкого уровня» Пропущенное руководство по стратегии выравнивания уплотнения
3. "Если нет других уплотнений, которые мы можем выполнить, мы запускаем уплотнение с одной стабильной версией, если в sstable имеется более X% выпадающих надгробий." CASSANDRA-7019 Поскольку надгробия создаются во время уплотнения, я думаю, что для оценки сбрасываемых надгробий может использоваться метаданные SSTable.

Таким образом, уплотнения (2) и (3) должны создавать / сбрасывать надгробия на самых высоких уровнях, поэтому использование LCS с большим TTL само по себе не должно быть проблемой.
Под созданием / удалением я подразумеваю, что такой же тип сжатия будет создавать надгробия для данных с истекшим сроком и / или отбрасывания надгробий, если период gc уже прошел.

Ссылка на исходный код, проясняющая эту ситуацию, будет отличной, спасибо.

Answer 1

Ответ Алена Родригеса из списка рассылки

Еще один ключ к исследованию - использование TTL в качестве значения по умолчанию, если оно подходит.TTL, установленные на уровне таблицы с параметром default_time_to_live, вообще не должны создавать никаких надгробий в C * 3.0 +.Не проверял на моей руке, но я читал об этом.

Как объяснено на параллельной нити , это неправильно, меа виноват.Я полагаю, что остальная часть моего комментария все еще остается (надеюсь:)).

Я не уверен, что это означает с " in-place ", так как SSTables являются неизменяемыми.Я предполагаю, что это относится к надгробиям, создаваемым в том же

Да, я полагаю, что во время следующего уплотнения, следующего за датой истечения срока, запись «превращается» в надгробную плиту и живет в SSTableэто результат сжатия, на уровне / контейнере, в который помещается этот SSTable.Вот почему я сказал «на месте», что действительно немного странно для неизменяемых данных.

В качестве дополнительной идеи для вашей проблемы на «современных» версиях Cassandra (я не помню версию, эточто означает «современный» ;-)), вы можете запускать «nodetool garbagecollect» регулярно (не обязательно часто) в течение непикового периода.Это может использовать ресурсы кластера, когда они вам не нужны, чтобы занять место на диске.Кроме того, уверенность в том, что 2-летняя пластинка не обновляется регулярно, определенно поможет.В крайнем случае однократной записи данных (никогда не обновляющихся) и, например, с TTL, я не вижу причин для того, чтобы данные за 2 года не были корректно выселены.Пока диск может расти, с ним все будет в порядке.

Я бы не слишком боялся этого, так как всегда есть способ удаления надгробий.И все же хорошо заранее подумать о дизайне, в общем, хорошо, если вы можете вращать разделы со временем, а не использовать старые разделы, например.