Эффективная сортировка и разбиение на страницы с помощью Solr при изменении индекса

Question

Я работаю над структурированным средством просмотра документов, где каждый документ Solr представляет собой «раздел» или «абзац» в большом наборе юридических документов вместе с различными метаданными. У меня есть корпус, который, вероятно, будет представлять 10 ^ 12 или более из этих разделов. Я хочу предоставить пейджинг для пользователей, чтобы они могли просматривать N из этих разделов одновременно в sort_path порядке.

---

Теперь проблема: даже если sort_path проиндексирован, все время добавляются и удаляются документы. Простое решение для сортировки и разбивки на страницы приведет к тому, что пользователи, возможно, будут пропускать разделы или неожиданно переходить по порядку, даже если они находятся рядом с документами, добавляемыми / удаляемыми при оформлении заказа; такое поведение было бы недопустимым.

Пример: я делаю ссылку на следующую страницу на что-то вроде ...sort_order=sort_path+desc&rows=N&start:12345. Затем, пока пользователь просматривает страницу, документ в начале порядка sort_path удаляется. Теперь, когда они получат следующие N строк, они пропустят 1 документ, не зная.

Итак, учитывая, что у меня есть поле sort_path, которое упорядочивает разделы, клиент должен иметь возможность запрашивать N разделов «до» или «после» sort_path:/X/Y/Z, вместо того, чтобы запрашивать rows:N с помощью start:12345. Я понятия не имею, как представить это в запросе Solr.

---

Возможно, я немного отодвинул края Solr, и в конечном итоге может оказаться более целесообразным хранить представления этих «секционных» документов как в Solr (для поиска контента, в котором Solr хорош, так и в RDBMS ( для заказа и индексации). Я надеялся избежать этого, и такого рода запросы все еще будут уродливыми в базе данных, поэтому, возможно, у вас есть какие-то идеи. (Спасибо!)

---

Обновление:

Оказывается, диапазоны solr в сочетании с сортировкой могут дать мне именно то, что мне нужно. На индексированном поле я могу сделать что-то вроде

sort_path:["/A/B/C" TO *]

, чтобы получить «следующие» N разделов, и сделать

sort_path:[* TO "/A/B/C"]

упорядочение по sort_path:desc с последующим обращением возвращенного чанка для получения предыдущих N разделов. Я собираюсь протестировать производительность этого решения, но оно кажется жизнеспособным.

Answer 1

Это на самом деле не специфическая для Solr проблема, а общая проблема с разбиением на страницы любого внешнего источника данных, поскольку источник данных имеет независимое состояние от (веб-приложения).Например, это также происходит в реляционных базах данных. Вот хороший охват нумерации страниц в реляционных базах данных, а также возможные решения.Большинство веб-приложений / веб-сайтов выбирают первое решение: «Повторите запрос для каждого нового запроса», поскольку другие решения намного сложнее и не масштабируются, но это страдает от проблемы, которую вы описываете.Просмотрите вопросы на stackoverflow.com некоторое время, и вы заметите это, поскольку вопросы создаются постоянно.

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

ДругойОпция будет уменьшать вашу скорость фиксации, но это может привести к неидеальной свежести документа.