Например, для динамического маппинга с датами, возьмём дефолтный logstash-*, где * - это дата.
Вот у нас их много, как лучше организовывать работу с ними загнать их все в alias, кстати, там ведь тоже можно использовать * для ссылки на индекс или всё же лучше использовать * прямо в запросе? Как устроены alias изнутри, влияет ли на производительность его использование и на сколько сильно? Или может alias представляет из себя дополнительный индекс и наоборот ускоряет работу?
На примитивном уровне алиасы это просто HashMap в памяти, в которой для каждого алиаса задан список индексов, в который этот алиас должен раскрываться перед выполнением запроса. Так что используйте то, что проще с точки зрения архитектуры вашего приложения. На скорость работы это никакого влияния не окажет (за исключением случая, если у вас сотни тысяч этих алиасов и вы их создаете и уничтожаете каждую секунду, тогда на старых версиях elasticsearch могут быть проблемы).
1 Like
@Igor_Motov, благодарю за ответ! А можно ещё узнать ваше мнение с организацией структуры.
Мне в голову пришёл вот такой паттерн, что когда нужно на продакшен новую версию выкатывать и требуется внести много изменений в маппинг, то приходится заниматься переиндексированием.
А я хочу решить эту проблему через алиасы, то есть имеем названия индексов users, accounts, sessions и т.п., теперь это названия в алиасах ссылками на индексы users_*, где users_v1, users_v2, ...
Каждый индекс имеют свою версию маппинга и свои данные.
Не возникнет ли сложностей с использованием таких алиасов? Учитывая, что маппинг в индексах отличается.
Я не очень понимаю, как это решает проблему переиндескирования. Обычно, потребность переиндексации возникает, когда необходимо выполнять новые запросы, который старый индекс не поддерживал. В вашем случае, вы оставляете старые данные в старом формате, то есть новый запрос с этими данными работать не будет.
1 Like
Не будет использовать совсем или частично? А как поведёт себя эластик если будет в v1 тип поля один, а в v2 другой с одним и тем же именем?
Зависит от запроса и типов полей в старой и новой схеме и версии elasticsearch. Elasticsearch будет пытаться интерпретировать запрос для каждого индекса отдельно и если такая запрос для каждого индекса будет иметь смысл - то такой запрос пройдет, если нет - то зависит от версии elasticsearch.
1 Like
Тогда это как раз решает проблему переиндексации всех документов.
Смотрите, я просто ввожу версионность для индексов, а за обновления данных уже отвечает клиентское приложение, при редактировании в случаи необходимости документ уже сохраняется под актуальный маппинг согласно клиентской модели данных.
Но при этом мы имеем возможность работы с документами из старого маппинга - поиск, просмотр, редактирование. Причём опять же клиентское приложение поддерживает версию индексов, зная как их отобразить для просмотра и после редактирования сохранить по актуальной модели данных.
Или я что-то не учёл при таком раскладе? 
Все дело - в деталях.
1 Like
Это верно!) Спасибо Игорь за консультацию! Такую структуру уже реализовали в новом проекте, посмотрим как это всё будет работать в продакшене)