Если стоит задача полной переиндексации большого по объему данных индекса, то как правильно это сделать?
Не удалять же старый и создавать новый.
Существует несколько способов. Начните с изучения документации и этого блога. Если будут конкретные вопросы - спрашивайте.
так я тему создал с учетом что подскажут лучшее решение а не множество.
Мне главное чтобы простоя между обновлениями не было.
Сейчас протестировал индекс на 50к записей, он заполнялся 25минут.
Лучшее для чего? Лучшее это понятие очень относительное. Оба способа, которые я привел - лучшие только для разных случаев. Если вы можете описать свою ситуацию подробнее, то можно будет порекомендовать что-то конкретнее.
пока приоритет на скорость
Скорость самого процесса индексирования? Каким образом Вы это делаете в данный момент? Где узкое место? CPU? Диск? Или машина не перегружена, но все равно медленно? Сколько машин в кластере и на сколько это все должно быть прозрачно для пользователей?
Пока 1 машина
документы добавляю с помощью прослойки elastica по одному документы и потом делаю обновление индекса.
Скорость мне кажется слишком малой по сравнению с тем же sphinx.
Я же привел пример - 50к записей за 25 минут. Т.к. в эластике еще слабоват, то не знаю нормально это или плохо.
Теперь понятно. Надо начать с того, что переключиться с индексирования по одному документу на bulk и перестать так часто обновлять индекс. Elasticsearch может обрабатывать несколько параллельных запросов bulk одновременно, если ваше приложение это позволяет. Если после этого будет все равно медленно, то надо будет смотреть где медленно и ускорять, но тут уже многое зависит от вашей системы и версии elasticsearch.
Спасибо, попробую пакетную индексацию.
На этапе разработки приходится переделывать индекс. В это время основная работа с переиндексацией, а потом это будет редко делаться..
Пакетная индексация помогла, теперь все происходит за 19с )