|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
собссно вопрос. есть приложение, оно выполняет одну единственную роль - обрабатывать запросы клиентов и возвращать данные. предварительно их откуда то собрав. в общем, ожидания есть одни - эластиксерч под капотом. я напилил некий ПОЦ на хиберсерче. но хиберсерч работает поверх рдбмс. то есть прилетает пользовательский запрос - ХС, идет за данными в эластик по индексированным полям, вытряхивает из него скажем 40 айдих (на страницу) и с этими айди прётся в рдбмс, доставая уже оттуда сущности целиком и простым запросом а ля селект туда сюда фром таблица вхере айди ин () собссно вопрос - насколько эта схема рациональна? почему бы не держать вообще ВСЕ поля в индексе как док целиком? может стоит сразу написать на чистом ес апи клиенте? но у хса много приятных плюшек из коробки которые придется пилить руками. или же эта схема эффективна поверх какой то работающей системы где много связей-джойнов и бохатя жизнью доменная модель а не 2 таблицы три запроса? опять же, я столкнулся с проблемой, что у них оракл, который тащит мешок бдшек и мешок сервисов которые его насилуют денно и ношно. то есть простой запрос типа "выбери 10к записей и отсортируй" без джойнов без ничего на таблицах в 10-30 млн записей отыгрывается от 2х секунд и до 30-ти секунд. один и тот же запрос на одном и том же наборе. и с этим, я так понимаю, ничего уже не поделать. выльется ли это в вариант - что оракл начент тормозить за собой весь хс? видимо, да. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 15:56 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Порадовал термин "ПОЦ". А какой отклик вообще нужен? Будем ли мы бороться за 200 милисекунд? И какое время среднее? 2 или 30 сек? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 16:54 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT, авторвытряхивает из него скажем 40 айдих (на страницу) авторто есть простой запрос типа "выбери 10к записей и отсортируй" Хотелки как то не стыкуются. PS: разобраться с производительностью Оракла, не? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 17:08 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Не. Оракл держат бес.п. оракл высокооплачиваемые профи. Посмотрели индексы и сказали все есть оптимизируйте запрос а че там оптимизировать это простейший селект по одному полю и с сортировкой. Тупо тормозит база. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 17:10 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
mayton Порадовал термин "ПОЦ". А какой отклик вообще нужен? Будем ли мы бороться за 200 милисекунд? И какое время среднее? 2 или 30 сек? Две секунды - приемлемо. 30 секунд - нет. Структура данных - плоский документ, 30миллилнов штук. Ну почти плоский. 40 полей. Типы запросов - классика отфильтровать по полю а, б, ц, отсортируй выдай пейдж. Размер Пейджа до 10к записей ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 17:12 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT, Железа Ораклу хватает? Какая часть тормозит, отбор по полю или сортировка? Набор полей для сортировки меняется или все время один и тот же? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 17:22 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Может меняться. Отжирает сортировка судя по плану. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 17:48 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT mayton Порадовал термин "ПОЦ". А какой отклик вообще нужен? Будем ли мы бороться за 200 милисекунд? И какое время среднее? 2 или 30 сек? Две секунды - приемлемо. 30 секунд - нет. Структура данных - плоский документ, 30миллилнов штук. Ну почти плоский. 40 полей. Типы запросов - классика отфильтровать по полю а, б, ц, отсортируй выдай пейдж. Размер Пейджа до 10к записей ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 17:57 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT, Странно, сортировка отобранного набора в 10 тысяч строк занимает 30 секунд? "вхере айди ин ()" - в ин десять тысяч айдишников, они туда влезли?)) Рекомендации какие нибудь ораклисты дали? PS: в случае крайней жо можно отсортировать у себя забрав несортированные записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 18:05 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT, Полагаю тебя тоже отнасилуют в топике оракла за эти слова автороракл, который тащит мешок бдшек и мешок сервисов которые его насилуют денно и ношно. то есть простой запрос типа "выбери 10к записей и отсортируй" без джойнов без ничего на таблицах в 10-30 млн записей отыгрывается от 2х секунд и до 30-ти секунд. один и тот же запрос на одном и том же наборе. и с этим, я так понимаю, ничего уже не поделать. Давай немножко попрофессиональнее будем. Сядь перкд ораклом не в выходные и дай нам все факты - запрос, результат, время, план запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 18:15 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
graycode andreykaT, Странно, сортировка отобранного набора в 10 тысяч строк занимает 30 секунд? "вхере айди ин ()" - в ин десять тысяч айдишников, они туда влезли?)) Рекомендации какие нибудь ораклисты дали? PS: в случае крайней жо можно отсортировать у себя забрав несортированные записи. Нельзя. Когда пагинация на стороне бэка ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 19:22 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT graycode andreykaT, Странно, сортировка отобранного набора в 10 тысяч строк занимает 30 секунд? "вхере айди ин ()" - в ин десять тысяч айдишников, они туда влезли?)) Рекомендации какие нибудь ораклисты дали? PS: в случае крайней жо можно отсортировать у себя забрав несортированные записи. Нельзя. Когда пагинация на стороне бэка Вторым постом mayton тебе сказал ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 19:29 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT, классика жанра джун девелопер * девопс, который про оракл слышали но не работали, но поадминить могут. если нет нормальной ide в sqlplus выполнить SET AUTOTRACE ON, нужны план и статистики запроса. надо понять сколько блоков вытягивает с диска, сколько из кеша, в памяти ли сортирует. если реально тормозят сортировки то очень может быть память зажали и сортирует на диске, тюнить sort_area_size надо. за одно, раз табличка мелкая, может можно alter table cache сделать. если одни и те же запросы то тормозят, то нет, скорее всего таблица/индексы из кеша быстро вытесняются. еще вариант, что оракловые базы сидят на черезчур умном сторидже, активно используемые блоки сторидж переносит на SSD, менее активные на HDD. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 20:42 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
еще неплохо узнать fetchSize для statement и какой запрос используется? надеюсь не where (?,...,?)? (получится что оракл очень часто парсит новый запрос) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 21:05 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
H5N1 andreykaT, классика жанра джун девелопер * девопс, который про оракл слышали но не работали, но поадминить могут. если нет нормальной ide в sqlplus выполнить SET AUTOTRACE ON, нужны план и статистики запроса. надо понять сколько блоков вытягивает с диска, сколько из кеша, в памяти ли сортирует. если реально тормозят сортировки то очень может быть память зажали и сортирует на диске, тюнить sort_area_size надо. за одно, раз табличка мелкая, может можно alter table cache сделать. если одни и те же запросы то тормозят, то нет, скорее всего таблица/индексы из кеша быстро вытесняются. еще вариант, что оракловые базы сидят на черезчур умном сторидже, активно используемые блоки сторидж переносит на SSD, менее активные на HDD. мне все равно что там. оракл это оракл. я зарепортил что примитивный запрос тормозит с фетчем 150к записей (сортировка да) и всё. а они пусть пляшут как хотят. могут сказать мы ничего ен можем не хотим. мне на это НАПЛЕВАТЬ. но если интересно они предложили профилировать запрос. но запрос строится динамически хибером через критерии поэтому им это снова сложно (там вариантов то по пальцам всё-равно). у меня сложилось впечатление что у всех оракл-дба есть три стандартных отмазки: у тебя запрос тяжелый, проверь индексы, посмотри план. еще раз. один и тот же запрос с одним и тем же набором данных тормозит РАНДОМНО. то есть. сейчас он работает 2 секунды. через час он 30 секунд берет, хоть 10 раз в ряд его дергай (кэш исключается), через час снова 2 секунды. одна и та же таблица один и тот же набор данных. что там оптимизировать? но не суть. я спросил про хиберсерч, а мне начинают рассказывать как оракл тюнить... ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 21:27 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
pavel_nv еще неплохо узнать fetchSize для statement и какой запрос используется? надеюсь не where (?,...,?)? (получится что оракл очень часто парсит новый запрос) не совсем понял. емнип там селект бла бла (селект бла бла ордер бай поле) роунам <=размерСтраницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 21:29 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
1. fetchSize - какими батчами драйвер забирает из оракла данные сетевыми запросами. Обычно по дефолту ставят не очень большое значение. Если выгребается действительно много записей - это может быть ботлнеком, и увеличение может дать прирост скорости на порядок. 2. по поводу preparedStatement - оракл имеет у себя кэш preparedStatement, и пулять в него разными запросами (разное кол-во параметров) типа SELECT * FROM T WHERE ID IN (?,?,...,?,?) не лучший вариант. Если брать тот же postgres - он менее чувствителен к этому, и то в нем разумнее оперировать массивами SELECT * FROM T WHERE ID=ANY(?), что может быть в разы быстрее из-за единого скана индекса. В oracle тоже можно сделать подобную штуку через самописную структуру типа TABLE OF NUMBER. Но думаю хибер плохо с этим дружит. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 21:41 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
я не могу брать то что захочу. я могу брать: эластиксерч (хс или там чистый клиент), оракл. готовый. попросить развернуть в нем свою бд. но я так понимаю физически это будет тот же хост (или набор хостов - я вообще без понятия как оно там сделано), где крутится и та бд которая примитивный селект рандомно отдает 3-30 сек. еще раз. там нет where id in (дофига значений) там есть where fieldName=fieldValue and where status in (value1, value2 всегда только два) order by someOtherField. всё. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 21:56 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT но если интересно они предложили профилировать запрос. но запрос строится динамически хибером через критерии поэтому им это снова сложно (там вариантов то по пальцам всё-равно). у меня сложилось впечатление что у всех оракл-дба есть три стандартных отмазки: у тебя запрос тяжелый, проверь индексы, посмотри план. не похожи ваши девопс на дба. дба смотрит план и статистики. без них что-то сказать не реально. andreykaT еще раз. один и тот же запрос с одним и тем же набором данных тормозит РАНДОМНО. то есть. сейчас он работает 2 секунды. через час он 30 секунд берет, хоть 10 раз в ряд его дергай (кэш исключается), через час снова 2 секунды. одна и та же таблица один и тот же набор данных. что там оптимизировать? джуна, который имеет все возможности посмотреть что не так, но вместо этого гадает. может ты просто порнуху качаешь в неудачное время. попроси девопсов посмотреть статистику запроса, в оракловой админке (dbconsole) веб интерфейс, рассчитан совсем на домохохяйку. посмотреть запросы длительностью 30+ секунд займет 3 клика и 10 секунд. да там алерты уже должны про такие запросы быть, с инструкциями как исправить. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 22:00 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT могут сказать мы ничего ен можем не хотим. мне на это НАПЛЕВАТЬ. они тут причем? Тебе самому наплевать. andreykaT у меня сложилось впечатление что у всех оракл-дба есть три стандартных отмазки: у тебя запрос тяжелый, проверь индексы, посмотри план. дак где тема на ветке дба? andreykaT но не суть. я спросил про хиберсерч, а мне начинают рассказывать как оракл тюнить... балабол ты. Простейший вопрос - "сейчас он работает 2 секунды. через час он 30 секунд" ты хочешь решить не вникая в оракл. Уже было - "каждому микросервису по бд")) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 22:04 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
H5N1 andreykaT но если интересно они предложили профилировать запрос. но запрос строится динамически хибером через критерии поэтому им это снова сложно (там вариантов то по пальцам всё-равно). у меня сложилось впечатление что у всех оракл-дба есть три стандартных отмазки: у тебя запрос тяжелый, проверь индексы, посмотри план. не похожи ваши девопс на дба. дба смотрит план и статистики. без них что-то сказать не реально. andreykaT еще раз. один и тот же запрос с одним и тем же набором данных тормозит РАНДОМНО. то есть. сейчас он работает 2 секунды. через час он 30 секунд берет, хоть 10 раз в ряд его дергай (кэш исключается), через час снова 2 секунды. одна и та же таблица один и тот же набор данных. что там оптимизировать? джуна, который имеет все возможности посмотреть что не так, но вместо этого гадает. может ты просто порнуху качаешь в неудачное время. попроси девопсов посмотреть статистику запроса, в оракловой админке (dbconsole) веб интерфейс, рассчитан совсем на домохохяйку. посмотреть запросы длительностью 30+ секунд займет 3 клика и 10 секунд. да там алерты уже должны про такие запросы быть, с инструкциями как исправить. они говорят что они профессионалы. я хз. может и джуны. мне то что? я бы понял там мегазапрос с мешком джойнов и аггрегаций там и т.п. так нет ничего. ) они посмотрели запрос длительностью 30 секунд. это мой запрос (один из). дальше что? их мегатулза сказала смени where not in () на where in () сменил - не помогло. их планзапросник показал убери сортировку - я сказал я не уберу сортировку потому что она мне нужна. они пожали плечами. ну пусть жмут. мне там нечего делать просто потому что совсем нечего. это работа дба. я подозреваю что просто другие сервисы тупо глушат бд и вообще все запросы там тормозят ко всем бд в определенный момент времени. а да еще предложили вытащить всё в память и в памяти отсортировать. (150к записей в моем случае), ну так себе совет. и еще раз. это не относится к теме вопроса. тема чуть другая. за тюнингом запросов я в другой топик пошёл бы. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 22:13 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Показания все более запутанные, началось с 40 айдишников, потом стало 10к записей, теперь уже 150к)) далее окажется что этот запрос с разными полями сортировки дергает одновременно тысяча пользователей, правда зачем тысяче пользователе 150к записей, даже одному то не понятно зачем такой объем да еще и с пагинацией... )) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 22:13 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Топик зело неясен. И ораторы не привносят ни капли ясности. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 22:17 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT мне там нечего делать просто потому что совсем нечего. это работа дба. Проектирование системы и реализация функционала это работа разработчика, если разработчик не в состоянии выделить узкие места и сбалансировать нагрузку, значит он фиговый разработчик. andreykaT я подозреваю что просто другие сервисы тупо глушат бд и вообще все запросы там тормозят ко всем бд в определенный момент времени. Если тормозит все, то это вопрос ДБА, правда результат может быть для разработчика неутешительный, т.е. ДБА выявит код который сильнее всего грузит систему и предложит разработчикам его переделать ... andreykaT а да еще предложили вытащить всё в память и в памяти отсортировать. (150к записей в моем случае), ну так себе совет. Почему? На каждый твой запрос это происходит в памяти сервера с Ораклом, почему бы этому не происходить в памяти сервера на котором крутится сервис бэкенда? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 22:30 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
H5N1 надо понять сколько блоков вытягивает с диска, сколько из кеша, в памяти ли сортирует. если реально тормозят сортировки то очень может быть память зажали и сортирует на диске, тюнить sort_area_size надо. за одно, раз табличка мелкая, может можно alter table cache сделать. если одни и те же запросы то тормозят, то нет, скорее всего таблица/индексы из кеша быстро вытесняются Судя по сортировкам 150к записей на каждый пейдж, да еще и разные поля в сортировке в запросах, да еще разработчик там такой не один, похоже все перечисленное сразу имеет место быть)) Как вариант всю таблицу (30 миллионов записей) в кеш, процессоров добавить двойной запас, памяти под сортировку отсыпать чтобы хватало с запасом ... ну и конечно не забыть вычесть затраты на оборудование и лицензии с зарплаты разрабов ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 22:41 |
|
|
start [/forum/topic.php?fid=59&msg=40013813&tid=2120628]: |
0ms |
get settings: |
21ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
11ms |
get forum data: |
4ms |
get page messages: |
469ms |
get tp. blocked users: |
1ms |
others: | 301ms |
total: | 889ms |
0 / 0 |