Я прошел через рекомендуемую архитектуру конфигурации узла Cassandra! согласно которому рекомендуемая аппаратная инфраструктура для узла должна иметь
ОЗУ: 16-32 ГБ,
место хранения: 500 ГБ - 1 ТБ и
64 бит ЦПУ с 8 ядрами
документация по datastax говорит
«Максимальная рекомендуемая емкость для Cassandra 1.2 и более поздних версий составляет от 3 до 5 ТБ на узел».
У меня тяжелая система записи, скажем, 10 КБ записей в секунду, начальные требования к хранилищу данных - 72 ТБ, и если я выберу 1 ТБ на узел, мне нужно будет иметь почти 80 узлов (с учетом накладных расходов). Цель состоит в том, чтобы уменьшить узел число, добавив дополнительную емкость хранения данных на каждый узел.
мой вопрос
1. Согласно документации, 16-32 ГБ ОЗУ нормально работают с загрузкой данных 500-1 ТБ. Итак, когда мне нужно будет добавить больше дискового пространства, 3-5 ТБ на узел, мне придется также увеличить ОЗУ и ЦП?
2. есть ли корреляция между размером хранилища и RAM + CPU
Я думаю, насколько хорошо это будет работать, будет зависеть от вашего набора данных и вашей нагрузки. Нет прямой корреляции между размером хранилища и ОЗУ + ЦП, однако, если вы ожидаете, что в 3 раза больше операций чтения и записи с 1 ТБ до 3 ТБ, то вы можете ожидать, что вам нужно будет учесть это с большим объемом ОЗУ и ЦП, поскольку хорошо, но вам, скорее всего, не потребуется увеличивать ваш ЦП и ОЗУ 1: 1 с вашим хранилищем (то есть, если вы перейдете с 1 до 3 ТБ диска, вам не понадобится 3x ОЗУ для размещения). В общем, вы обнаружите, что ввод-вывод является узким местом, поэтому наличие быстрых дисков (SSD!) Является наиболее важным.
Я запускал узлы с 3 ТБ данных, и это работало без особых проблем. Необходимо было провести много настройки, поэтому, если у вас нет кого-то в команде, у которого есть большой опыт настройки Cassandra, я бы не рекомендовал это, если это не является жестким требованием. Вам нужно быть осторожным с оперативной памятью и тем, сколько кучи вы назначите процессу Cassandra jvm. Максимальный рекомендуемый размер кучи для Cassandra составляет 8 ГБ, поскольку сборка мусора становится более разрушительной с большими кучами (если вы не используете Azul Zing), а менее частые полные сборщики мусора могут привести к фрагментации, которая влияет на производительность. Как правило, запускать Java-приложения с кучей размером более 8 ГБ - не лучший вариант, если этого можно избежать.
В более новых версиях Cassandra вы можете переместить много информации из кучи в собственную память. Начиная с версии 1.2, фильтры Блума и метаданные сжатия были перемещены из кучи в собственную память. В 2.1 теперь вы можете выделить memtables из кучи, это может помочь вам работать с большим набором данных. Таким образом, теперь вы можете получить больше от большего объема оперативной памяти при сохранении разумной кучи (8 ГБ).
Я рекомендую всегда больше склоняться в сторону меньших узлов. Эти рекомендации существуют по какой-то причине, и я думаю, в основном потому, что Кассандра более доказала, что ее используют таким образом. Cassandra отлично работает с облачными провайдерами, а с обычным оборудованием вам может даже оказаться дешевле иметь больше меньших узлов, чем меньшее количество больших. Там, где это может стать дорогостоящим, так это в эксплуатации, но если вы используете хорошие инструменты управления конфигурацией, такие как puppet или chef, это становится менее затратным. Это также становится труднее сделать с помощью специального оборудования.
Я бы порекомендовал не верить никому на слово, а попробовать протестировать различные конфигурации в EC2 или другом облачном провайдере и посмотреть, что лучше всего подходит для вашего приложения. Ваш профиль нагрузки и набор данных действительно будут определяющим фактором того, сработает это или нет. Не могу не подчеркнуть, провожу много тестов с разными конфигурациями! Как только вы решились на что-то, становится сложно (но не невозможно) отключиться. Как человек, прошедший через 3 разные конфигурации кластера для одного приложения, я не могу не подчеркнуть этого :). Чтобы проверить это, новый инструмент стресса Включенный в Cassandra 2.1, действительно упрощает создание сценария загрузки, отражающего то, что будет делать ваше приложение. Cassandra очень настраиваема и имеет много хороших показателей для измерения производительности, поэтому использование инструмента стресса также дает вам возможность попробовать различные варианты и узнать больше об управлении экземплярами Cassandra (настройка memtable, уплотнение и другие параметры, чтобы почувствовать). Одна или две недели тестирования избавят вас от нескольких месяцев лишений!