Я спрашиваю, потому что наш поиск находится в состоянии изменения, поскольку мы работаем над этим, но каждый раз, когда мы вносим изменения в индекс (изменяем токенизатор или фильтр или количество черепов/реплик), мы должны сдуть весь индекс и повторно проиндексировать все наши модели Rails обратно в Elasticsearch... это означает, что нам приходится учитывать время простоя, чтобы переиндексировать все наши записи.
Есть ли более разумный способ сделать это, о котором я не знаю?
Я думаю, что @karmi делает все правильно. Однако позвольте мне объяснить это немного проще. Мне пришлось иногда обновлять производственную схему с помощью некоторых новых свойств или параметров анализа. Недавно я начал использовать описанный ниже сценарий, чтобы выполнять миграцию индекса постоянной, постоянной нагрузки и нулевого простоя. Вы можете сделать это удаленно.
Вот шаги:
real1 и псевдонимы real_write, real_read, указывающие на него,real_write и читает только из real_read,_source доступно свойство документа.Создайте индекс real2 с новым сопоставлением и настройками по вашему выбору.
Использование следующих псевдонимов для переадресации запросов запроса.
curl -XPOST 'http://esserver:9200/_aliases' -d '
{
"actions" : [
{ "remove" : { "index" : "real1", "alias" : "real_write" } },
{ "add" : { "index" : "real2", "alias" : "real_write" } }
]
}'
Это атомная операция. С этого времени real2 заполняется новыми клиентскими данными на всех узлах. Читатели по-прежнему используют старый real1 через real_read. Это конечная последовательность.
Данные должны быть перенесены с real1 на real2, однако новые документы в real2 не могут быть перезаписаны старыми записями. Миграция script должна использовать bulk API с операцией create (не index или update). Я использую простой Ruby script es-reindex, который имеет хороший E.T.A. Статус:
$ ruby es-reindex.rb http://esserver:9200/real1 http://esserver:9200/real2
ОБНОВЛЕНИЕ 2017 Вместо использования script вы можете рассмотреть новый Reindex API. В нем много интересных функций, таких как отчеты о конфликтах и т.д.
Теперь real2 обновляется, и клиенты пишут ему, однако они все еще читают от real1. Пусть обновляется псевдоним читателя:
curl -XPOST 'http://esserver:9200/_aliases' -d '
{
"actions" : [
{ "remove" : { "index" : "real1", "alias" : "real_read" } },
{ "add" : { "index" : "real2", "alias" : "real_read" } }
]
}'
Записывает и читает переход на real2. Вы можете архивировать и удалять индекс real1 из кластера ES.
Готово!
Да, есть более разумные способы переиндексации ваших данных без простоя.
Во-первых, никогда, никогда не используйте "окончательное" имя индекса в качестве вашего реального имени индекса. Итак, если вы хотите называть свои "статьи" вашего индекса, не используйте это имя в качестве физического индекса, но создайте индекс, такой как "articles-2012-12-12" или "articles-A", "articles -1" и т.д.
Во-вторых, создайте псевдоним "alias", указывающий на этот индекс. Затем ваше приложение будет использовать этот псевдоним, поэтому вам не придется вручную изменять имя индекса, перезапускать приложение и т.д.
В-третьих, когда вам нужно или нужно переиндексировать данные, переиндексируйте их в другой индекс, скажем, "articles-B" - все инструменты в инструментах для индексирования Tire поддерживают вас здесь.
Когда вы закончите, укажите псевдоним на новый индекс. Таким образом, вы не только минимизируете время простоя (его нет), у вас также есть безопасный снимок: если вы каким-то образом испортили индексирование в новый индекс, вы можете просто вернуться к старой, пока не решите проблема.
Написал сообщение в блоге о том, как я недавно обрабатывал переиндексацию без простоя. Занимает некоторое время, чтобы выяснить все мелочи, которые должны быть на месте, чтобы сделать это. Надеюсь, это поможет!
https://summera.github.io/infrastructure/2016/07/04/reindexing-elasticsearch.html
Подводя итог:
Создайте новый индекс с новым сопоставлением. Это может быть в одном экземпляре Elasticsearch или в новом экземпляре.
Пока вы переиндексируете, вы хотите обновить свои новые и старые индексы. Для операции записи это можно сделать, отправив операцию записи в фоновый рабочий как для нового, так и для старого индекса.
Удаления немного сложнее, потому что есть условие гонки между удалением и переиндексацией записи в новый индекс. Таким образом, вам нужно будет отслеживать записи, которые необходимо удалить во время вашего переиндекса, и обработать их, когда вы закончите. Если вы не выполняете много удалений, другим способом было бы исключить возможность удаления во время вашего reindex.
Вы хотите использовать прокрученный поиск для чтения данных и bulk API для вставки. Поскольку после шага 2 вы будете записывать новые и обновленные документы в новый индекс в фоновом режиме, вы хотите, чтобы вы не обновляли существующие документы в новом индексе с помощью запросов массового API-интерфейса.
Это означает, что операция, которую вы хотите использовать для массовых запросов API, создается, а не индексируется. Из документации: "create будет терпеть неудачу, если документ с тем же индексом и типом уже существует, тогда как индекс будет добавлять или заменять документ по мере необходимости", Главное здесь - вы не хотите, чтобы старые данные из прокрученного поискового снимка перезаписывали новые данные в новом индексе.
В github есть отличный script, чтобы помочь вам в этом процессе: es-reindex.
Как только вы закончите переиндексацию, пришло время переключить поиск на новый индекс. Вы захотите снова включить удаление или обработать заданные задачи удаления для нового индекса. Вы можете заметить, что поиск нового индекса сначала немного медленный. Это объясняется тем, что Elasticsearch и JVM нуждаются во времени для разогрева.
Выполните необходимые изменения кода, чтобы ваше приложение начало поиск нового индекса. Вы можете продолжить запись в старый индекс, если у вас возникнут проблемы и вам нужно откат. Если вы считаете, что это не нужно, вы можете прекратить писать на него.
На этом этапе вы должны полностью перейти к новому индексу. Если все идет хорошо, выполните любую необходимую очистку, например:
Может быть, создать другой индекс и переиндексировать все данные на него, а затем сделать переключатель, когда он будет повторно индексироваться?