Перейти к основному содержимому

Коммиты и поиск NRT в SolrCloud

· 5 мин. чтения

1. Обзор

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

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

2. Индексирование в SolrCloud

Коллекция в Solr состоит из нескольких осколков, и у каждого осколка есть разные реплики. Одна из реплик сегмента выбирается в качестве лидера для этого сегмента при создании коллекции:

  • Когда клиент пытается проиндексировать документ, документу сначала назначается сегмент на основе хэша идентификатора документа.
  • Клиент получает URL-адрес лидера этого сегмента от zookeeper, и, наконец, на этот URL-адрес делается запрос индекса.
  • Лидер сегмента локально индексирует документ перед отправкой на реплики.
  • Как только лидер получает подтверждение от всех активных и восстанавливающихся реплик, он возвращает подтверждение клиентскому приложению индексации.

Когда мы индексируем документ в Solr, он не попадает в индекс напрямую. Это записывается в так называемый tlog (журнал транзакций). Solr использует журнал транзакций, чтобы гарантировать, что документы не будут потеряны до их фиксации в случае сбоя системы.

Если система дает сбой до того, как документы в журнале транзакций будут зафиксированы, т. е. сохранены на диске, журнал транзакций воспроизводится повторно при восстановлении системы, что приводит к нулевой потере документов.

Каждый запрос индекса/обновления регистрируется в журнале транзакций, который продолжает расти, пока мы не выполним коммит.

3. Коммиты в SolrCloud

Операция фиксации означает завершение изменения и сохранение этого изменения на диске. SolrCloud предоставляет два вида операций фиксации, а именно. фиксация и мягкая фиксация.

3.1. Фиксация (жесткая фиксация)

Фиксация или жесткая фиксация — это та, в которой Solr сбрасывает все незафиксированные документы в журнале транзакций на диск. Активный журнал транзакций обрабатывается, а затем открывается новый файл журнала транзакций.

Он также обновляет компонент, называемый средством поиска, чтобы вновь зафиксированные документы стали доступными для поиска. Средство поиска можно рассматривать как доступное только для чтения представление всех зафиксированных документов в индексе.

Операция фиксации может быть выполнена исключительно клиентом, вызвав API фиксации :

String zkHostString = "zkServer1:2181,zkServer2:2181,zkServer3:2181/solr";
SolrClient solr = new CloudSolrClient.Builder()
.withZkHost(zkHostString)
.build();
SolrInputDocument doc1 = new SolrInputDocument();
doc1.addField("id", "123abc");
doc1.addField("date", "14/10/2017");
doc1.addField("book", "To kill a mockingbird");
doc1.addField("author", "Harper Lee");
solr.add(doc1);
solr.commit();

Точно так же его можно автоматизировать как autoCommit , указав его в файле solrconfig.xml , см. раздел 3.4.

3.2. SoftCommit

Softcommit был добавлен, начиная с Solr 4, в первую очередь для поддержки функции NRT в SolrCloud. Это механизм, позволяющий осуществлять поиск по документам почти в реальном времени, пропуская дорогостоящие аспекты жестких коммитов.

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

Когда мы указываем maxTime для softcommit как 1000, это означает, что документ будет доступен в запросах не позднее 1 секунды с момента его индексации.

Эта функция предоставляет SolrCloud возможность поиска практически в реальном времени, поскольку новые документы можно сделать доступными для поиска даже без их фиксации. Softcommit можно запустить только как autoSoftCommit , указав его в файле olrconfig.xml , см. раздел 3.4.

3.3. Автокоммит и Автософткоммит

Файл solrconfig.xml — один из самых важных файлов конфигурации в SolrCloud. Он генерируется во время создания коллекции. Чтобы включить autoCommit или autoSoftCommit , нам нужно обновить следующие разделы в файле:

<autoCommit>
<maxDocs>10000</maxDocs>
<maxTime>30000</maxTime>
<openSearcher>true</openSearcher>
</autoCommit>

<autoSoftCommit>
<maxTime>6000</maxTime>
<maxDocs>1000</maxDocs>
</autoSoftCommit>

maxTime: количество миллисекунд с момента самого раннего незафиксированного обновления, после которого должна произойти следующая фиксация/мягкая фиксация.

maxDocs: количество обновлений, которые произошли с момента последней фиксации и после которых должна произойти следующая фиксация/мягкая фиксация.

openSearcher: это свойство сообщает Solr, следует ли открывать новый поисковик после операции фиксации или нет. Если это правда , после фиксации старый поисковик закрывается, и открывается новый поисковик, делая зафиксированный документ видимым для поиска . Если это ложь , документ не будет доступен для поиска после фиксации.

4. Поиск почти в реальном времени

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

Обычные коммиты обходятся дорого, поэтому программные коммиты полезны. Но, поскольку softcommit не сохраняет документы, нам нужно установить интервал maxTime autocommit (или maxDocs ) в разумное значение, в зависимости от ожидаемой нагрузки.

4.1. G et s в реальном времени

Есть еще одна функция, предоставляемая Solr, которая работает в режиме реального времени — get API. Get API может вернуть нам документ, который еще даже не был мягко зафиксирован. ``

Он ищет непосредственно в журналах транзакций, если документ не найден в индексе. Таким образом, мы можем запустить вызов get API сразу после возврата вызова index, и мы по-прежнему сможем получить документ.

Однако, как и во всех слишком хороших вещах, здесь есть одна загвоздка. Нам нужно передать идентификатор документа в вызове get API. Конечно, мы можем предоставить другие фильтрующие запросы вместе с id , но без id вызов не работает:

http://localhost:8985/solr/myCollection/get?id=1234&fq=name:foreach

5. Вывод

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

Мы не должны делать интервал фиксации слишком длинным, иначе наш журнал транзакций вырастет до значительного размера. Однако мы не должны выполнять наши программные коммиты слишком часто.

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