Стратегия сжатия временного окна для данных с TTLed вставками, за которыми следуют TTLed обновления

Question

У меня проблема с уплотнением кассандры в таблице, в которой хранятся данные о событиях. Эти события генерируются цензорами и имеют связанный TTL. По умолчанию каждое событие имеет TTL 1 день. У немногих событий есть различный TTL как 7/10/30, который является деловым требованием. У немногих событий может быть TTL 5 лет, если событие должно быть сохранено. У более чем 98% строк TTL составляет 1 день.

Несмотря на то, что время от времени запускается незначительное сжатие, использование диска постоянно увеличивается. Это связано с тем, как работает стратегия сжатия SizeTierd, т.е. она будет выбирать таблицу схожего размера для сжатия. Это создает несколько огромных таблиц, которые долго не уплотняются. Наличие нескольких больших таблиц увеличит средний размер SSTable, и сжатие будет выполняться реже. Похоже, STCS не правильный выбор. В en-load-test я добавил данные в таблицы и переключился на уровневую стратегию сжатия. С LCS дисковое пространство восстанавливалось до определенной точки, а затем использование диска было постоянным. Процессор также был меньше по сравнению с STCS. Однако стратегия сжатия временного окна выглядит более перспективной, так как она хорошо работает для данных TTL с временными рядами. Я собираюсь протестировать TWCS с моим набором данных. То есть, пока я пытаюсь найти ответ на несколько запросов, на которые я не нашел ответа или что я нашел непонятным для меня.

В моем случае использования событие добавляется в таблицу со связанным TTL. Тогда есть еще 5 обновлений об этом событии в течение следующей минуты. Обновления не производятся для одного столбца, вместо этого полная строка переписывается с новым TTL (что одинаково для всех столбцов). Этот новый TTL нравится быть немного меньше, чем предыдущий TTL. Например, событие создается с TTL 86400 секунд. Он обновляется через 5 секунд, тогда новый TTL будет 86395. Дальнейшее обновление будет с новым TTL, который будет немного меньше, чем 86395. После 4-5 обновлений обновление не будет выполнено для более чем 99% строк. 1% строк будут переписаны с TTL 5 лет.

1. Из того, что я прочитал: TWCS для данных, вставленных с неизменным TTL. Означает ли это, что я не должен использовать TWCS?
2. Кроме того, записи не по порядку плохо обрабатываются TWCS. Если событие создается в 10:00 5 сентября с 1-дневным TTL, и та же строка события перезаписывается с TTL 5 лет 10-го или 12-го сентября, будет ли это нашей записью заказа? Я полагаю, что не в порядке, когда я устанавливаю метку времени для данных при добавлении данных в БД или что-то, что может быть вызвано восстановлением чтения.

Любое руководство / предложение будет оценено!

ПРИМЕЧАНИЕ: я использую cassandra 2.2.8, поэтому я буду создавать jar для TWCS, а затем использовать его.

Answer 1

TWCS - отличный вариант при определенных обстоятельствах. Вот что следует иметь в виду:

1) Одно из больших преимуществ TWCS заключается в том, что слияния / согласования между sstables не происходит. Самый старый просто «отрублен». Из-за этого вы не хотите, чтобы строки / ячейки занимали несколько «сегментов / окон». Например, если вы вставляете один столбец в течение одного окна, а затем в следующее окно, вы вставляете другой столбец (т.е. обновление той же строки, но другого столбца в более поздний период времени). Вместо сжатия, создающего одну строку с обоими столбцами, TWCS отключит один из столбцов (самый старый). На самом деле я не уверен, позволит ли TWCS даже позволить этому произойти, но приводил вам пример того, что произойдет, если это произойдет. В этом примере я считаю, что TWCS будет запрещать удаление любого sstable, пока не истечет срок действия обоих окон. Хотя не уверен на 100%. В любом случае, избегайте этого сценария.

2) TWCS сталкивается с аналогичными проблемами, когда происходят записи вне времени (перекрытие). В последней статье описана замечательная статья, объясняющая это:

https://thelastpickle.com/blog/2016/12/08/TWCS-part1.html

Перекрытие может произойти из-за ремонта или из-за старого уплотнения (например, если вы использовали STCS, а затем переключились на TWCS, некоторые из sstables могутoverlap).

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

Если вы избегаете обоих сценариев, описанных выше, TWCS очень эффективен из-за характера того, как он очищает вещи - больше не нужно объединять sstables. Просто удалите самое старое окно.

Когда вы настраиваете TWCS, вы должны помнить, что самое старое окно удаляется после истечения TTL и прохождения GC Grace - не забудьте добавить эту часть. Как вы уже описали, наличие различного числа TTL среди строк может задержать удаление окон. Если вы хотите увидеть, что блокирует TWCS от удаления sstable или как выглядит sstables, вы можете использовать sstableexpiredblockers или скрипт в вышеупомянутом URL (который по сути является sstablemetadata с некоторыми причудливыми сценариями).

Надеюсь, это поможет.

-Джим