Назад | Перейти на главную страницу

Cassandra: планирование мощности

Я исследую перенос некоторых больших БД из MySQL в Cassandra, и я пытаюсь понять, как спланировать кластер. Исторически сложилось так, что можно было бы просто купить диски для хранения соответствующих данных, но я не понимаю, как Cassandra использует дисковое пространство по сравнению с пространством RAM.

При планировании кластера возникает вопрос, сколько машин, сколько дисков, ОЗУ и т. Д. На машину. Как мне ответить на это за 1Тб? 10 Тб? Больше?

Планирование мощности действительно это наука (в плане математики / статистики). Поскольку математические модели никуда вас не приведут, вам действительно нужно настроить испытательный стенд, который можно использовать для ответа на ваши вопросы, поскольку никто здесь не может предоставить вам теоретическую модель, которую вы, похоже, просите.

Как на это ответить:

  1. Получите (масштабируемую) тестовую площадку
  2. Заполните его своими данными
  3. Напишите соответствующие инструменты для создания нагрузки
  4. Приложите нагрузку и измерьте
  5. Измерьте и проведите проверку ваших результатов
  6. При желании настройте и, возможно, снова перейдите к 3. или 4.

или наймите профессионала.

По сути, формула для диска на узел это D x RF / N x O / C с переменными, определенными ниже:

  • D - ваш общий размер данных.
  • RF - ваш фактор репликации. В большинстве кластеров используется как минимум 2 (для надежности) или 3 (для комбинированной надежности и доступности при CL = Quorum).
  • N - количество узлов в вашем кластере. Это должно быть как минимум RF. Вы также захотите увеличить это число, пока не получите удобный результат «диск на узел».
  • O - множитель накладных расходов для индексов и несвязанных стабильных файлов на диске. Я бы использовал здесь как минимум коэффициент O = 2, если у вас почти нет индексов и чрезвычайно стабильных данных.
  • C - это фактор, который вы сэкономите с поддержкой сжатия Cassandra 1.0+, если вы его включите. Это будет примерно экономия, которую вы получите от сжатия файла с репрезентативным содержимым. Используйте C = 1, если сжатие отключено. Если сжатие имеет тенденцию сокращать размер ваших данных вдвое, попробуйте C = 0,6 или около того, потому что сжатие используется не для всего (например, для индексов).

После того, как вы получили некоторые числа, вы должны выбрать «диск на узел», который составляет не более 30% доступного локального хранилища, чтобы вам не приходилось немедленно наращивать кластер, и поэтому возможны моментальные снимки.

Планирование памяти намного больше зависит от того, как выглядит ваша схема, но вам понадобится как минимум 4 ГБ, выделенные для Cassandra на каждом узле. ОС сможет использовать что угодно, кроме этого, для очень полезного кэширования диска. Больше памяти становится полностью бесполезным только тогда, когда она существенно превышает реальный объем данных, находящихся на диске.