много данных, терабайты и мы пишем в условно один индекс для которого происходит постоянно rollover и уходит в warm и cold tiers.
Но когда мы ищем по всему индексу но по датам то еластик все равно будет бежать по всему индексу и хоть там данные и дефрагментированы (forcemerge) но так как там обычные диски то поиск все равно медленно.
Я вот думаю как организовать индексы и возможно добавить алиасы по типу - aliasFrom2022 aliasFrom2023 или даже aliasFrom202201 aliasFrom202202 чтобы когда ищем с датой то еластик не все индексы шерстил.
Может есть еще какие-то подходы как улучшить быстродействие запросов в части чтобы не по всем индексам искал еластик?
Руководство говорит, что шарды не должны превышать размера 10гб. Если индекс спроектирован правильно, то должно работать хорошо. Где-то видел еще цифру 40 ГБ на шард. Также следует использовать по возможности nvme накопители. И использовать raid0
Мы в GCP , в документации рекомендовано 25-50 на шарду… не подскажете где про 10 есть инфо?
Сейчас не могу ссылку кинуть, в закрытом контуре нахожусь. Есть на официальном сайте в руководстве, в разделе, если память не подводит how to.
На официальном сайте тоже до 50
Странно. Я там читал пару месяцев назад 10. Может чего поменялось. Вечером сам гляну.
Ок. Спасибо, видимо раньше было по-другому.
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-multiple-indices.html можно явно указать по каким индексам искать.
та их много будет... алиасы прийдется делать
wildcard *-ами подхватывайте пачки индексов.
Elasticsearch is quite efficient when it comes to filtering out shards that do not have any data within a time range Вы уверены что это та проблема которую Вы ищите? Там на древних версиях действительно вопросы были и баги по этому поводу, конечно, но...
Соу тру. Ну хоть какие-нибудь безобидные реакции включите то. Как тут тусить то можно без реакций то?
Боты влетают и на миллионы сообщений реакции ставят
Обсуждают сегодня