Блог

Итак, у нас есть хранилище MySQL, которое является нашим уровнем сохраняемости для наших данных. Для нескольких вариантов использования поиска мы хотим создать индексы Elasticsearch по требованию, запрашивая данные из хранилища MySQL. Мы также настроили политику ILM, которая удаляет эти индексы, скажем, через неделю после создания. По сути, эти индексы являются эфемерными и создаются по запросу всякий раз, когда поступает поисковый запрос, а затем удаляются позже.

Поскольку существует только фиксированный набор данных, которые мне нужно было бы ввести в индекс Elasticsearch, я хочу определить состояние этого индекса, которое указывает на завершенность процесса приема. Это необходимо, потому что пользователю действительно не разрешается выполнять поиск до тех пор, пока не будут собраны все данные — до тех пор, пока индекс не будет полностью загружен всеми необходимыми данными.

Итак, то, что я ищу, — это связать это состояние с какими-то метаданными индекса. Поскольку наша политика ILM диктует, что эти индексы эфемерны, я не хочу использовать внешнюю систему для управления их состоянием. Как правило, мне приходилось бы перемещаться по состояниям «ожидание», «построение» и «завершено / не выполнено», когда я создаю индекс и начинаю прием.

Похоже, что сопоставление _meta — это то, что я могу использовать для этой цели, но я не совсем уверен, что это правильный способ сделать это.

Есть ли какой-то другой, возможно, очевидный способ сделать это? Или, возможно, лучший способ решить эту проблему в целом?

Использование мета-полей в сопоставлении должно работать и обычно используется несколькими фреймворками. Но это зависит от объема и структуры данных / информации, которые необходимо сохранить, и способа, которым вы хотите работать с этими данными.

Если объем метаданных должен быть больше или сложнее, рассмотрите возможность создания метаиндекса, в котором хранятся простые документы о состоянии ваших индексов. Это также будет более эффективно, поскольку изменения индекса, такие как обновления отображения, должны транслироваться в кластере. Наличие такого выделенного индекса метаданных облегчит множество других задач, таких как запрос всех индексов, которые подлежат удалению и т.д. Используя _meta, вы не сможете реализовать что-то вроде управления версиями или поддержки истории. С помощью предлагаемого мета-индекса вы можете хранить один документ на управляемый индекс или по одному на индекс и изменять состояние, если вам нужна какая-то история.

Кстати: компоненты Elasticstack создают множество указателей с префиксом точки, таких как .kibana или .logstash; причина в том, что эти компоненты должны хранить какое-то состояние.

С моей точки зрения, это более универсальное решение, и стоит попробовать.

РЕДАКТИРОВАТЬ обобщение комментариев:

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