Кластер Cassandra - плотность данных (размер данных за node) - поиск обратной связи и рекомендации

Ответ 1

Риск суперплотных узлов не обязательно максимизирует IO во время ремонта и уплотнения - это невозможность надежного разрешения общей ошибки node. В своем ответе Джиму Мейеру вы заметите, что RAID5 не рекомендуется, потому что вероятность сбоя при перестройке слишком высока - тот же самый потенциальный сбой является основным аргументом против суперплотных узлов.

В дни pre-vnodes, если у вас был 20T node, который умер, и вам пришлось его восстановить, вам нужно было бы потопить 20T из соседних (2-4) узлов, что бы максимизировать все из этих узлов, увеличивают вероятность отказа, и для восстановления вниз node потребуется (часы/дни). За это время вы работаете с уменьшенной избыточностью, что может представлять риск, если вы оцениваете свои данные.

Одна из причин, по которым многие люди оценили многие, заключается в том, что она распределяет нагрузку на большее количество соседей - теперь потоковые операции для загрузки вашей замены node поступают из десятков машин, распространяя нагрузку. Однако у вас все еще есть фундаментальная проблема: вы должны получить 20T данных на node без сбоя загрузки. Потоковая передача долгое время была более хрупкой, чем хотелось бы, и шансы потоковой передачи 20T без сбоев в облачных сетях не являются фантастическими (хотя опять же, все становится лучше и лучше).

Можете ли вы запустить узлы 20T? Конечно. Но какой смысл? Почему бы не запустить 5 узлов 4T - вы получите больше избыточности, вы можете уменьшить объем процессора/памяти соответственно, и вам не придется беспокоиться о повторной загрузке 20T одновременно.

Наши "плотные" узлы - это 4T GP2 EBS тома с Cassandra 2.1.x(x >= 7, чтобы избежать OOM в 2.1.5/6). Мы используем один том, потому что, пока вы предлагаете "cassandra теперь поддерживает JBOD достаточно хорошо", наш опыт заключается в том, что использование алгоритмов балансировки Cassandra вряд ли даст вам то, что, по вашему мнению, будет - IO будет громовым стадом между устройствами (подавить один, затем подавить следующий и т.д.), они будут заполняться асимметрично. Для меня это отличный аргумент против большого количества небольших томов - я бы предпочел просто увидеть последовательное использование на одном томе.

Ответ 2

Я не использовал KairosDB, но если он дает вам некоторый контроль над тем, как используется Cassandra, вы можете изучить несколько вещей:

• Посмотрите, можете ли вы использовать инкрементный ремонт вместо полного ремонта. Поскольку ваши данные являются неизменяемыми временными рядами, вам не придется часто ремонтировать старые SSTables, поэтому инкрементный ремонт просто восстанавливает последние данные.

• Архивировать старые данные в другом ключевом пространстве и редко ремонтировать это пространство ключей, например, при изменении топологии. Для рутинного ремонта только отремонтируйте "горячее" пространство ключей, которое вы используете для последних данных.

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

• Существуют и другие варианты ремонта, которые могут помочь, например, я нашел, что параметр -local значительно ускоряет ремонт, если вы используете несколько центров обработки данных. Или, может быть, вы могли бы выполнять ограниченный ремонт чаще, чем производительность, убивая полный ремонт всего.

У меня есть кластеры Cassandra, которые используют RAID5. До сих пор это работало нормально, но если два диска в массиве терпят неудачу, то node становится непригодным, поскольку запись в массив отключена. Затем кто-то должен вручную вмешаться, чтобы исправить неисправные диски или удалить node из кластера. Если у вас много узлов, то сбои диска будут довольно распространенным явлением.

Если никто не даст вам ответа о запуске 20 узлов ТБ, я бы предложил запустить некоторые эксперименты на вашем собственном наборе данных. Настройте один 20 ТБ node и заполните его своими данными. Когда вы его заполняете, контролируйте пропускную способность записи и выясняйте, есть ли недопустимые потери в пропускной способности при возникновении компромиссов, и сколько TB это становится невыносимым. Затем добавьте пустой 20 ТБ node в кластер и выполните полный ремонт нового node и посмотрите, сколько времени потребуется, чтобы перенести на него половину набора данных. Это даст вам представление о том, сколько времени потребуется для замены неудавшегося node в вашем кластере.

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

Ответ 3

Я бы рекомендовал подумать о модели данных вашего приложения и о том, как разбить ваши данные. Для данных временных рядов, вероятно, имеет смысл использовать составной ключ [1], который состоит из ключа раздела + одного или нескольких столбцов. Разделы распределяются между несколькими серверами в соответствии с хэшем ключа раздела (в зависимости от используемого вами Partitioner Cassandra, см. Cassandra.yaml).

Например, вы можете разбить свой сервер на устройство, которое генерирует данные (шаблон 1 в [2]) или на определенный промежуток времени (например, в день), как показано в шаблоне 2 в [2].

Вы также должны знать, что максимальное количество значений для каждого раздела ограничено 2 миллиардами [3]. Поэтому очень рекомендуется разбиение на разделы. Не сохраняйте все ваши временные ряды на одном Cassandra node в одном разделе.

[1] http://www.planetcassandra.org/blog/composite-keys-in-apache-cassandra/

[2] https://academy.datastax.com/demos/getting-started-time-series-data-modeling

[3] http://wiki.apache.org/cassandra/CassandraLimitations