Блог

Это более широкий вопрос, связанный с построением архитектуры для приложения псевдонимов с маршрутизацией времени SolrCloud. Я использую SolrCloud для регулярного приема данных временных рядов, и SolrCloud работает в кластере Kubernetes. Узел Solr подключается каждый раз, когда мы добавляем новый модуль в наш кластер. У каждого модуля есть постоянное требование объема, поэтому мы также масштабируем наше хранилище.

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

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

Я не уверен, какой будет наилучшая конфигурация на уровне коллекции / кластера на основе доступных политик в https://solr.apache.org/guide/8_6/solrcloud-autoscaling-policy-preferences.html

В настоящее время я создаю коллекции с еженедельными интервалами, и мои варианты использования включают поиск по данным не менее 2 недель. Поскольку полученные данные будут помещены в новые модули, мои клиентские приложения, обращенные к стороне клиента, будут каждый раз бомбардировать новые модули.

Коэффициент репликации каждой коллекции равен 2, а параметр numShards равен 2.

Какой уровень конфигурации на уровне коллекции / псевдонима / кластера я должен использовать, чтобы избежать «горячих точек»?