Доброго времени суток
Есть Elastic Search 5.x
когда делаю запрос через билдер
boolQuery.must(QueryBuilders.matchQuery("fieldA", valueA));
boolQuery.must(QueryBuilders.matchQuery("fieldB", valueB));
boolQuery.must(QueryBuilders.matchQuery("fieldC", valueC));
то все прекрасно fieldA=valueA && fieldB=valueB && fieldC=valueC
а как реализовать fieldA=valueA && fieldA=valueB && fieldA=valueC или аналог fieldA IN(valueA, valueB, valueC)
в разрезе билдера?

Буду благодарен за любые советы, замечания и рекомендации

Увы, сам страдаю такой бедой. Частично проблема решается выставлением хедера X-Opaque-ID со стороны кода. А дальше только соображениями "что могло грузануть". Увы, это не MySQL, где можно посмотреть запросы и сделать эксплейн..

Хуже того — кибану нельзя заставить ставить X-Opaque-ID, так что задача "угадай, что кто-то делает выборку за миллион лет в кибане" решать можно только с помощью хрустального шара..

It depends. В общем случае разумно делать так, чтобы число шардов хорошо на число нод делилось. Т.е. если у тебя, скажем, 6 нод, то 6 шардов по 20 ГБ будет предпочтительней как по-мне

Так а если у меня 60 нод и в ресурсах диска не так сильно ограничен как ограничен рамом и в целом советами ориентироваться кол-ва рама умножать на 20, то есть 610 на одну ноду. И вот хотелось бы в минимальное кол-во шародов уместить как много больше данных

Потому и говорю — зависит от ситуации:) Как по-мне, стоит исходить из того, что большие шарды долго переезжают, плохо обеспечивают равномерность по месту ну и, потенциально, требуют больше оперативки, стоит выбирать что-то умеренно. На практике и на 200ГБ шарды вполне себе у нас имеют место быть. Так что если имеет смысл сделать больше 40ГБ — ничего страшного

А какой размер всего индекса при 200ГБ шардах?

Не помню точно, но полтора ТБ или около того

Понял, спасибо!

Ещё вопрос, а держать большие индексы с 1 шардом и 1 репликей это мувитон? К примеру индекс создаётся с 5 шардами и 0 репликей, rollover’ом через ILM перетекает в ворм при достижении определённого размера, шринкается до 1 шарда и навешивается 1 реплика чтобы сильно не страдало чтение

Поставить nginx перед coordinate node и все запросы проводить через него. И по логам найти виновника

Среди сотен запросов в минуту, ага. Тоже самое что просто сниффер поставить

Если найдёте решение получше, будет здорово, если об этом расскажете. Так как такого рода вопросов много в этом чате

Я по крайней мере нашёл в какой куче его искать - просто вырубал компоненты

Насколько я знаю, один шард - это 1 индекс lucene. Ну а дальше думать, насколько это приемлемо в вашем случае

слоулог

во время затупа в слоулоге буквально всё

оно ж тупит

ну так берите первый