Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 11   вперед  Ctrl      все
 и снова немного архитектуры и эластика с рдбмс  [new]
andreykaT
Member

Откуда: Finland
Сообщений: 3233
собссно вопрос.

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

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

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

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

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

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

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

Сообщение было отредактировано: 31 окт 20, 15:54
31 окт 20, 15:56    [22224003]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
mayton
Member

Откуда: loopback
Сообщений: 49762
Порадовал термин "ПОЦ".

А какой отклик вообще нужен? Будем ли мы бороться за 200 милисекунд? И какое время среднее? 2 или 30 сек?
31 окт 20, 16:54    [22224028]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
graycode
Member

Откуда:
Сообщений: 461
andreykaT,

автор
вытряхивает из него скажем 40 айдих (на страницу)

автор
то есть простой запрос типа "выбери 10к записей и отсортируй"

Хотелки как то не стыкуются.

PS: разобраться с производительностью Оракла, не?
31 окт 20, 17:08    [22224032]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
andreykaT
Member

Откуда: Finland
Сообщений: 3233
Не. Оракл держат бес.п. оракл высокооплачиваемые профи. Посмотрели индексы и сказали все есть оптимизируйте запрос а че там оптимизировать это простейший селект по одному полю и с сортировкой. Тупо тормозит база.
31 окт 20, 17:10    [22224033]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
andreykaT
Member

Откуда: Finland
Сообщений: 3233
mayton
Порадовал термин "ПОЦ".

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

Две секунды - приемлемо. 30 секунд - нет.
Структура данных - плоский документ, 30миллилнов штук. Ну почти плоский. 40 полей. Типы запросов - классика отфильтровать по полю а, б, ц, отсортируй выдай пейдж. Размер Пейджа до 10к записей
31 окт 20, 17:12    [22224034]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
graycode
Member

Откуда:
Сообщений: 461
andreykaT,

Железа Ораклу хватает? Какая часть тормозит, отбор по полю или сортировка? Набор полей для сортировки меняется или все время один и тот же?
31 окт 20, 17:22    [22224038]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
andreykaT
Member

Откуда: Finland
Сообщений: 3233
Может меняться. Отжирает сортировка судя по плану.
31 окт 20, 17:48    [22224044]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 6525
andreykaT
mayton
Порадовал термин "ПОЦ".

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

Две секунды - приемлемо. 30 секунд - нет.
Структура данных - плоский документ, 30миллилнов штук. Ну почти плоский. 40 полей. Типы запросов - классика отфильтровать по полю а, б, ц, отсортируй выдай пейдж. Размер Пейджа до 10к записей
кинуть вопрос в ветку оракла стесняешься?
31 окт 20, 17:57    [22224047]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
graycode
Member

Откуда:
Сообщений: 461
andreykaT,

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

PS: в случае крайней жо можно отсортировать у себя забрав несортированные записи.
31 окт 20, 18:05    [22224051]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
PetroNotC Sharp
Member

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

Давай немножко попрофессиональнее будем.
Сядь перкд ораклом не в выходные и дай нам все факты - запрос, результат, время, план запроса.
31 окт 20, 18:15    [22224053]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
andreykaT
Member

Откуда: Finland
Сообщений: 3233
graycode
andreykaT,

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

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

Нельзя. Когда пагинация на стороне бэка
31 окт 20, 19:22    [22224071]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 6525
andreykaT
graycode
andreykaT,

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

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

Нельзя. Когда пагинация на стороне бэка
тогда не гноби сервер пустыми заявлениями почем зря.
Вторым постом mayton тебе сказал
31 окт 20, 19:29    [22224075]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 374
andreykaT,

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

Сообщение было отредактировано: 31 окт 20, 20:42
31 окт 20, 20:42    [22224105]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
pavel_nv
Member

Откуда: NV -> SpB
Сообщений: 265
еще неплохо узнать fetchSize для statement
и какой запрос используется? надеюсь не where (?,...,?)? (получится что оракл очень часто парсит новый запрос)
31 окт 20, 21:05    [22224122]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
andreykaT
Member

Откуда: Finland
Сообщений: 3233
H5N1
andreykaT,

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

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

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

но не суть. я спросил про хиберсерч, а мне начинают рассказывать как оракл тюнить...
31 окт 20, 21:27    [22224131]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
andreykaT
Member

Откуда: Finland
Сообщений: 3233
pavel_nv
еще неплохо узнать fetchSize для statement
и какой запрос используется? надеюсь не where (?,...,?)? (получится что оракл очень часто парсит новый запрос)

не совсем понял. емнип там селект бла бла (селект бла бла ордер бай поле) роунам <=размерСтраницы.
31 окт 20, 21:29    [22224132]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
pavel_nv
Member

Откуда: NV -> SpB
Сообщений: 265
1. fetchSize - какими батчами драйвер забирает из оракла данные сетевыми запросами. Обычно по дефолту ставят не очень большое значение. Если выгребается действительно много записей - это может быть ботлнеком, и увеличение может дать прирост скорости на порядок.

2. по поводу preparedStatement - оракл имеет у себя кэш preparedStatement, и пулять в него разными запросами (разное кол-во параметров) типа SELECT * FROM T WHERE ID IN (?,?,...,?,?) не лучший вариант. Если брать тот же postgres - он менее чувствителен к этому, и то в нем разумнее оперировать массивами SELECT * FROM T WHERE ID=ANY(?), что может быть в разы быстрее из-за единого скана индекса. В oracle тоже можно сделать подобную штуку через самописную структуру типа TABLE OF NUMBER. Но думаю хибер плохо с этим дружит.
31 окт 20, 21:41    [22224137]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
andreykaT
Member

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

еще раз. там нет where id in (дофига значений) там есть where fieldName=fieldValue and where status in (value1, value2 всегда только два) order by someOtherField. всё.
31 окт 20, 21:56    [22224142]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 374
andreykaT

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

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

andreykaT

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

джуна, который имеет все возможности посмотреть что не так, но вместо этого гадает.
может ты просто порнуху качаешь в неудачное время. попроси девопсов посмотреть статистику запроса, в оракловой админке (dbconsole) веб интерфейс, рассчитан совсем на домохохяйку. посмотреть запросы длительностью 30+ секунд займет 3 клика и 10 секунд. да там алерты уже должны про такие запросы быть, с инструкциями как исправить.
31 окт 20, 22:00    [22224146]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 6525
andreykaT
могут сказать мы ничего ен можем не хотим. мне на это НАПЛЕВАТЬ.

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

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

балабол ты.
Простейший вопрос - "сейчас он работает 2 секунды. через час он 30 секунд" ты хочешь решить не вникая в оракл.
Уже было - "каждому микросервису по бд"))
31 окт 20, 22:04    [22224149]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
andreykaT
Member

Откуда: Finland
Сообщений: 3233
H5N1
andreykaT

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

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

andreykaT

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

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

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

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

Сообщение было отредактировано: 31 окт 20, 22:10
31 окт 20, 22:13    [22224153]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
graycode
Member

Откуда:
Сообщений: 461
Показания все более запутанные, началось с 40 айдишников, потом стало 10к записей, теперь уже 150к)) далее окажется что этот запрос с разными полями сортировки дергает одновременно тысяча пользователей, правда зачем тысяче пользователе 150к записей, даже одному то не понятно зачем такой объем да еще и с пагинацией... ))
31 окт 20, 22:13    [22224154]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
mayton
Member

Откуда: loopback
Сообщений: 49762
Топик зело неясен. И ораторы не привносят ни капли ясности.
31 окт 20, 22:17    [22224158]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
graycode
Member

Откуда:
Сообщений: 461
andreykaT
мне там нечего делать просто потому что совсем нечего. это работа дба.

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

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

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

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

Почему? На каждый твой запрос это происходит в памяти сервера с Ораклом, почему бы этому не происходить в памяти сервера на котором крутится сервис бэкенда?
31 окт 20, 22:30    [22224162]     Ответить | Цитировать Сообщить модератору
 Re: и снова немного архитектуры и эластика с рдбмс  [new]
graycode
Member

Откуда:
Сообщений: 461
H5N1
надо понять сколько блоков вытягивает с диска, сколько из кеша, в памяти ли сортирует.
если реально тормозят сортировки то очень может быть память зажали и сортирует на диске, тюнить sort_area_size надо. за одно, раз табличка мелкая, может можно alter table cache сделать. если одни и те же запросы то тормозят, то нет, скорее всего таблица/индексы из кеша быстро вытесняются

Судя по сортировкам 150к записей на каждый пейдж, да еще и разные поля в сортировке в запросах, да еще разработчик там такой не один, похоже все перечисленное сразу имеет место быть)) Как вариант всю таблицу (30 миллионов записей) в кеш, процессоров добавить двойной запас, памяти под сортировку отсыпать чтобы хватало с запасом ... ну и конечно не забыть вычесть затраты на оборудование и лицензии с зарплаты разрабов )))
31 окт 20, 22:41    [22224169]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 11   вперед  Ctrl      все
Все форумы / Java Ответить