Elasticsearch 5 — Подход к проектированию для многих небольших, но очень разных индексов?

#elasticsearch-5

#elasticsearch-5

Вопрос:

С удалением ‘type’ в mapping из версии 5.x мне нужно создать много индексов. У всех индексов есть документы, которые не имеют большого сходства.

Например,

Форма приложения -1 поле — Поле A (String) — Поле B (int) — Поле C (Date)

Форма приложения — 2 поля — X (int) Поле — Y (int) Поле — Z (длинное)

На одного клиента приходится до 50 приложений. Он может масштабироваться до 500 пользователей. Итак, выбранный подход к проектированию может иметь 500 X 50 = 25000 индексов. Однако размер памяти каждого индекса / приложения может быть очень маленьким (т. Е. от килобайт до пары мегабайт максимум)

Я прочитал форум, и в основном предлагалось хранить плотные данные в минимальном количестве индексов. Но в моем случае существует множество моделей без перекрывающихся полей. Итак, я вижу один вариант, который является индексом для каждой модели (т. Е. Форма приложения в моем случае использования)

Мой вопрос: хороший ли это подход к проектированию с учетом варианта использования? или лучшие альтернативы?

Ответ №1:

Есть одно решение, позволяющее по-прежнему сохранять поддельные типы, и команда Elastic рекомендует использовать его, если количество документов на сегмент будет очень маленьким.

 {
  "application1": {
    "a": "string",
    "b": "number",
    "c": "date"
  },
  "application2": {
    "x": "number",
    "y": "number",
    "z": "number"
}
  

Так что в этом случае application1 и application2 служат вам в качестве типов.

Комментарии:

1. Но в этом случае у меня будет куча полей в одном индексе. Итак, для 50 приложений может быть по крайней мере 10-15 уникальных полей каждое. Это означает, что примерно в одном документе индекса будет 500-700 полей. Одному экземпляру документа будет присвоено только 10-15 данных, а другой будет просто заполнителем из-за общей схемы / сопоставления. Вам не кажется, что это проблема «раздувания полей»?

2. Это. Это скорее обходной путь для удаления типов. Это не идеально, а скорее еще одно решение, которое может сработать для вас.

3. Другим подходом было бы создать индекс для каждого приложения и использовать идентификатор клиента в качестве ключа маршрутизации.