Получил 14-узловой кластер DSC 2.1.15, который использует STCS, и, похоже, он колеблется вокруг того, что кажется стабильным числом sstables, даже когда мы вставляем все больше и больше данных, поэтому в настоящее время начинаем видеть файлы данных sstables в избытке. +1 ТБ. См. графики:
Читая это, мы опасаемся, что слишком большие размеры файлов могут отложить сжатие надгробий, чтобы, наконец, освободить место, поскольку нам придется подождать, пока будут созданы как минимум 4 sstables одинакового размера.
Каждый узел в настоящее время имеет по два каталога данных, мы надеялись, что cassandra будет распределять данные по этим каталогам, используя относительное пространство в равной степени, но поскольку sstables растут из-за сжатия, мы опасаемся, что в конечном итоге все больше и больше sstables и, возможно, в одном каталоге данных в первую очередь.
Как это лучше контролировать, может быть, LCS или...?
Как определить оптимальное соотношение количества sstables и их размеров?
Что влияет на количество sstables по сравнению с их размерами и в какой каталог данных они помещаются?
В настоящее время некоторые узлы начинают выглядеть перекошенными:
/dev/mapper/vg--blob1-lv--blob1 6.4T 3.3T 3.1T 52% /blob/1
/dev/mapper/vg--blob2-lv--blob2 6.6T 545G 6.1T 9% /blob/2
Можем ли мы остановить узел, объединить все sstables пространства ключей (они кажутся уникальными именами с идентификатором/seq.#, даже если они распределены по двум каталогам данных) в один каталог данных и расширить базовый том и перезапустить узел снова и, таким образом, избежать исчерпания «пробел», когда заполняется только один каталог данных FS?
