powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Map
Форумы / Java [игнор отключен] [закрыт для гостей] / и снова немного архитектуры и эластика с рдбмс
25 сообщений из 269, страница 1 из 11
и снова немного архитектуры и эластика с рдбмс
    #40013733
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
собссно вопрос.

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

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

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

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

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

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

выльется ли это в вариант - что оракл начент тормозить за собой весь хс? видимо, да.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013744
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Порадовал термин "ПОЦ".

А какой отклик вообще нужен? Будем ли мы бороться за 200 милисекунд? И какое время среднее? 2 или 30 сек?
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013746
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andreykaT,

авторвытряхивает из него скажем 40 айдих (на страницу)
авторто есть простой запрос типа "выбери 10к записей и отсортируй"
Хотелки как то не стыкуются.

PS: разобраться с производительностью Оракла, не?
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013747
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не. Оракл держат бес.п. оракл высокооплачиваемые профи. Посмотрели индексы и сказали все есть оптимизируйте запрос а че там оптимизировать это простейший селект по одному полю и с сортировкой. Тупо тормозит база.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013748
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Порадовал термин "ПОЦ".

А какой отклик вообще нужен? Будем ли мы бороться за 200 милисекунд? И какое время среднее? 2 или 30 сек?

Две секунды - приемлемо. 30 секунд - нет.
Структура данных - плоский документ, 30миллилнов штук. Ну почти плоский. 40 полей. Типы запросов - классика отфильтровать по полю а, б, ц, отсортируй выдай пейдж. Размер Пейджа до 10к записей
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013749
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andreykaT,

Железа Ораклу хватает? Какая часть тормозит, отбор по полю или сортировка? Набор полей для сортировки меняется или все время один и тот же?
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013754
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Может меняться. Отжирает сортировка судя по плану.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013757
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andreykaT
mayton
Порадовал термин "ПОЦ".

А какой отклик вообще нужен? Будем ли мы бороться за 200 милисекунд? И какое время среднее? 2 или 30 сек?

Две секунды - приемлемо. 30 секунд - нет.
Структура данных - плоский документ, 30миллилнов штук. Ну почти плоский. 40 полей. Типы запросов - классика отфильтровать по полю а, б, ц, отсортируй выдай пейдж. Размер Пейджа до 10к записей
кинуть вопрос в ветку оракла стесняешься?
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013760
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andreykaT,

Странно, сортировка отобранного набора в 10 тысяч строк занимает 30 секунд? "вхере айди ин ()" - в ин десять тысяч айдишников, они туда влезли?)) Рекомендации какие нибудь ораклисты дали?

PS: в случае крайней жо можно отсортировать у себя забрав несортированные записи.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013761
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andreykaT,
Полагаю тебя тоже отнасилуют в топике оракла за эти слова
автороракл, который тащит мешок бдшек и мешок сервисов которые его насилуют денно и ношно. то есть простой запрос типа "выбери 10к записей и отсортируй" без джойнов без ничего на таблицах в 10-30 млн записей отыгрывается от 2х секунд и до 30-ти секунд. один и тот же запрос на одном и том же наборе. и с этим, я так понимаю, ничего уже не поделать.
Давай немножко попрофессиональнее будем.
Сядь перкд ораклом не в выходные и дай нам все факты - запрос, результат, время, план запроса.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013768
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
graycode
andreykaT,

Странно, сортировка отобранного набора в 10 тысяч строк занимает 30 секунд? "вхере айди ин ()" - в ин десять тысяч айдишников, они туда влезли?)) Рекомендации какие нибудь ораклисты дали?

PS: в случае крайней жо можно отсортировать у себя забрав несортированные записи.

Нельзя. Когда пагинация на стороне бэка
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013771
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andreykaT
graycode
andreykaT,

Странно, сортировка отобранного набора в 10 тысяч строк занимает 30 секунд? "вхере айди ин ()" - в ин десять тысяч айдишников, они туда влезли?)) Рекомендации какие нибудь ораклисты дали?

PS: в случае крайней жо можно отсортировать у себя забрав несортированные записи.

Нельзя. Когда пагинация на стороне бэка
тогда не гноби сервер пустыми заявлениями почем зря.
Вторым постом mayton тебе сказал
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013781
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andreykaT,

классика жанра джун девелопер * девопс, который про оракл слышали но не работали, но поадминить могут.
если нет нормальной ide в sqlplus выполнить SET AUTOTRACE ON, нужны план и статистики запроса. надо понять сколько блоков вытягивает с диска, сколько из кеша, в памяти ли сортирует.
если реально тормозят сортировки то очень может быть память зажали и сортирует на диске, тюнить sort_area_size надо. за одно, раз табличка мелкая, может можно alter table cache сделать. если одни и те же запросы то тормозят, то нет, скорее всего таблица/индексы из кеша быстро вытесняются. еще вариант, что оракловые базы сидят на черезчур умном сторидже, активно используемые блоки сторидж переносит на SSD, менее активные на HDD.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013787
pavel_nv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
еще неплохо узнать fetchSize для statement
и какой запрос используется? надеюсь не where (?,...,?)? (получится что оракл очень часто парсит новый запрос)
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013794
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
H5N1
andreykaT,

классика жанра джун девелопер * девопс, который про оракл слышали но не работали, но поадминить могут.
если нет нормальной ide в sqlplus выполнить SET AUTOTRACE ON, нужны план и статистики запроса. надо понять сколько блоков вытягивает с диска, сколько из кеша, в памяти ли сортирует.
если реально тормозят сортировки то очень может быть память зажали и сортирует на диске, тюнить sort_area_size надо. за одно, раз табличка мелкая, может можно alter table cache сделать. если одни и те же запросы то тормозят, то нет, скорее всего таблица/индексы из кеша быстро вытесняются. еще вариант, что оракловые базы сидят на черезчур умном сторидже, активно используемые блоки сторидж переносит на SSD, менее активные на HDD.

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

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

но не суть. я спросил про хиберсерч, а мне начинают рассказывать как оракл тюнить...
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013795
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pavel_nv
еще неплохо узнать fetchSize для statement
и какой запрос используется? надеюсь не where (?,...,?)? (получится что оракл очень часто парсит новый запрос)

не совсем понял. емнип там селект бла бла (селект бла бла ордер бай поле) роунам <=размерСтраницы.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013800
pavel_nv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. fetchSize - какими батчами драйвер забирает из оракла данные сетевыми запросами. Обычно по дефолту ставят не очень большое значение. Если выгребается действительно много записей - это может быть ботлнеком, и увеличение может дать прирост скорости на порядок.

2. по поводу preparedStatement - оракл имеет у себя кэш preparedStatement, и пулять в него разными запросами (разное кол-во параметров) типа SELECT * FROM T WHERE ID IN (?,?,...,?,?) не лучший вариант. Если брать тот же postgres - он менее чувствителен к этому, и то в нем разумнее оперировать массивами SELECT * FROM T WHERE ID=ANY(?), что может быть в разы быстрее из-за единого скана индекса. В oracle тоже можно сделать подобную штуку через самописную структуру типа TABLE OF NUMBER. Но думаю хибер плохо с этим дружит.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013803
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я не могу брать то что захочу. я могу брать:
эластиксерч (хс или там чистый клиент),
оракл. готовый. попросить развернуть в нем свою бд. но я так понимаю физически это будет тот же хост (или набор хостов - я вообще без понятия как оно там сделано), где крутится и та бд которая примитивный селект рандомно отдает 3-30 сек.

еще раз. там нет where id in (дофига значений) там есть where fieldName=fieldValue and where status in (value1, value2 всегда только два) order by someOtherField. всё.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013806
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andreykaT

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

не похожи ваши девопс на дба. дба смотрит план и статистики. без них что-то сказать не реально.

andreykaT

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

джуна, который имеет все возможности посмотреть что не так, но вместо этого гадает.
может ты просто порнуху качаешь в неудачное время. попроси девопсов посмотреть статистику запроса, в оракловой админке (dbconsole) веб интерфейс, рассчитан совсем на домохохяйку. посмотреть запросы длительностью 30+ секунд займет 3 клика и 10 секунд. да там алерты уже должны про такие запросы быть, с инструкциями как исправить.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013809
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andreykaT
могут сказать мы ничего ен можем не хотим. мне на это НАПЛЕВАТЬ.

они тут причем? Тебе самому наплевать.
andreykaT
у меня сложилось впечатление что у всех оракл-дба есть три стандартных отмазки: у тебя запрос тяжелый, проверь индексы, посмотри план.

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

балабол ты.
Простейший вопрос - "сейчас он работает 2 секунды. через час он 30 секунд" ты хочешь решить не вникая в оракл.
Уже было - "каждому микросервису по бд"))
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013812
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
H5N1
andreykaT

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

не похожи ваши девопс на дба. дба смотрит план и статистики. без них что-то сказать не реально.

andreykaT

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

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

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

и еще раз. это не относится к теме вопроса. тема чуть другая. за тюнингом запросов я в другой топик пошёл бы.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013813
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Показания все более запутанные, началось с 40 айдишников, потом стало 10к записей, теперь уже 150к)) далее окажется что этот запрос с разными полями сортировки дергает одновременно тысяча пользователей, правда зачем тысяче пользователе 150к записей, даже одному то не понятно зачем такой объем да еще и с пагинацией... ))
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013816
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Топик зело неясен. И ораторы не привносят ни капли ясности.
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013819
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andreykaT
мне там нечего делать просто потому что совсем нечего. это работа дба.

Проектирование системы и реализация функционала это работа разработчика, если разработчик не в состоянии выделить узкие места и сбалансировать нагрузку, значит он фиговый разработчик.

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

Если тормозит все, то это вопрос ДБА, правда результат может быть для разработчика неутешительный, т.е. ДБА выявит код который сильнее всего грузит систему и предложит разработчикам его переделать ...

andreykaT
а да еще предложили вытащить всё в память и в памяти отсортировать. (150к записей в моем случае), ну так себе совет.

Почему? На каждый твой запрос это происходит в памяти сервера с Ораклом, почему бы этому не происходить в памяти сервера на котором крутится сервис бэкенда?
...
Рейтинг: 0 / 0
и снова немного архитектуры и эластика с рдбмс
    #40013825
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
H5N1
надо понять сколько блоков вытягивает с диска, сколько из кеша, в памяти ли сортирует.
если реально тормозят сортировки то очень может быть память зажали и сортирует на диске, тюнить sort_area_size надо. за одно, раз табличка мелкая, может можно alter table cache сделать. если одни и те же запросы то тормозят, то нет, скорее всего таблица/индексы из кеша быстро вытесняются

Судя по сортировкам 150к записей на каждый пейдж, да еще и разные поля в сортировке в запросах, да еще разработчик там такой не один, похоже все перечисленное сразу имеет место быть)) Как вариант всю таблицу (30 миллионов записей) в кеш, процессоров добавить двойной запас, памяти под сортировку отсыпать чтобы хватало с запасом ... ну и конечно не забыть вычесть затраты на оборудование и лицензии с зарплаты разрабов )))
...
Рейтинг: 0 / 0
25 сообщений из 269, страница 1 из 11
Форумы / Java [игнор отключен] [закрыт для гостей] / и снова немного архитектуры и эластика с рдбмс
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]