В Solr 3.1 и позже у нас есть очень интересная функциональность, которая позволяет нам сортировать по значению функции. Что это дает нам? Собственно, несколько интересных возможностей.
Давайте начнем
Первый пример, который приходит на ум, возможно, из-за проекта, над которым я работал некоторое время назад, это сортировка по расстоянию между двумя географическими точками. До настоящего времени для реализации такой функциональности были необходимы изменения в Solr (например, LocalSolr или LocalLucene ). Используя Solr 3.1 и более поздние версии, вы можете сортировать результаты поиска, используя значение, возвращаемое определенными функциями. Например, это Solr, у нас есть функция dist, вычисляющая расстояние между двумя точками. Одним из вариантов функции является функция, принимающая пять параметров: алгоритм и две пары точек. Если, используя эту функцию, мы хотим отсортировать результаты поиска в порядке возрастания от точки широты и долготы 0.0, мы должны добавить следующий параметр сортировки в запрос Solr:
...sort=dist(2, geo_x, geo_y, 0, 0) asc |
Я подозреваю, что наиболее часто используемые значения первого параметра будут:
- 1 — расчет на основе манхэттенских метрик
- 2 — расчет евклидова расстояния
Несколько слов о производительности
До сих пор все хорошо, но как это выглядит с точки зрения производительности? Я сделал два простых теста.
Во время первого теста я проиндексировал 200 000 документов, каждый из которых состоял из четырех полей: идентификатор (числовое поле), описание ( текстовое поле) и местоположение (два числовых поля). Для того , чтобы не затенять результаты испытаний для сортировки, я использовал один из самых простых функций , доступных в настоящее время в Solr — на сумму функцию , которая суммирует два данные аргументов. Я сравнил время запроса сортировки по умолчанию (по счету ) с теми, которые использовали значение функции. В следующей таблице приведены результаты теста:
| запрос | Количество результатов | Время запроса | Время повторного запроса |
|---|---|---|---|
| д = *: * & сортировать = оценка + убыв | 200,000 | 31ms | 0ms |
| д = *: * & рода = сумма (geo_x, geo_y) + убывание | 200,000 | 813ms | 0ms |
| д = опись: ала и сортировать = оценка + убыв | 200,000 | 47ms | 1мс |
| д = опись: ала и сортировки = сумма (geo_x, geo_y) + убывание | 200,000 | 797ms | 1мс |
Другой тест был основан на сравнении сортировки по строковому полю и сортировке с использованием функции. Тест был практически идентичен первому тесту. Я проиндексировал 200 000 проиндексированных документов (с дополнительным полем: name_sort — тип string ) и использовал функцию sum . В следующей таблице приведены результаты теста:
| запрос | Количество результатов | Время запроса | Время повторного запроса |
|---|---|---|---|
| д = *: * & рода = opis_sort + убывание | 200,000 | 267ms | 0ms |
| д = *: * & рода = сумма (geo_x, geo_y) + убывание | 200,000 | 823ms | 0ms |
| д = опись: ала и сортировки = opis_sort + убывание | 200,000 | 266ms | 1мс |
| д = опись: ала и сортировки = сумма (geo_x, geo_y) + убывание | 200,000 | 810ms | 1мс |
Приведенный выше тест показывает, что сортировка с использованием функции сортировки намного медленнее, чем порядок сортировки по умолчанию (что и следовало ожидать). Сортировка по значению функции также выполняется медленнее, чем по строковому полю, но разница не так значительна, как в предыдущем случае.
Несколько слов в конце
Конечно, вышеприведенный тест просто просматривает тему эффективности сортировки с использованием функций Solr, однако показывает прямую связь. Учитывая, что в большинстве случаев это не будет метод сортировки по умолчанию, и, давая нам действительно мощный инструмент, мне кажется, что эту функцию стоит запомнить. Это, безусловно, стоит использовать, когда в требованиях говорится, что мы должны сортировать по значению, которое зависит от запроса и значений индекса — как в случае сортировки по расстоянию от точки, указанной пользователем.