Разница между Solr Cursor и ElasticSearch Scroll

При поиске разбиения на страницы с помощью Solr и ElasticSearch оказалось, что обе имеют одну и ту же "проблему" (глубокая разбивка на страницы, особенно с осколками). Хотя обе поисковые системы предоставляют решение/обходное решение для этого:

• Solr: cursor https://cwiki.apache.org/confluence/display/solr/Pagination+of+Results

• ElasticSearch: scroll http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-scroll.html#scroll-search-context
  
  

Теперь я прочитал эти страницы и обыскал интернет, но в некоторых случаях я все еще немного невежественен:

• cursor/scroll тайм-ауты (сбор мусора):

  • Документация Solr, похоже, не дает возможности установить тайм-аут (или какой-либо специальный запрос для аннулирования токена cursor). Это в основном просто вопрос о возможных утечках памяти и т.д.
  • ElasticSearch предоставляет тайм-аут через scroll=1m.
    
    

• обратная разбивка на страницы:

  • Solr предоставит токен cursor для каждого запроса, поэтому можно получить доступ к любой предыдущей странице.
  • ElasticSearch, похоже, всегда использует один и тот же токен scroll. Поэтому я не могу вернуться назад, не выполняя новый поиск?
    
    

• Изменить поисковый запрос:

  • ElasticSearch явно требует использования специального URL-адреса для scroll запросов (http://localhost:9200/_search/scroll?scroll=1m?scroll_id=...). Таким образом, нет возможности изменить поисковый запрос.
  • Solr добавляет токен cursor к обычным запросам. Означает ли это, что я могу использовать токен cursor и изменять запрос (фильтры, порядок, размер страницы и т.д.)?
    
    

• Индекс меняется при использовании scroll/cursor:

  • Документация Solr говорит, что если значение сортировки документа 1 изменилось так, что оно находится после позиции курсора, документ возвращается клиенту дважды. Это ясно для меня. Но теперь есть еще два вопроса, которые не покрываются:

    • Что произойдет, если я использую токен cursor для страницы 2 (где документ 1 был до изменения значения сортировки)? Я увижу старые элементы (включая документ 1) или увижу новую созданную страницу со свежевыпущенными документами?
    • В основном тот же вопрос, что и раньше: документация Solr говорит: значение сортировки документа 17 изменилось так, что оно находится до позиции курсора, документ был "пропущен" и не будет возвращен клиенту, когда курсор продолжит прогресс. Если я использую старый токен cursor, смогу ли я получить документ 17? Или он ушел навсегда при использовании текущей последовательности токенов cursor?
      
      

  • Документация ElasticSearch ничего не говорит о том, что произойдет, если индекс изменится при использовании scroll. Я мог представить, что он ведет себя так же, как Solr, потому что оба используют Lucene для этой функциональности. Но Я совершенно не уверен, потому что нет информации об этом сценарии.

• Как это может быть быстрее простого size=10&from=10/rows=5&start=0?
  Более любопытный технический вопрос, просто потому, что я хотел бы понять, что происходит под капотом.

  • Мне просто интересно, как (особенно) Solr может сделать это cursor более эффективным, чем обычное разбиение на страницы, используя start и rows. Причина: (как сказано выше) Если документ изменяется, он будет получать reindex и может быть помещен после/перед текущим cursor. Это звучит для меня, как будто он должен переупорядочить все документы. И это в основном то же самое, что и разбивка по страницам по умолчанию!?

EDIT:

• Документация ElasticSearch говорит: "Прокрученный поиск моментально отображает моментальный снимок - он не видит изменений, внесенных в индекс после того, как был сделан первоначальный запрос на поиск. Он делает это, сохраняя старый файлы данных, чтобы он мог сохранить свое" представление "относительно того, как выглядел индекс в момент его начала". Итак, есть еще вопрос: как Solr справляется с этим?

---

Было бы здорово, если бы кто-нибудь мог дать мне некоторое объяснение, как все работает.

Спасибо заранее! :)