Работа с некомпактными / перекрывающимися sstables в Кассандре - PullRequest
0 голосов
/ 31 марта 2020

У нас есть новый кластер с Cassandra 2.2.14, и мы оставили уплотнения, чтобы «разобраться». Это в нашей среде UAT, поэтому нагрузка низкая. Мы запускаем STCS.

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

'tombstone_compaction_interval': '120', 
'unchecked_tombstone_compaction': 'true', 
'tombstone_threshold': '0.2', 
'min_threshold': '2'

это привело к некоторым сжатиям, однако количество выпавших надгробий невелико, и оно не было go ниже порогового значения (0,2). После того, как эти настройки были применены, вот что я вижу из sstablemetadata:

Estimated droppable tombstones: 0.3514636277302944
Estimated droppable tombstones: 0.0
Estimated droppable tombstones: 6.007563159628437E-5

Обратите внимание, что это только один CF, и там намного хуже CF (90% надгробий и т. Д. c) , Используя это в качестве примера, но все CF имеют одинаковые симптомы.

tablestats:

               SSTable count: 3
                Space used (live): 3170892738
                Space used (total): 3170892738
                Space used by snapshots (total): 3170892750
                Off heap memory used (total): 1298648
                SSTable Compression Ratio: 0.8020960426857765
                Number of keys (estimate): 506775
                Memtable cell count: 4
                Memtable data size: 104
                Memtable off heap memory used: 0
                Memtable switch count: 2
                Local read count: 2161
                Local read latency: 14.531 ms
                Local write count: 212
                Local write latency: NaN ms
                Pending flushes: 0
                Bloom filter false positives: 0
                Bloom filter false ratio: 0.00000
                Bloom filter space used: 645872
                Bloom filter off heap memory used: 645848
                Index summary off heap memory used: 192512
                Compression metadata off heap memory used: 460288
                Compacted partition minimum bytes: 61
                Compacted partition maximum bytes: 5839588
                Compacted partition mean bytes: 8075
                Average live cells per slice (last five minutes): 1.0
                Maximum live cells per slice (last five minutes): 1
                Average tombstones per slice (last five minutes): 124.0
                Maximum tombstones per slice (last five minutes): 124

Очевидный ответ здесь заключается в том, что надгробные камни не подходили для Удаление.

gc_grace_seconds имеет значение 10 дней и не было перемещено. Я выбросил одну из sstables в json и вижу надгробия, датируемые апрелем 2019 года:

{"key": "353633393435353430313436373737353036315f657370a6215211e68263740a8cc4fdec",
 "cells": [["d62cf4f420fb11e6a92baabbb43c0a93",1566793260,1566793260977489,"d"],
           ["d727faf220fb11e6a67702e5d23e41ec",1566793260,1566793260977489,"d"],
           ["d7f082ba20fb11e6ac99efca1d29dc3f",1566793260,1566793260977489,"d"],
           ["d928644a20fb11e696696e95ac5b1fdd",1566793260,1566793260977489,"d"],
           ["d9ff10bc20fb11e69d2e7d79077d0b5f",1566793260,1566793260977489,"d"],
           ["da935d4420fb11e6a960171790617986",1566793260,1566793260977489,"d"],
           ["db6617c020fb11e6925271580ce42b57",1566793260,1566793260977489,"d"],
           ["dc6c40ae20fb11e6b1163ce2bad9d115",1566793260,1566793260977489,"d"],
           ["dd32495c20fb11e68f7979c545ad06e0",1566793260,1566793260977489,"d"],
           ["ddd7d9d020fb11e6837dd479bf59486e",1566793260,1566793260977489,"d"]]},

Так что я не верю, что gc_grace_seconds является проблемой здесь. Я запустил ручное заданное пользователем сжатие для каждого файла Data.db в папке семейства столбцов (только отдельный файл Data.db, по одному за раз). Произошли уплотнения, но значения надгробий изменились очень мало. Старые данные все еще остаются.

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

Так что ремонт в порядке. Уплотнения в порядке. Все, о чем я могу думать, - это перекрывающиеся SSTable.

Последний тест - полное сжатие семейства столбцов. Я выполнил пользовательский (не компактный nodetool) для 3 SSTables с использованием JMXterm. Это привело к единственному файлу SSTable со следующим:

Estimated droppable tombstones: 9.89886650537452E-6

Если я ищу пример EPOCH, как указано выше (1566793260), он не отображается. И не ключ. Так что это было уплотнено, или Кассандра что-то сделала. Общее количество строк, содержащих флаг надгробной плиты («d»), составляет 1317 из 120-миллионного дампа строк. И значения EPOCH все в течение 10 дней. Хорошо.

Итак, я предполагаю, что значение -6 - это очень маленький процент, и у sstablemetadata возникают проблемы с его отображением. Итак, успех не так ли? Но для полного удаления старых надгробий потребовалось полное уплотнение. Насколько я знаю, полное уплотнение - это только последний маневр.

Мои вопросы -

  1. Как я могу определить, является ли моя проблема здесь с перекрывающимися sstables? Я не вижу никакой другой причины, по которой данные не будут сжиматься, если они не связаны друг с другом.
  2. Как я могу разрешить перекрывающиеся sstables, не выполняя полное сжатие? Я боюсь, что это будет повторяться через несколько недель. Я не хочу зацикливаться на необходимости регулярно выполнять полное уплотнение, чтобы держать надгробия в страхе.
  3. Каковы причины создания перекрывающихся sstables? Это проблема проектирования данных или какая-то другая проблема?

Приветствия.

1 Ответ

0 голосов
/ 31 марта 2020

Чтобы ответить на ваши вопросы:

Как я могу определить, является ли моя проблема здесь наложением sstables? Я не вижу никакой другой причины, по которой данные не будут сжиматься, если только они не связаны друг с другом.

Если надгробия не были созданы с использованием TTL, в большинстве случаев надгробия и теневые данные могли найдите в разных sstables. При использовании STCS и небольшом объеме записи в кластер будет инициировано небольшое сжатие, что приведет к тому, что надгробия останутся на продолжительное время. Если у вас есть ключ разбиения надгробной плиты, запустите nodetool getsstables -- <keyspace> <table> <key> на узле, чтобы вернуть все sstables, которые содержат ключ в локальном узле. Вы можете сбросить содержимое sstable для подтверждения.

Как разрешить перекрывающиеся sstables, не выполняя полное уплотнение? Я боюсь, что это будет повторяться через несколько недель. Я не хочу зацикливаться на необходимости регулярно выполнять полное уплотнение, чтобы держать надгробные плиты в страхе.

В "nodetool compaction -s" есть новая опция, которая может выполнять основное сжатие и разрезать вывод до 4 sstables с разными размерами. Это решает предыдущую проблему основного уплотнения, которое создает один большой sstable. Если коэффициент сбрасываемых надгробий достигает 80-90%, полученный размер стабильного будет еще меньше, так как большинство надгробий было очищено.

В более новой версии Cassandra (3.10+) есть новый инструмент, nodetool garbagecollect, для очистки надгробий. Однако в этом инструменте есть ограничения. Не все виды надгробий могут быть удалены этим.

При этом для вашей ситуации существует то, что существуют перекрывающиеся sstables и низкий объем операций / меньшая частота уплотнений, либо вы должны выяснить все связанные sstables и использовать пользовательское уплотнение, либо выполнить значительное уплотнение с помощью " -s». https://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/tools/nodetool/toolsCompact.html

Каковы причины создания перекрывающихся sstables? Это проблема проектирования данных или какая-то другая проблема?

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

...