собссно вопрос.

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

в общем, ожидания есть одни - эластиксерч под капотом.

я напилил некий ПОЦ на хиберсерче. но хиберсерч работает поверх рдбмс. то есть прилетает пользовательский запрос -
ХС, идет за данными в эластик по индексированным полям, вытряхивает из него скажем 40 айдих (на страницу) и с этими айди прётся в рдбмс, доставая уже оттуда сущности целиком и простым запросом а ля селект туда сюда фром таблица вхере айди ин ()

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

или же эта схема эффективна поверх какой то работающей системы где много связей-джойнов и бохатя жизнью доменная модель а не 2 таблицы три запроса?

опять же, я столкнулся с проблемой, что у них оракл, который тащит мешок бдшек и мешок сервисов которые его насилуют денно и ношно. то есть простой запрос типа "выбери 10к записей и отсортируй" без джойнов без ничего на таблицах в 10-30 млн записей отыгрывается от 2х секунд и до 30-ти секунд. один и тот же запрос на одном и том же наборе. и с этим, я так понимаю, ничего уже не поделать.

выльется ли это в вариант - что оракл начент тормозить за собой весь хс? видимо, да.

Не. Оракл держат бес.п. оракл высокооплачиваемые профи. Посмотрели индексы и сказали все есть оптимизируйте запрос а че там оптимизировать это простейший селект по одному полю и с сортировкой. Тупо тормозит база.

Две секунды - приемлемо. 30 секунд - нет.
Структура данных - плоский документ, 30миллилнов штук. Ну почти плоский. 40 полей. Типы запросов - классика отфильтровать по полю а, б, ц, отсортируй выдай пейдж. Размер Пейджа до 10к записей

Может меняться. Отжирает сортировка судя по плану.

Нельзя. Когда пагинация на стороне бэка

мне все равно что там. оракл это оракл. я зарепортил что примитивный запрос тормозит с фетчем 150к записей (сортировка да) и всё. а они пусть пляшут как хотят. могут сказать мы ничего ен можем не хотим. мне на это НАПЛЕВАТЬ.
но если интересно они предложили профилировать запрос. но запрос строится динамически хибером через критерии поэтому им это снова сложно (там вариантов то по пальцам всё-равно). у меня сложилось впечатление что у всех оракл-дба есть три стандартных отмазки: у тебя запрос тяжелый, проверь индексы, посмотри план.

еще раз. один и тот же запрос с одним и тем же набором данных тормозит РАНДОМНО. то есть. сейчас он работает 2 секунды. через час он 30 секунд берет, хоть 10 раз в ряд его дергай (кэш исключается), через час снова 2 секунды. одна и та же таблица один и тот же набор данных. что там оптимизировать?

но не суть. я спросил про хиберсерч, а мне начинают рассказывать как оракл тюнить...

не совсем понял. емнип там селект бла бла (селект бла бла ордер бай поле) роунам <=размерСтраницы.

я не могу брать то что захочу. я могу брать:
эластиксерч (хс или там чистый клиент),
оракл. готовый. попросить развернуть в нем свою бд. но я так понимаю физически это будет тот же хост (или набор хостов - я вообще без понятия как оно там сделано), где крутится и та бд которая примитивный селект рандомно отдает 3-30 сек.

еще раз. там нет where id in (дофига значений) там есть where fieldName=fieldValue and where status in (value1, value2 всегда только два) order by someOtherField. всё.

они говорят что они профессионалы. я хз. может и джуны.
мне то что? я бы понял там мегазапрос с мешком джойнов и аггрегаций там и т.п. так нет ничего. )
они посмотрели запрос длительностью 30 секунд. это мой запрос (один из). дальше что? их мегатулза сказала смени where not in () на where in () сменил - не помогло. их планзапросник показал убери сортировку - я сказал я не уберу сортировку потому что она мне нужна. они пожали плечами. ну пусть жмут. мне там нечего делать просто потому что совсем нечего. это работа дба. я подозреваю что просто другие сервисы тупо глушат бд и вообще все запросы там тормозят ко всем бд в определенный момент времени.
а да еще предложили вытащить всё в память и в памяти отсортировать. (150к записей в моем случае), ну так себе совет.

и еще раз. это не относится к теме вопроса. тема чуть другая. за тюнингом запросов я в другой топик пошёл бы.

это - таблица. еще раз. в таблице 30м записей. я даю селект в селекте 150к записей, я делаю сортировку, и беру 10к сверху. ну что тут не ясного то?

по весам. запрос без сортировки - 45 попугаев. с сортировкой 11000 попугаев.

и опять же. алё, хиберсерч. вопрос. хиберсерч работает поверх рдбмс, насколько такой подход эффективен? против подхода - а давайте всё будем хранить чисто в индексах эластика?

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

у меня ощущение что я пришел в магазин туалетную бумагу купить а мне советуют заглушку в задницу вставить и предлагают 25 разных моделей этих заглушек на выбор.

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

я погуглил кучу статей и не нашел однозначного ответа насклько ЕС подходит как документное хранилище. а не быстрый лукап айдишек сущностей с которыми ты идешь потом в другое хранилище (это то как работает ХС).

Эвеншуал консистенси вполне себе допускает что в какой то момент времени что то там может быть и не очень готово

никак. но есть мнение что эластик это умеет делать быстрее при некоторых обстоятельствах

Не понял про индекс и как избавиться. Ты про индекс рдбмс говоришь или про индекс эластика?

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

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

можно держать всё в эластике но возможно тебе придется постоянно обновлять те поля, которые и не нужны в поиске вовсе.

ну и перформанс - в случае эластика это только эластик. в случае эластик + рдбмс - оно будет работать настолько быстро насколько быстро работает самый медленный элемент этой схемы.

я не девопс и не дба. понятия не имею почему рдбмс в заднице.
и снова это не тема про оракл и как его улучшить. давай так. мой вариант улучшить производительность там только один - написать грозное письмо и кулачком потрясти.

Мне твое мнение очень важно. Ты не поверишь

Ты ж пойми, там дело может быть вообще в сетевом подключении. И все твои оптимизации имеют мало проку в таком раскладе. Просто потому что дело НЕ в этом.