Кассандровские надгробия с TTL - PullRequest
Новая
       9

Кассандровские надгробия с TTL

0 голосов
/ 15 февраля 2019

Я довольно долго работал с Кассандрой (DSE) и пытаюсь понять что-то не совсем понятное.Мы используем DSE 5.1.9 для этой иллюстрации.Это кластер с одним узлом (если у вас кластер из нескольких узлов, убедитесь, что RF = nodeCount упростит задачу).

Это очень простой пример: создайте следующую простую таблицу: 

CREATE TABLE mytable (
    status text,
    process_on_date_time int,
    PRIMARY KEY (status, process_on_date_time)
) WITH CLUSTERING ORDER BY (process_on_date_time ASC)
AND gc_grace_seconds = 60

У меня есть фрагмент кода, который вставляет записи по 5 тыс. Одновременно, всего до 200 тыс. Записей с TTL 300 секунд.Статус ВСЕГДА "ожидает рассмотрения", а process_on_date_time представляет собой счетчик, который увеличивается на 1, начиная с 1 (все уникальные записи - в основном от 1 до 200 тыс.).

Я запускаю код, а затем, когда он завершается, я сбрасываюпамятка на диск.Там только один созданный sstable.После этого не выполняется ни сжатие, ни восстановление, ни выполнение каких-либо других действий, которые могли бы создать или изменить конфигурацию sstable.

После дампа sstable я вхожу в cqlsh, включаю трассировку, устанавливаю согласованность в LOCAL_ONE и выключаю подкачку страниц.Затем я повторяю это: 

SELECT * from mytable where status = 'pending' and process_on_date_time <= 300000;

Что интересно, я вижу такие вещи (вырезая текст для удобства чтения): 

Run X) Read 31433 live rows and 85384 tombstone cells (31k rows returned to my screen) 
Run X+1) Read 0 live rows and 76376 tombstone cells (0 rows returned to my screen - all rows expired at this point) 
Run X+2) Read 0 live rows and 60429 tombstone cells 
Run X+3) Read 0 live rows and 55894 tombstone cells 
... 
Run X+X) Read 0 live rows and 0 tombstone cells

Что происходит?Sstable не меняется (очевидно, что он неизменный), ничего больше не вставляется, не очищается и т. Д. Почему количество надгробий уменьшается до тех пор, пока оно не станет равным 0?В чем причина такого поведения?

Я ожидаю увидеть каждый прогон: чтение 100 тыс. Надгробий и прерывание запроса, поскольку все TTL истекли в одном sstable.

1 Ответ

0 голосов
/ 01 марта 2019

Для всех, кому может быть любопытен этот ответ, я открыл билет с помощью Datastax, и вот что они упомянули: 

After the tombstones pass the gc_grace_seconds they will be ignored in result sets because they are 
filtered out after they have past that point. So you are correct in the assumption that the only way for the 
tombstone warning to post would be for the data to be past their ttl but still within gc_grace.


And since they are ignored/filtered out they wont have any harmful effect 
on the system since like you said they are skipped.

Так что это означает, что если срок действия TTL истекает, но находятся в пределахGC Grace Seconds, они будут засчитаны как надгробия при запросе.Если TTL истекают, а GC Grace Seconds также истекает, они НЕ будут считаться надгробными плитами (пропущены).Система все еще должна «пропалывать» просроченные записи TTL, но, кроме времени обработки, не «вредна» для запроса.Мне это показалось очень интересным, поскольку я нигде не вижу этого документально.

Думаю, что другие могут заинтересоваться этой информацией и могут добавить ее, если их опыт отличается.

...