Предлажем да прочитате транскрипт извештаја Владимира Ситникова из раног 2016. „ПостгреСКЛ и ЈДБЦ истискују сав сок“
Добар дан Моје име је Владимир Ситников. Радим за НетЦрацкер 10 година. И углавном се бавим продуктивношћу. Све што је у вези са Јавом, све што се односи на СКЛ је оно што волим.
А данас ћу говорити о томе са чиме смо се сусрели у компанији када смо почели да користимо ПостгреСКЛ као сервер базе података. И углавном радимо са Јавом. Али оно што ћу вам данас рећи није само о Јави. Као што је пракса показала, то се дешава и на другим језицима.
Ми ћемо причати:
- о узорковању података.
- О чувању података.
- И такође о перформансама.
- И о подводним грабљама које су ту закопане.
Почнимо са једноставним питањем. Бирамо један ред из табеле на основу примарног кључа.
База података се налази на истом хосту. И сва ова пољопривреда траје 20 милисекунди.
Ових 20 милисекунди је много. Ако имате 100 таквих захтева, онда трошите време у секунди на скроловање кроз ове захтеве, односно губимо време.
Не волимо ово да радимо и гледамо шта нам база нуди за ово. База података нам нуди две опције за извршавање упита.
Прва опција је једноставан захтев. Шта је ту добро? То што ми то узимамо и шаљемо, и ништа више.
База података такође има напредни упит, који је компликованији, али функционалнији. Можете засебно послати захтев за рашчлањивање, извршење, везивање променљивих итд.
Супер проширени упит је нешто што нећемо покривати у овом извештају. Ми, можда, желимо нешто из базе и постоји листа жеља која је у неком облику формирана, односно то је оно што желимо, али то је немогуће сада и у наредној години. Тако да смо то управо снимили и ићи ћемо около да дрмамо главне људе.
А оно што можемо да урадимо је једноставан упит и проширени упит.
Шта је посебно у сваком приступу?
Једноставан упит је добар за једнократно извршавање. Једном завршено и заборављено. А проблем је што не подржава бинарни формат података, односно није погодан за неке системе високих перформанси.
Проширени упит – омогућава вам да уштедите време на рашчлањивању. Ово смо урадили и почели да користимо. Ово нам је заиста помогло. Не постоји само уштеда на рашчлањивању. Постоје уштеде на преносу података. Пренос података у бинарном формату је много ефикаснији.
Пређимо на праксу. Овако изгледа типична апликација. То може бити Јава, итд.
Направили смо изјаву. Извршио наредбу. Цреатед цлосе. Где је ту грешка? У чему је проблем? Нема проблема. Тако пише у свим књигама. Овако треба писати. Ако желите максималан учинак, пишите овако.
Али пракса је показала да то не функционише. Зашто? Зато што имамо „блиски” метод. А када то урадимо, са тачке гледишта базе података испада да је то као пушач који ради са базом података. Рекли смо „ПАРСЕ ЕКСЕЦУТЕ ДЕАЛЛОЦАТЕ“.
Чему сво ово додатно креирање и растерећење изјава? Они никоме нису потребни. Али оно што се обично дешава у ПрепаредСтатементс је да када их затворимо, они затварају све у бази података. Ово није оно што желимо.
Желимо, као здрави људи, да радимо са базом. Једном смо узели и припремили нашу изјаву, а онда је извршимо много пута. У ствари, много пута - ово је једном у целом животу апликација - они су рашчлањени. И користимо исти ИД наредбе на различитим РЕСТ-овима. Ово је наш циљ.
Како то можемо постићи?
Веома је једноставно - нема потребе да затварате изјаве. Пишемо то овако: „припремити“ „извршити“.
Ако овако нешто покренемо, онда је јасно да ће се негде нешто прелити. Ако није јасно, можете га испробати. Хајде да напишемо бенцхмарк који користи ову једноставну методу. Направите изјаву. Покрећемо га на некој верзији драјвера и откријемо да се прилично брзо руши са губитком све меморије коју је имао.
Јасно је да се такве грешке лако исправљају. Нећу о њима. Али рећи ћу да нова верзија ради много брже. Метода је глупа, али ипак.
Како правилно радити? Шта треба да урадимо за ово?
У стварности, апликације увек затварају изјаве. У свим књигама кажу да се затвори, иначе ће сећање исцурити.
А ПостгреСКЛ не зна како да кешира упите. Неопходно је да свака сесија креира овај кеш за себе.
И не желимо да губимо време на рашчлањивање.
И као и обично, имамо две опције.
Прва опција је да то узмемо и кажемо да умотамо све у ПгСКЛ. Тамо постоји кеш меморија. Спрема све. Испаће сјајно. Видели смо ово. Имамо 100500 захтева. Не ради. Не слажемо се да ручно претварамо захтеве у процедуре. Не не.
Имамо другу опцију - узмите и сами га исечите. Отварамо изворе и почињемо да сечемо. Видели смо и видели. Испоставило се да то није тако тешко учинити.
Ово се појавило у августу 2015. Сада постоји модернија верзија. И све је супер. Толико добро функционише да ништа не мењамо у апликацији. И чак смо престали да размишљамо у правцу ПгСКЛ-а, односно ово нам је било сасвим довољно да све режијске трошкове сведемо скоро на нулу.
Сходно томе, наредбе припремљене на серверу се активирају при 5. извршењу како би се избегло трошење меморије у бази података на сваки једнократни захтев.
Можете питати – где су бројеви? шта добијаш? И овде нећу давати бројеве, јер сваки захтев има своје.
Наши упити су били такви да смо потрошили око 20 милисекунди на рашчлањивање ОЛТП упита. Било је 0,5 милисекунди за извршење, 20 милисекунди за рашчлањивање. Захтев – 10 КиБ текста, 170 редова плана. Ово је ОЛТП захтев. Захтева 1, 5, 10 редова, понекад и више.
Али уопште нисмо желели да губимо 20 милисекунди. Смањили смо је на 0. Све је супер.
Шта можеш да однесеш одавде? Ако имате Јава, онда узмите модерну верзију драјвера и радујте се.
Ако говорите другим језиком, онда размислите – можда вам и ово треба? Јер са становишта коначног језика, на пример, ако ПЛ 8 или имате ЛибПК, онда вам није очигледно да трошите време не на извршење, на рашчлањивање, и ово вреди проверити. Како? Све је бесплатно.
Осим што има грешака и неких посебности. И о њима ћемо сада разговарати. Највише ће бити о индустријској археологији, о томе шта смо пронашли, на шта смо наишли.
Ако се захтев генерише динамички. Дешава се. Неко спаја низове заједно, што резултира СКЛ упитом.
Зашто је лош? Лоше је јер сваки пут завршимо са другачијим низом.
А хасхЦоде овог различитог низа треба поново да се прочита. Ово је заиста ЦПУ задатак - проналажење дугачког текста захтева чак ни у постојећем хешу није тако лако. Дакле, закључак је једноставан - немојте генерисати захтеве. Чувајте их у једној променљивој. И радуј се.
Следећи проблем. Типови података су важни. Постоје ОРМ-ови који кажу да није важно какав НУЛЛ постоји, нека постоји нека врста. Ако је Инт, онда кажемо сетИнт. А ако је НУЛЛ, онда нека увек буде ВАРЦХАР. И каква је разлика на крају шта је НУЛЛ? Сама база података ће све разумети. А ова слика не ради.
У пракси, базу података уопште није брига. Ако сте први пут рекли да је ово број, а други пут сте рекли да је ВАРЦХАР, онда је немогуће поново користити изјаве које је припремио сервер. И у овом случају, морамо поново да креирамо нашу изјаву.
Ако извршавате исти упит, уверите се да типови података у вашој колони нису помешани. Морате пазити на НУЛЛ. Ово је уобичајена грешка коју смо имали након што смо почели да користимо ПрепаредСтатементс
У реду, укључено. Можда су узели возача. И продуктивност је опала. Ствари су постале лоше.
Како се ово дешава? Да ли је ово грешка или карактеристика? Нажалост, није било могуће разумети да ли је ово грешка или карактеристика. Али постоји врло једноставан сценарио за репродукцију овог проблема. Сасвим неочекивано нас је упала у заседу. И састоји се од узорковања буквално из једне табеле. Имали смо, наравно, више оваквих захтева. По правилу су укључивали два или три стола, али постоји такав сценарио репродукције. Узмите било коју верзију из своје базе података и играјте је.
Поента је да имамо две колоне, од којих је свака индексирана. У једној колони НУЛЛ има милион редова. А друга колона садржи само 20 редова. Када извршавамо без везаних променљивих, све функционише добро.
Ако почнемо да извршавамо са везаним променљивим, тј. извршимо "?" или „1$“ за наш захтев, шта ћемо на крају добити?
Прво извршење је очекивано. Други је мало бржи. Нешто је кеширано. Треће, четврто, пето. Онда прасак - и тако нешто. А најгоре је што се то дешава на шестом погубљењу. Ко је знао да је потребно извршити тачно шест егзекуција да би се схватило шта је заправо план извршења?
Ко је крив? Шта се десило? База података садржи оптимизацију. И изгледа да је оптимизован за генерички случај. И, сходно томе, почевши од неког тренутка, она прелази на генерички план, који се, нажалост, може показати другачијим. Може се испоставити да је исто, а може бити другачије. И постоји нека врста граничне вредности која доводи до оваквог понашања.
Шта можете учинити поводом тога? Овде је, наравно, теже било шта претпоставити. Постоји једноставно решење које користимо. Ово је +0, ОФФСЕТ 0. Сигурно знате таква решења. Само узмемо и додамо „+0“ захтеву и све је у реду. показаћу ти касније.
А постоји још једна опција - пажљивије погледајте планове. Програмер мора не само да напише захтев, већ и да каже „објасни анализу“ 6 пута. Ако је 5, неће радити.
А постоји и трећа опција - напишите писмо пгскл-хакерима. Написао сам, међутим, још није јасно да ли је ово грешка или карактеристика.
Док размишљамо да ли је ово грешка или карактеристика, хајде да то поправимо. Хајде да узмемо наш захтев и додамо „+0“. Све је у реду. Два симбола и не морате ни да размишљате о томе како је или шта је. Врло једноставна. Једноставно смо забранили бази података да користи индекс на овој колони. Немамо индекс у колони „+0“ и то је то, база података не користи индекс, све је у реду.
Ово је правило од 6 објашњења. Сада у тренутним верзијама морате то да урадите 6 пута ако имате везане променљиве. Ако немате везане варијабле, то је оно што ми радимо. И на крају, управо овај захтев пропада. То није шкакљива ствар.
Чини се, колико је могуће? Буба овде, буба тамо. У ствари, грешка је свуда.
Хајде да погледамо изблиза. На пример, имамо две шеме. Шема А са табелом С и дијаграм Б са табелом С. Упит – изаберите податке из табеле. Шта ћемо имати у овом случају? Имаћемо грешку. Имаћемо све наведено. Правило је – буба је свуда, имаћемо све наведено.
Сада је питање: "Зашто?" Чини се да постоји документација да ако имамо шему, онда постоји променљива "сеарцх_патх" која нам говори где да тражимо табелу. Чини се да постоји варијабла.
У чему је проблем? Проблем је у томе што изјаве припремљене на серверу не сумњају да неко може променити сеарцх_патх. Ова вредност остаје, такорећи, константна за базу података. А неки делови можда неће добити нова значења.
Наравно, ово зависи од верзије на којој тестирате. Зависи од тога колико се ваше табеле озбиљно разликују. А верзија 9.1 ће једноставно извршити старе упите. Нове верзије могу ухватити грешку и рећи вам да имате грешку.
Како то третирати? Постоји једноставан рецепт - немојте то радити. Нема потребе да мењате сеарцх_патх док је апликација покренута. Ако се промените, боље је да направите нову везу.
Можете дискутовати, односно отварати, дискутовати, додавати. Можда можемо да убедимо програмере базе података да када неко промени вредност, база података треба да каже клијенту о томе: „Види, твоја вредност је ажурирана овде. Можда треба да ресетујете изјаве и поново их креирате?" Сада се база података понаша тајно и ни на који начин не јавља да су се изјаве промениле негде унутра.
И поново ћу нагласити – ово је нешто што није типично за Јаву. Видећемо исту ствар у ПЛ/пгСКЛ један на један. Али тамо ће се репродуковати.
Хајде да пробамо још неколико података. Ми бирамо и бирамо. Имамо табелу са милион редова. Сваки ред је килобајт. Отприлике гигабајт података. И имамо радну меморију у Јава машини од 128 мегабајта.
Ми, као што се препоручује у свим књигама, користимо стреам обраду. То јест, отварамо сет резултата и читамо податке одатле мало по мало. Хоће ли успети? Хоће ли испасти из сећања? Хоћеш ли читати мало? Верујмо бази података, верујмо у Постгрес. Не верујемо. Хоћемо ли испасти из ОФМемори? Ко је искусио ОутОфМемори? Ко је после тога успео да то поправи? Неко је успео да то поправи.
Ако имате милион редова, не можете само да бирате. ОФФСЕТ/ЛИМИТ је обавезан. Ко је за ову опцију? А ко је за играње са аутоЦоммит-ом?
Овде се, као и обично, испоставља да је најнеочекиванија опција тачна. А ако изненада искључите аутоЦоммит, то ће помоћи. Зашто је то? Наука не зна за ово.
Али подразумевано, сви клијенти који се повезују на Постгрес базу података преузимају целокупне податке. ПгЈДБЦ није изузетак у овом погледу; он бира све редове.
Постоји варијација на тему ФетцхСизе, тј. можете рећи на нивоу засебне изјаве да овде, молимо вас да изаберете податке са 10, 50. Али ово не функционише док не искључите аутоЦоммит. Искључен аутоЦоммит - почиње да ради.
Али пролазак кроз код и постављање сетФетцхСизе свуда је незгодно. Због тога смо направили подешавање које ће рећи подразумевану вредност за целу везу.
То смо рекли. Параметар је конфигурисан. И шта смо добили? Ако бирамо мале количине, ако, на пример, бирамо 10 редова одједном, онда имамо веома велике режијске трошкове. Стога ову вредност треба поставити на око сто.
У идеалном случају, наравно, још увек морате да научите како да га ограничите у бајтовима, али рецепт је следећи: подесите дефаултРовФетцхСизе на више од сто и будите срећни.
Пређимо на убацивање података. Убацивање је лакше, постоје различите опције. На пример, ИНСЕРТ, ВАЛУЕС. Ово је добра опција. Можете рећи „ИНСЕРТ СЕЛЕЦТ“. У пракси је иста ствар. Нема разлике у перформансама.
Књиге кажу да морате да извршите наредбу Батцх, књиге кажу да можете извршити сложеније команде са неколико заграда. А Постгрес има дивну функцију - можете да урадите КОПИРАЊЕ, тј. урадите то брже.
Ако га измерите, поново можете направити нека занимљива открића. Како желимо да ово функционише? Желимо да не анализирамо и не извршавамо непотребне команде.
У пракси, ТЦП нам то не дозвољава. Ако је клијент заузет слањем захтева, онда база података не чита захтеве у покушају да нам пошаље одговоре. Крајњи резултат је да клијент чека да база података прочита захтев, а база података чека да клијент прочита одговор.
И стога је клијент приморан да повремено шаље пакет за синхронизацију. Додатне мрежне интеракције, додатно губљење времена.
И што их више додамо, све је горе. Возач је прилично песимистичан и додаје их прилично често, отприлике једном на сваких 200 редова, у зависности од величине редова итд.
Дешава се да исправите само једну линију и све ће се убрзати 10 пута. Дешава се. Зашто? Као и обично, оваква константа је већ негде коришћена. А вредност „128“ је значила да се не користи батцхинг.
Добро је што ово није укључено у званичну верзију. Откривено пре почетка објављивања. Сва значења која дајем заснована су на савременим верзијама.
Хајде да пробамо. Ми меримо ИнсертБатцх једноставно. ИнсертБатцх меримо више пута, односно исту ствар, али има много вредности. Трицки мове. Не може свако ово да уради, али то је тако једноставан потез, много лакши од КОПИРАЊА.
Можете да урадите ЦОПИ.
И то можете учинити на структурама. Декларирајте подразумевани тип корисника, проследите низ и ИНСЕРТ директно у табелу.
Ако отворите везу: пгјдбц/убенцхмсрк/ИнсертБатцх.јава, онда је овај код на ГитХуб-у. Можете видети конкретно који захтеви се тамо генеришу. Није битно.
Покренули смо. И прва ствар коју смо схватили је да је некоришћење серије једноставно немогуће. Све опције батцхинга су нуле, односно време извршења је практично нула у поређењу са једнократним извршавањем.
Убацујемо податке. То је врло једноставна табела. Три колоне. И шта ми овде видимо? Видимо да су све три ове опције отприлике упоредиве. А ЦОПИ је, наравно, бољи.
Ово је када убацујемо комаде. Када смо рекли да је једна ВРЕДНОСТ, две ВРЕДНОСТИ, три ВРЕДНОСТИ, или смо назначили 10 њих одвојених зарезом. Ово је сада само хоризонтално. 1, 2, 4, 128. Види се да се много боље осећа због Батцх Инсерт, који је нацртан плавом бојом. Односно, када убаците један по један или чак када убаците четири одједном, постаје дупло боље, једноставно зато што смо мало више нагурали у ВРЕДНОСТИ. Мање ЕКСЕЦУТЕ операција.
Коришћење ЦОПИ-а на малим количинама је изузетно обећавајуће. На прва два нисам ни цртао. Они иду у рај, односно ови зелени бројеви за ЦОПИ.
ЦОПИ треба користити када имате најмање стотину редова података. Режијски трошкови отварања ове везе су велики. И, да будем искрен, нисам копао у овом правцу. Оптимизовао сам Батцх, али не и ЦОПИ.
Шта ћемо даље? Пробали смо. Разумемо да треба да користимо или структуре или паметну бачву која комбинује неколико значења.
Шта треба да извучете из данашњег извештаја?
- ПрепаредСтатемент је наше све. Ово даје много за продуктивност. То производи велики пад у масти.
- И треба да урадите АНАЛИЗУ ОБЈАШЊЕЊА 6 пута.
- И треба да разблажимо ОФФСЕТ 0 и трикове попут +0 да бисмо исправили преостали проценат наших проблематичних упита.
Извор: ввв.хабр.цом