У меня очень простой вопрос.Elasticsearch время поиска согласованность
У меня есть индекс поиска elasticsearch, содержащий 1600000 относительно больших документов, и мне нужно отсканировать индекс, чтобы синхронизировать его с классической базой данных sql.
Мои документы включают в себя идентификатор и идентификатор времени.
Затем, чтобы синхронизировать sql db и индекс упругости, я просто читаю строки и документы последовательно, как отсортированные по id, так и сравнивая идентификаторы, я могу определить, нужно ли мне удалить документ (сравнение отрицательное), добавьте новый документ со строкой sql (сравнение положительно), а если сравнение 0, сравните метки времени, чтобы узнать, нужно ли мне обновлять документ.
Это работает, но я наблюдаю, что чтение документов становится намного медленнее, поскольку я продвигаю чтение.
я получить свои документы в кусках, повторяя поиск по индексу, сдвигая «от» поля запроса каждый раз, что-то вроде этого:
{
"from" : 0, "size" : 10000,
"fields" : ["idannonce","ts"],
"sort" : ["idannonce"],
"query" : "match_all" {}
}
Этот простой запрос является намного медленнее, когда «из "составляет 1000000, чем когда это 0.
Это нормальное поведение? Я думал, что это должно произойти примерно в то же самое время, когда поле «idannonce» должно быть проиндексировано, нет?
Любые мысли? Есть ли способ написать тот же запрос, чтобы он работал в постоянное время?
Thanks
Я надеялся использовать API прокрутки, но, к сожалению, он не поддерживает сортировку. Используя API поиска, я могу сортировать свои документы по idannonce. Кроме того, я не пропускаю никаких вставок/удалений, поскольку процесс синхронизации выполняется за два прохода. Сначала я делюсь дельта между sql db и эластичным индексом, используя только идентификаторы и временные метки, затем я извлекаю полные данные для дельта из sql и вставляю/обновляю/удаляю свои документы по мере необходимости. Теперь я до сих пор не понимаю, почему мои запросы работают медленнее, когда «от» является высоким. Есть идеи ? –
Прокрутка обычно используется с типом поиска сканирования, который действительно не поддерживает сортировку. Однако вы можете использовать прокрутку и другие типы поиска. Это может быть более эффективным, хотя сначала вытащить все идентификаторы без сортировки, а затем отсортировать их на вашем клиенте. Чтобы ответить на ваш вопрос о замедлении, поиск последующих страниц происходит медленнее, потому что elasticsearh должен выполнять больше работы. Ваш индекс разбит на несколько осколков, верно? Итак, представьте себе, у вас есть 5 отсортированных списков, расположенных на разных узлах, и я хочу, чтобы вы извлекали записи с 999,990 до 1 000 000 из объединенного списка. Как бы вы это сделали? – imotov
Большое спасибо, я не знал, что можно использовать API прокрутки с другими типами поиска, чем сканировать. Я, вероятно, попробую на следующей неделе, пока я переключился на запрос диапазона, я помню последний найденный id и перезапустил поиск с этого идентификатора. Это не слишком медленно, но я надеюсь, что свиток будет быстрее. –