Только что начал на Solandra и пытался понять детали шардинга Solandra 2-го уровня.
AFAIK Soalndra создает количество сконфигурированных шардов (как свойство «solandra.shards.at.once»), где каждый шард размером до solandra.maximum.docs.per.shard.
На следующем уровне он начинает создавать слоты внутри каждого шарда, которые определяются как «solandra.maximum.docs.per.shard» / «solandra.index.id.reserve.size».
То, что я понял из модели данных SchemaInfo CF, что внутри определенного шарда есть слоты, принадлежащие разным физическим узлам, и это гонка, происходящая между узлами для получения этих слотов.
Мои вопросы:
Означает ли это, если я запрашиваю запись на конкретном узле solr, например. ....solandra/abc/dataimport?command=full-import распространяется ли этот запрос на все возможные узлы и т. Д.Это распределенная запись?Потому что до тех пор, пока это не произойдет, как другие узлы будут конкурировать за слоты внутри конкретного шарда. В идеале код для написания документа или набора документов будет выполняться на одной физической JVM.
С помощью шардинга мы попытались записать несколько документов на одном физическом узле, но если он пишет на основе слотов, принадлежащих разным физическим узлам, чего мы на самом деле достигли, когда мы снованужно получить результаты из разных узлов.Я понимаю, что пропускная способность записи максимальна.
Можем ли мы посмотреть на настройку этих чисел -?"solandra.maximum.docs.per.shard", "solandra.index.id.reserve.size","solandra.shards.at.once".
Если у меня только один осколок и коэффициент репликации равный 5 в одной установке узла DC 6, я увидел, что конечные точки этогошард содержит 5 конечных точек в соответствии с фактором репликации. Но что происходит с шестым.Я видел через nodetool, что левый 6-й узел действительно не получает никаких данных.Если я увеличу коэффициент репликации до 6, оставив кластер включенным, это решит проблему и выполнит ремонт и т. Д. Или найдется лучший способ.