Как работает обработчик запросов Solr / sql без коллекции, содержащей какие-либо данные?

#solr

#solr

Вопрос:

Я просматриваю документацию Solr для параллельного интерфейса SQL. В разделе «Лучшие практики» я вижу следующее:

Имеет смысл создать отдельную коллекцию SolrCloud только для обработчика / sql. Эта коллекция может быть создана с использованием стандартного API сбора SolrCloud. Поскольку эта коллекция существует только для обработки запросов / sql и предоставления пула рабочих узлов, в этой коллекции не требуется хранить какие-либо данные.

Я не понимаю, как поможет наличие отдельной коллекции, и это тоже без данных. Я бы предположил, что наличие коллекции, в которой находятся данные, и настройка /sql обработчика в этой коллекции — это правильный путь, потому что сами блоки Solr будут пулом рабочих узлов. Как здесь помогает наличие новой коллекции только для обработки /sql запросов? И как он функционирует без данных? Может кто-нибудь, пожалуйста, объяснить?

Ответ №1:

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

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

Иллюстрация таблицы данных, показанная в руководстве (ниже цитаты, на которую вы ссылаетесь), показывает, как это работает:

График, показывающий, как каждый рабочий узел связывается с каждой коллекцией для получения их результатов

Комментарии:

1. Спасибо MatsLindh. Итак, если я правильно понимаю, вы говорите, что у меня будет 2 коллекции — одна с моими бизнес-данными, а другая без данных с неявным /sql обработчиком, верно? Если я использую JDBC для подключения, мне придется подключиться ко 2-й коллекции. Поскольку я укажу, к какой коллекции точно запрашивать, нет никакой двусмысленности, в какой коллекции будут выполняться предложения WHERE. Это правильно?

2. Правильно. Данные будут из коллекции, указанной в FROM части вашей коллекции SQL. Вы подключитесь к «meta»-коллекции, содержащей ваш обработчик sql.

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

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