Статьи

Solr 3.1+: обработчик обновлений JSON

После выпуска Solr 3.1 я решил изучить расширенный список форматов, с помощью которых мы можем обновлять индексы. До сих пор у нас был выбор из трех типов форматов, с помощью которых мы могли предоставлять данные — XML, CSV и т. Д. называется JavaBin. Выпуск Solr 3.1 представляет четвертый формат — JSON.

Давайте начнем

Новый обработчик ( JsonUpdateRequestHandler ) позволяет нам передавать данные в формате JSON, который теоретически должен преобразовывать в меньший объем данных, передаваемых по сети, и ускорять индексирование, поскольку синтаксический анализатор JSON теоретически быстрее синтаксических анализаторов XML. Но давайте пока оставим представление.

конфигурация

Давайте начнем с определения обработчика. Для этого добавьте следующее определение в файл solrconfig.xml (если вы используете файл solrconfig.xml по умолчанию, поставляемый с Solr 3.1, этот обработчик уже определен):

<requestHandler name="/update/json" class="solr.JsonUpdateRequestHandler" startup="lazy" />

Запись выше определяет новый обработчик, который будет инициализирован при первом использовании ( startup = ”lazy” ).

индексирование

Следующим шагом является подготовка данных — конечно в формате JSON. Вот пример, показывающий два документа в одном файле с именем data.json :

{

"add": {
  "doc": {
    "id" : "123456788",
    "region" : ["abc","def"],
    "name" : "ABCDEF",
  }
}

,
"add": {
  "doc": {
    "id" : "123456789",
    "region" : ["abc","def"],
    "name" : "XYZMN",
  }
}

}

Такой подготовленный файл может быть отправлен по адресу / update / json и, таким образом, проиндексирован. Не забудьте отправить команду фиксации на соответствующий адрес (стандарт / обновление ), чтобы указать Solr открыть новый поисковик индекса.

Производительность

В конце я оставил себе то, что меня действительно больше всего интересует — производительность нового обработчика. В соответствии с информацией, хранящейся в системе JIRA, можно ожидать, что JsonUpdateRequestHandler будет быстрее, чем его аналог процессора в формате XML. Чтобы проверить это, я подготовил файлы из 10.000, 100.000 и 1 миллиона документов. Каждый документ содержал идентификатор (строковое поле), две области (строковое поле, многозначное) и имя (текстовое поле). Один файл был сохранен в формате JSON, второй — в формате XML, третий — в формате CSV. Все файлы были проиндексированы отдельно. Вот результат этого простого теста:

Количество документов Вес данных Время индексации XML Время индексации JSON Время индексации CSV
10,000 JSON:1.19MB
XML:1.88MB
CSV: 394KB
954ms 734ms 732ms
100.000 JSON:12.4MB
XML:19.3MB
CSV: 4.33MB
7656ms 6222ms 6203ms
1.000.000 JSON:129MB
XML:197MB
CSV: 48.1MB
126625ms 119023ms 108234ms

The conclusions suggest themselves. First, XML data is relatively larger than the one written in JSON format (the difference is about 35%). However, a file stored in JSON format, is larger (which might be expected) than the one written in the CSV. If you send data not on the local network, the size is relevant – the difference in file size is significant enough that it is worth thinking about changing the XML to any of the formats that require less space.

Indexation time

Another thing is the indexing time. Leaning on the results of this simple test we can think that JsonUpdateRequestHandler is slightly (about 7 – 9%) faster than the XmlUpdateRequestHandler. As you can see, the difference is similar for JsonUpdateRequestHandler and CSVRequestHandler, where the handler operates on files in CSV format is faster than its counterpart that operates in JSON format by about 7 to 9%. Let’s hope that when the noggit library comes out of Apache Labs, its performance will be even greater, and thus we will see even faster JsonUpdateRequestHandler.