Мой эластичный кластер содержит индексы с гигантскими файлами сопоставления.Это связано с тем, что некоторые из моих индексов содержат до 60 тыс. Различных полей.
Чтобы немного рассказать о моей настройке, каждый индекс содержит информацию из одного источника.Каждый источник имеет несколько типов данных (которые я буду называть слоями), которые индексируются как разные типы в индексе, соответствующем источнику.Каждый слой имеет разные атрибуты (в среднем 20).Чтобы избежать конфликта имен полей, они проиндексированы как «LayerId_FieldId».
Я пытаюсь найти способ уменьшить размер моего отображения (насколько я понимаю, это может вызвать проблемы с производительностью).Одним из вариантов является наличие одного индекса на слой (и, возможно, распределение больших слоев по нескольким индексам, каждый из которых отвечает за отдельный временной сегмент).У меня сейчас около 4000 различных слоев, поэтому давайте скажем, что в этом методе у меня будет 5000 различных индексов.Эластично ли это хорошо?Что меня должно волновать (если вообще) с таким большим количеством индексов, некоторые из которых очень малы (некоторые слои имеют всего 100 элементов)?
Вторым возможным решением является следующее,Вместо сохранения данных слоя в том виде, в котором они мне отправлены, например:
"LayerX_name" : "John Doe",
"LayerX_age" : 34,
"LayerX_isAdult" : true,
, они будут сохранены как:
"value1_string" : "John Doe",
"value2_number" : 34,
"value3_boolean" : true,
В последнем варианте у меня будетсохранить некоторый индекс метаданных, который связывает родовые имена с реальными именами полей.В приведенном выше примере мне нужно знать, что для слоя X поле «value1_string» соответствует «name».Таким образом, всякий раз, когда я получаю новый документ для индексации, мне приходится запрашивать метаданные, чтобы узнать, как сопоставить данные поля моим общим именам.Это позволяет мне отображать постоянный размер (скажем, 50 полей для каждого типа значения, то есть всего несколько сотен полей).Однако это вносит некоторые накладные расходы, но самое главное, я чувствую, что это в основном сводит мою базу данных к реляционной, и я теряю способность обрабатывать документы произвольной структуры.
Некоторые технические подробности о моем кластере:
Elasticsearch версия 2.3.5
22 узла, 3 из которых являются мастерами, каждый узел содержит 16 ГБ оперативной памяти, 2 ТБ дискового хранилища.В общей сложности у меня в настоящее время есть 6 ТБ данных, распределенных по 1,2 миллиардам документов, 55 индексам и 1500 осколкам.
Буду признателен за ваш вклад в два предложенных мной решения или любые другие альтернативы, которые у вас есть.в уме!