Прокрутка против (от + размера) разбиения на страницы по сравнению с search_after в API данных без сохранения состояния c API - PullRequest
Новая
       12

Прокрутка против (от + размера) разбиения на страницы по сравнению с search_after в API данных без сохранения состояния c API

1 голос
/ 08 апреля 2020

У меня есть индекс ES, в котором хранится уникальный ключ и дата последнего обновления для каждого документа. Мне нужно написать APi, который будет использоваться для синхронизации c данных, связанных с этим ключом, либо дельта (на основе сохраненной даты, например, предоставить мне данные, обновленные после 3 марта 2020 г.)

Rough ES mapping : 

{
  "mappings": {
    "userdata": {
      "_all": {
        "enabled": false
      },
      "properties": {

        "userId": {
          "type": "long"
        },
        "userUUID": {
          "type": "keyword"
        },        
        "uniqueKey":{
          "type":"keyword"       
        },
        "updatedTimestamp":{
          "type":"date"       
        }
      }
    }
  }

Я буду использовать этот индекс ES, чтобы найти список таких уникальных ключей, соответствующих фильтру даты, и построить оставшиеся детали для каждого ключа из cassandra.

API без гражданства.

Нет. документов, соответствующих фильтру даты, может составлять от нескольких тысяч до нескольких сотен тысяч. Теперь при синхронизации таких данных клиенту необходимо разбить результаты на страницы.

Для разбивки на страницы я планирую использовать lastSynchedUniqueKey. Для каждого последующего вызова клиент предоставит это значение, и API будет внутренне выполнять запрос диапазона в этом поле и извлекать данные с помощью uniqueKey > lastSynchedUniqueKey

Итак, запрос ES будет иметь следующие компоненты:

  • поисковый запрос: (запрос ярости даты) + (uniqueKey> lastSynchedUniqueKey) + (запрос по имени пользователя)
  • сортировка: по уникальному ключу в виде c order
  • size: 100 -> это максимальный размер страницы (предложить, если он может быть изменен на основе общего количества документов для синхронизации. Единственное беспокойство - не хочу загружать кластер ES с этими запросами. Будут другие индексы в кластер, который используется для поиска, ориентированного на пользователя.)

Каков лучший вариант для разбивки на страницы в этом случае:

  1. нумерация страниц: использование (от + размер ) и фильтровать и сортировать параметры: я знаю, что это не будет работать.

  2. scroll: с тем же фильтром и параметрами сортировки

  3. В документе ES предлагается использовать '_do c' для сортировки по sc роллы. Что не возможно в моем случае. Можно ли вместо этого использовать поле в индексе?

  4. Прокручивается ли быстрее, чем search_after?

Пожалуйста, предоставьте свои данные о сортировке и разбивке на страницы с точки зрения клиента и внутри.

...