SOLR и VNodes и токены

Примечание. Я немного переформатировал и добавил дополнительную информацию.

Пожалуйста, взгляните на это: Question_Answer

Я хочу спросить - с DSE 5.0 и грядущие изменения, которые были упомянуты на саммите C* в этом году для 5.1 и 5.2, будет ли полезен тот же совет?

Наш вариант использования:

Платформа ДОЛЖНА быть доступна в любое время. (Кассандра)
Данные должны быть доступны для поиска. (SOLR / Lucene)
Платформа ДОЛЖНА обеспечивать аналитику / хранилище данных / BI и т. д. (Graph / Spark)

Все это возможно в одном продукте благодаря DSE! Спасибо ДатаСтакс!

Vnodes добавляет дополнительные накладные расходы для части решения поиска, связанной с сбором и разбросом. В некоторых тестах этот показатель достигает 30%. Некоторые клиенты готовы мириться с такими накладными расходами и хотят использовать виртуальные узлы из-за преимуществ динамического масштабирования.


datastax-enterprise datastax-startup
person Gavin Baumanis    schedule 06.10.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Если у вас есть или вы планируете создать небольшой кластер, и вам не нужно масштабировать его на лету, я определенно рекомендую использовать отдельные токены. Скрытое преимущество такого подхода заключается в том, что ваш ремонт также будет немного быстрее. Это помогает с поиском, когда вы читаете эквивалент CL.ONE.

Можно запустить все функции на одном контроллере домена (поиск, аналитика и теперь график), но вы обнаружите, что накладные расходы возрастают. Вам потребуются более крупные узлы с большим объемом памяти и ресурсов процессора, чтобы справиться с вычислительной нагрузкой. Я бы, наверное, начал со 128 ГБ оперативной памяти и пошел дальше. Думаю, если ваша нагрузка действительно невелика, вам может сойти с рук меньше. Как и во всем, бенчмаркинг в масштабе, который вы собираетесь запустить, является ключевым.

Кстати, мне не совсем понятны ваши намерения в отношении РФ. Вы подразумеваете 2 узла и RF = 3. Я предполагаю, что это просто фраза, но если нет - стоит отметить, что вам нужно как минимум столько же узлов, сколько RF для лучшего покрытия!

ВРТ в РФ; с 2 узлами на стойку: и 2 стойки - всего 4 узла в центре обработки данных. Если я что-то не упустил - что, конечно, может быть, - здесь RF, равный 3, будет работать.

person Nom de plume    schedule 06.10.2016
comment
О, пропустил 2 гонки - да, это должно быть хорошо. - person Gavin Baumanis; 06.10.2016
comment
Если вы решите использовать vnodes с поиском DSE в версии 5.0.x (или более ранней), имейте в виду, что вам может потребоваться настроить размер кеша фильтра Solr, чтобы обеспечить разумную производительность запросов. (Конечно, вы должны использовать DSE SolrFilterCache, который ограничивает использование глобальной памяти, а не реализации кэша OSS Solr.) - person Nom de plume; 06.10.2016
comment
Но объем хранимых данных и количество транзакций у нас ОЧЕНЬ скромные.
Наша спецификация рассчитана на 100 одновременных сеансов в приложении, что, конечно, даже не означает 100 одновременных запросов/операций к БД.
< br /> По большей части наше приложение напоминает повседневное корпоративное CRUD-приложение.

Хотя это и не смешно, экземпляры AWS не совсем бесплатны.
Наличие отдельного кластера для каждой рабочей нагрузки (с достаточным репликация для непрерывной доступности), будет для нас проблемой стоимости.

Хотя я понимаю, доказательство концепции может предложить некоторую помощь — но без реальной рабочей нагрузки / реальных пользователей — проходя через сервисы / приложения - таким образом, что только «производственная» система и мошеннические пользователи могут действительно дать представление. Лучшее, что вы можете сделать, это «нагрузить» функциональное тестирование.

Короче говоря, мы немного застряли здесь с точки зрения платформы.

Сначала мы думали, наличие:

2 центров обработки данных для географической изоляции
2 стойки на ЦОД
2 узла на стойку
RF из 3
CL из local_quorum

Если мы обнаружим, что сталкиваемся с проблемами производительности, мы можем увеличить масштаб — добавить дополнительную стойку или дополнительные узлы к первоначальным 2 стойкам.

Что касается V-узлов или количества токенов. , мы понятия не имеем.

В документации по поиску DSE говорится, что V-узлы увеличивают нагрузку на 30 %, поэтому похоже, что вам не следует использовать V-узлы, но затем в таблице в документации указано, что также говорит использовать 16 или 32. Как может быть и то, и другое?

Если мы можем успешно выполнять все рабочие нагрузки на одном узле (наши требования действительно минимальны), мы будем работать с V-узлами (16 или 32) или мы запускаем один токен?

Наконец, есть ли другая альтернатива?
Могут ли у вас быть узлы с разными wo? rkloads в одном дата-центре? Где отдельные узлы настроены с требованиями к ОЗУ/ЦП для конкретной рабочей нагрузки?

Предположим, что у нас 4 узла на каждый центр обработки данных (только в качестве отправной точки — мы понятия не имеем, сможете ли вы успешно запустить поиск на одном узле / или Spark на одном узле)

Узел 1: Просто Cassandra
Узел 2: Cassandra и поиск
Узел 3: Cassandra и Graph
Узел 4 : Cassandra и Spark

Если для поиска требуется 64 ГБ ОЗУ — пусть будет так... но узел Cassandra only может работать только с 8 или 16.

Так что мы можем с точки зрения ЦП и памяти для каждого типа рабочей нагрузки, но при этом иметь только один контроллер домена. (У нас будет 2 для резервирования, но фактически это один DC: зеркальный)

Заранее спасибо за вашу помощь.
- person Caleb Rackliffe; 06.10.2016