|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Суффикс КК = миллион? Правильно ли я понял 1) 10kk == 10_000_000 2) 190k == 190_000 3) 10kk == 10_000_000 4) 186k == 186_000 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:29 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Vyatich Нужно видеть распределение данных, чтобы бить на партиции. Только что-то мне подсказывает, что enti0_.X='XXXXXVAL123' - это бОльшая часть таблицы. нет. это примерно 180к записей из 10м. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:29 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Код: plsql 1.
Сколько возвращает? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:34 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Тоесть вот этот предикат у нас - самый полезный. Код: java 1.
Он - кандидат на ключ партишенинга. Он режет табличку на 1/52 часть и всё остальное туловище. Варианты - списковое партицирования с явным перечислением всех значений? Надо спросить у Андрея сколько уникальных иксов есть? И хеш партицирование с ~50 партишенов. Две из них дадут промах но всяко лучше чем бегать RANGE_SCAN по всей табличке. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:36 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
mayton, Перед партицированием выясняют полезность и эффективность индексирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:40 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Я не знаю теоретической формулы. Поэтому ставлю эксперимент. Его цена все равно будет дешевле чем попытка учесть 100500 параметров сервера... включая случайные влияния соседних сеансов и запросов в этой-же БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:42 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
mayton, Просто партицирование стоит после индексов в очередности. Вот и все. Это как лечить человека. Антибиотики позже водки)) ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:44 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
mayton Суффикс КК = миллион? Правильно ли я понял 1) 10kk == 10_000_000 2) 190k == 190_000 3) 10kk == 10_000_000 4) 186k == 186_000 да, всё верно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:50 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Ты-же видел план. INDEX_RANGE_SCAN по enti0_.X='XXXXXVAL123' не дал достаточно скорости. Но этот индекс выполнил другую полезную работу. Он выдает сразу сортирующий итератор (курсор). И это нельзя забывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:50 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Vyatich Код: plsql 1.
Сколько возвращает? 186k, enti0_.a - это уникальный ключ для каждой записи. считай айдишник (но он тоже есть). почему так - ну вот так вот. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:52 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT почему так - ну вот так вот. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:53 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
PetroNotC Sharp andreykaT почему так - ну вот так вот. давай выражусь корректнее - это строковое поле, которое имеет уникальное значение для каждой записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:56 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT PetroNotC Sharp пропущено... расшифруй) давай выражусь корректнее - это строковое поле, которое имеет уникальное значение для каждой записи. А как быть с ID хибера и rowid оракла? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:58 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT, Внезапно - ОРМ уникальность для объакта обеспечиват через ID записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 18:00 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Забудьте про rowId. Он нужен только для обеспечения работы индексов. И для ремонтно-восстановительных работ когда база повреждена. На него нельзя накручивать бизнес-смыслы. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 18:04 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
Тогда разбей на partitions по enti0_.X и создай локальный, УНИКАЛЬНЫЙ индекс по enti0_.a. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 18:07 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
mayton Тоесть вот этот предикат у нас - самый полезный. Код: java 1.
Он - кандидат на ключ партишенинга. Он режет табличку на 1/52 часть и всё остальное туловище. Варианты - списковое партицирования с явным перечислением всех значений? Надо спросить у Андрея сколько уникальных иксов есть? И хеш партицирование с ~50 партишенов. Две из них дадут промах но всяко лучше чем бегать RANGE_SCAN по всей табличке. 10M записей партиционировать ? имхо таблица крошечная, смысла партиционировать нет. планы с картинки бесполезены, т.к. сняты когда вся таблица явно в буферном кеше, затрат на и/о почти нет, соответственно и elapsed time миллисекунда. нужен план с 30 секундами и нормальная статистика, autotrace вот так показывает Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 18:11 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
mayton, Это кому? Я и не обращаюсь к оракловому. У него два айди что ли? Тогда и будет как есть счас. Бардак в голове и табле ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 18:28 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
H5N1 нужен план с 30 секундами Но ему не доходит. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 18:33 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
H5N1 10M записей партиционировать ? имхо таблица крошечная, смысла партиционировать нет. планы с картинки бесполезены, т.к. сняты когда вся таблица явно в буферном кеше, затрат на и/о почти нет, соответственно и elapsed time миллисекунда. нужен план с 30 секундами и нормальная статистика, autotrace вот так показывает Да. Вот эта ситуация с плавающим откликом показывает что у него полезные блоки выгружаются. И от 2 до 30 секунд - это объясняет. Я-же предлагаю SEQUENTAL_READ по всей таблице заменить на SEQUENTAL_READ по сортируемому полю в рамках 1 партишена который будет в 50 раз меньше. По поводу крошечной таблицы. Мы вычитываем 7М на 10 000 это примерно 700 символов на результирующую строку. Это немало. Возможно оригинальная строка еще шире. В блоке мало строк. А это значит что INDEX_RANGE scan еще менее эффективен. Строки некластеризованы вокруг одного блока. Я кстати в качестве эксперимента предложу Андрейке просто еще раз пересоздать таблицу CTAS по сортированной выборке. Этот чортов фактор кластеризации о котором так любят спрашивать новички... Мдя.... ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 18:42 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
конкретно этому запросу должно помочь Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 19:15 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
mayton По поводу крошечной таблицы. Мы вычитываем 7М на 10 000 это примерно 700 символов на результирующую строку. Это немало. Возможно оригинальная строка еще шире. В блоке мало строк. А это значит что INDEX_RANGE scan еще менее эффективен. Строки некластеризованы вокруг одного блока. В 180к записях у него 15 мб, вся талица значит порядка 833 мб. нужен план при 30 секундах и статистика. если реально andreykaT select count(*) from Entity - занимает до 30 то i/o просто мертвое переодически. партиционирорвать 833 мб ... по мне это звучит странно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 19:21 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
По настоящему крутые ораклисты добиваются того чтобы искомые данные ФИЗИЧЕСКИ лежали близко в процессе выборки. Это или партишенинг или кластеризация. Индексы танцуют только на 7% селективности (как было во времена Oracle 8i) и щас кажется задавили до 3%. И сюда-же до кучи игры с механикой заполнения блока. В идеале выгодно чтоб блок заполнялся на 100%. Но это хуже для updates. Можно подключить также Oracle Compression чтоб унылые повторения строк поджать. Получится gzip внутри блока. Тоже можно попробовать. В дата-аналитике еще дальше пошли. Там решили что не нужно физически хранить строку. А нужно - столбец. Но это - если 500 колонок в таблице и выше. И это таки помогает. Вобщем пробуйте физически консолидировать искомые данные. И так чтоб скорость insert/update упала но не сильно. Можно защелкнуть таблицу в приоритетах чтоб она была выше чем другие (BUFFER_POOL_KEEP) если у Андрейки хватит привилегий. Тогда ее никто не вытеснит из BP. Путей - масса. А вы говорите Хибернейт... ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 19:24 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
H5N1 mayton По поводу крошечной таблицы. Мы вычитываем 7М на 10 000 это примерно 700 символов на результирующую строку. Это немало. Возможно оригинальная строка еще шире. В блоке мало строк. А это значит что INDEX_RANGE scan еще менее эффективен. Строки некластеризованы вокруг одного блока. В 180к записях у него 15 мб, вся талица значит порядка 833 мб. нужен план при 30 секундах и статистика. если реально andreykaT select count(*) from Entity - занимает до 30 то i/o просто мертвое переодически. партиционирорвать 833 мб ... по мне это звучит странно. да. в мониторе на ио уходит 98% ресурса и типа 2% - цпу ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 19:35 |
|
и снова немного архитектуры и эластика с рдбмс
|
|||
---|---|---|---|
#18+
andreykaT да. в мониторе на ио уходит 98% ресурса и типа 2% - цпу а что там за дисковый массив, можно узнать? И сбрасывается ли HWM? В купе с сильной фрагментацией данных это может привести к проблемам. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 20:19 |
|
|
start [/forum/topic.php?fid=59&msg=40014488&tid=2120628]: |
0ms |
get settings: |
26ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
445ms |
get tp. blocked users: |
2ms |
others: | 294ms |
total: | 857ms |
0 / 0 |