После выпуска 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.