Соландра Шардинг: инсайдерские мысли

Question

Я только начал изучать 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 я понял, что внутри определенного шарда есть слоты, принадлежащие разным физическим узлам, и между узлами происходит гонка за этими слотами.

Мои вопросы:

1. Означает ли это, если я запрашиваю запись на конкретном узле Solr, например.....solandra/abc/dataimport?command=full-import распространяется ли этот запрос на все возможные узлы и т. д. Является ли эта распределенная запись? Потому что до тех пор, пока это не произойдет, как другие узлы будут конкурировать за слоты внутри конкретного шарда. В идеале код для написания документа или набора документов будет выполняться на одной физической JVM.

2. С помощью шардинга мы пытались написать несколько документов на одном физическом узле, но если он пишет на основе слотов, принадлежащих разным физическим узлам, чего мы на самом деле достигли, поскольку нам снова нужно получать результаты с разных узлов. Я понимаю, что пропускная способность записи максимальна.

3. Можем ли мы посмотреть на настройку этих чисел -? "solandra.maximum.docs.per.shard","solandra.index.id.reserve.size","solandra.shards.at.once"

4. Если у меня только один фрагмент и коэффициент репликации равный 5 в одной настройке узла DC 6, я увидел, что конечные точки этого сегмента содержат 5 конечных точек согласно коэффициенту репликации. Но что происходит с 6-м. Я видел через nodetool, что левый 6-й узел действительно не получает никаких данных. Если я увеличу коэффициент репликации до 6, оставив кластер включенным, это решит проблему и выполнит ремонт и т. Д. Или найдется лучший способ.

Answer 1

В целом параметр shards.at.once используется для управления параллелизмом индексации. чем выше это число, тем больше осколков записывается одновременно. Если вы установите его в единицу, вы всегда будете писать только в один осколок. Обычно это должно быть установлено на 20% > количество узлов в кластере. поэтому для кластера из четырех узлов установите его на пять.

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

Чем выше docs.per.shard, тем медленнее будут выполняться запросы для данного шарда. В общем, это должно быть 1-5M макс.

Чтобы ответить на ваши вопросы:

1. Это будет импортировать только с одного узла. но он будет индексироваться по многим в зависимости от шардов сразу.

2. Я думаю, что вопрос заключается в том, вы должны писать через все узлы? Да.

3. Да, смотри выше.

4. Если вы увеличите shards.at.once, это будет заполнено быстро