Пользовательский шардинг или автоматический шардинг в SolrCloud?

Я хочу создать clsuter SolrCloud для более чем 10 миллионов новостных статей. После прочтения этой статьи: Shards и индексирование данных в SolrCloud, у меня следующий план:

  1. Добавьте префикс ED2001! к идентификатору документа, где ED означает какой-то газетный источник, а 2001 — часть года в дате публикации новостной статьи, т.е. я хочу поместить все новостные статьи из определенного источника новостей, опубликованные в определенном году, в осколок.
  2. Создайте коллекцию с router.name, для которого задано значениеcompositeID.
  3. Добавить документы?
  4. Сбор запросов?

Практически у меня возникли вопросы:

  1. Как добавить документы на основе этого плана? Нужно ли указывать специальные параметры при обновлении коллекции/ядра?
  2. Это называется пользовательским шардингом? Если нет, то что такое пользовательский шардинг?
  3. Является ли автоматическое разбиение лучшим выбором для моего случая, поскольку есть функция разбиения на осколки для автоматического разбиения, когда осколок слишком большой?
  4. Могу ли я запросить без параметра _router_?

РЕДАКТИРОВАТЬ @ 2015/9/2:

  1. Вот как я думаю, что SolrCloud будет делать: количество новостных статей в конкретном газетном источнике за определенный год имеет тенденцию быть около фиксированного числа, например. Каждый год в ED публикуется около 80 000 статей, поэтому размер каждого сегмента не будет сильно увеличиваться. Для новостных статей ED в следующем году мне нужно только добавить префикс «ED2016!» к идентификатору документа, SolrCloud создаст для меня новый сегмент (который содержит все статьи ED2016), а позже лидер распространит реплику этого нового сегмента на другие узлы (на реплику на узел, кроме лидера?). Я прав? Если да, кажется, нет необходимости в разделении осколков.

person Scott Chu    schedule 02.09.2015    source источник


Ответы (2)


Ответ-1: Если у вас есть схема (структура) документа, вы можете указать ее в конфигурации schema.xml или использовать режим schema-less Solr для индексации документа. Режим schema-less автоматически идентифицирует поля в вашем документе и проиндексирует их. Конфигурация режима schema-less немного отличается от режима конфигурации на основе схемы в solr. После этого вам нужно отправить документы в solr для индексации с помощью curl или solrj java api. По сути, solr предоставляет конечные точки отдыха для всех различных операций. Вы можете написать клиент на любом языке, который вам больше подходит.

Ответ 2. То, что вы упомянули в своем плане, а именно использование compositeId, называется индивидуальным сегментированием. Потому что вы сами решаете, в какой шард должен попасть тот или иной документ.

Ответ-3: я бы посоветовал использовать функцию автоматического сегментирования, если вы не уверены, сколько данных вам нужно проиндексировать в настоящее время и в будущем. По мере увеличения размера индекса вы можете разделить осколки и масштабировать solr по горизонтали.

Ответ-4: Я просмотрел документацию solr, нигде не нашел упоминания _route_ в качестве обязательного параметра. Но в некоторых ситуациях это может повысить производительность запросов, поскольку устраняет задержку в сети при запросе всех сегментов.

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

person YoungHobbit    schedule 02.09.2015
comment
Если вы используете collection api solr для создания осколков и не используете механизм маршрутизации документов по умолчанию, то в будущем вы сможете добавлять/удалять осколки в своей коллекции. Подход, который вы описали в своем вопросе, является правильным и, похоже, соответствует вашим требованиям. - person YoungHobbit; 02.09.2015
comment
\@abhishek: Я использую составной идентификатор для двух целей: Во-первых, для управления размером сегмента, так как каждый год нет каждого источника. статей всегда около стабильного количества (я редактирую свой вопрос, исходя из этой мысли). В практическом применении пользователи постоянно запрашивают статьи на основе диапазона лет, поэтому я могу применить _route_ со списком определенного года, как вы упомянули в своем ответе. - person Scott Chu; 02.09.2015
comment
Ваше мышление и подход верны и кажутся мне практичными. Вот ссылка на Collection API. - person YoungHobbit; 02.09.2015
comment
Я бы посоветовал вам запустить сервер solr в облачном режиме и создать сегмент, используя collection api, и использовать compositeID для маршрутизации документа. Сначала начните с двух сегментов, проиндексируйте несколько (n,m) документов в каждом сегменте, а затем добавьте новый сегмент в ту же коллекцию, используя collection api. В основном вы не указываете количество осколков во время запуска solr. Это решит вашу цель. - person YoungHobbit; 02.09.2015
comment
Мне нужно изменить свой подход, так как составной идентификатор должен сначала указать numShards, и я никак не могу знать, сколько лет документов я вложу. Моя мысль в вопросе 5 кажется неправильной! Возможно, мне придется использовать неявный маршрутизатор с самого начала. - person Scott Chu; 02.09.2015
comment
Если вы используете маршрутизатор CompositeId, вы можете отправлять документы с префиксом в идентификаторе документа, который будет использоваться для вычисления хэша, который Solr использует для определения сегмента, в который отправляется документ для индексации. Это от Документация Solr. Я не понимаю одного, где говорится, что если вы используете compositeId, вам нужно использовать опцию numShards. - person YoungHobbit; 02.09.2015
comment
Ознакомьтесь с разделом Collections API в разделе «Конфигурация и параметры SolrCloud» в справочном руководстве. В описании параметра запроса 'numShards' действия CREATE указано количество осколков, которые должны быть созданы как часть коллекции. Это обязательный параметр при использовании маршрутизатора compositeId. - person Scott Chu; 03.09.2015

На самом деле это руководство, чтобы ответить на мой собственный вопрос:

Я понимаю некоторые понятия:

  1. "индивидуальное сегментирование" НЕ ЯВЛЯЕТСЯ "настраиваемым хешированием".
  2. Solr в среднем разделяет хэш-значения по умолчанию.
  3. Маршрутизатор CompositeId применяет «настраиваемое хеширование», поскольку он изменяет поведение хеширования по умолчанию, добавляя префикс shard_key/количество битов.
  4. Неявный маршрутизатор применяет «настраиваемый сегмент», поскольку нам нужно вручную указать, на какие сегменты будут отправляться наши документы.
  5. Маршрутизатор CompositeId по-прежнему выполняет автоматическое разбиение, поскольку именно Solr видит префикс shard_key и направляет документы в определенные сегменты.
  6. Маршрутизатор CompositeId должен указать параметр numShards (возможно, потому, что Solr необходимо распределить различные диапазоны пространства хеш-значений для каждого из сегментов).

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

person Scott Chu    schedule 03.09.2015
comment
Что касается пункта 5, у Шона Хейзи есть хороший комментарий к моему вопросу об онлайн-документе Справочного руководства Aapche Solr: cwiki.apache.org/confluence/display/solr/ - person Scott Chu; 08.09.2015
comment
Таким образом, для данных временных рядов индивидуальная сегментация является лучшей стратегией, поскольку мы определяем, какие временные шкалы данных распределяются по каким сегментам. - person Scott Chu; 23.09.2015
comment
можно ли направить документы на определенный шард? например, если в коллекции есть два сегмента, shard_1 и shard_2, как проще всего перейти к shard_1? - person user482963; 05.07.2017