Извештај представља неке приступе који дозвољавају прати перформансе СКЛ упита када их има на милионе дневно, а постоје стотине надгледаних ПостгреСКЛ сервера.
Која техничка решења нам омогућавају да ефикасно обрадимо толики обим информација и како то олакшава живот обичном програмеру?
Ко је заинтересован? анализа специфичних проблема и различите технике оптимизације СКЛ упити и решавање типичних ДБА проблема у ПостгреСКЛ-у - такође можете на ову тему.
Моје име је Кирил Боровиков, представљам . Конкретно, специјализован сам за рад са базама података у нашој компанији.
Данас ћу вам рећи како оптимизујемо упите, када не морате да „раздвајате“ перформансе једног упита, већ масовно решавате проблем. Када има милион захтева, а треба их пронаћи приступе решењу овај велики проблем.
Генерално, Тенсор за милион наших клијената јесте : корпоративна друштвена мрежа, решења за видео комуникацију, за интерни и екстерни ток докумената, рачуноводствени системи за рачуноводство и складишта,... Односно, такав „мегакомбајн” за интегрисано управљање пословањем, у коме постоји више од 100 различитих интерни пројекти.
Како бисмо осигурали да сви нормално раде и развијају се, имамо 10 развојних центара широм земље, са више њих 1000 програмера.
Са ПостгреСКЛ-ом радимо од 2008. године и акумулирали смо велику количину онога што обрађујемо - клијентских података, статистичких, аналитичких, података из екстерних информационих система - више од 400ТБ. Само у производњи је око 250 сервера, а укупно има око 1000 сервера базе података које пратимо.
СКЛ је декларативни језик. Не описујете „како“ нешто треба да функционише, већ „шта“ желите да постигнете. ДБМС боље зна како да направи ЈОИН - како да повежеш табеле, које услове да наметнеш, шта ће проћи кроз индекс, шта неће...
Неки ДБМС прихватају наговештаје: „Не, повежите ове две табеле у тај и такав ред“, али ПостгреСКЛ то не може да уради. Ово је свесна позиција водећих програмера: „Радије бисмо завршили оптимизатор упита него дозволили програмерима да користе неке врсте савета.“
Али, упркос чињеници да ПостгреСКЛ не дозвољава „споља“ да се контролише, савршено дозвољава види шта се дешава у њемукада покренете свој упит и где има проблема.
Уопштено говорећи, са којим класичним проблемима обично долази програмер [у ДБА]? „Овде смо испунили захтев и код нас је све споро, све виси, нешто се дешава... Невоља нека!“
Разлози су скоро увек исти:
- неефикасан алгоритам упита
Програмер: „Сада му дајем 10 табела у СКЛ-у преко ЈОИН...“ - и очекује да ће његови услови на чудесан начин бити „развезани“ и да ће све брзо добити. Али чуда се не дешавају, и сваки систем са таквом варијабилности (10 табела у једном ФРОМ) увек даје неку врсту грешке. [] - небитне статистике
Ова тачка је веома релевантна посебно за ПостгреСКЛ, када „сипате“ велики скуп података на сервер, упутите захтев и он „сексира“ ваш таблет. Јер јуче је у њему било 10 записа, а данас их има 10 милиона, али ПостгреСКЛ још није свестан тога, а ми треба да му кажемо о томе. [] - „прикључити” ресурсе
Инсталирали сте велику и јако оптерећену базу података на слабом серверу који нема довољно перформанси диска, меморије или процесора. И то је све... Негде постоји плафон перформанси изнад којег више не можете да скочите. - блокирање
Ово је тешка тачка, али они су најрелевантнији за различите упите за модификовање (ИНСЕРТ, УПДАТЕ, ДЕЛЕТЕ) - ово је посебна велика тема.
Добијање плана
...А за све остало ми треба план! Морамо да видимо шта се дешава унутар сервера.
План извршења упита за ПостгреСКЛ је стабло алгоритма за извршење упита у текстуалном представљању. Управо се алгоритам, као резултат анализе планера, показао најефикаснијим.
Сваки чвор стабла је операција: преузимање података из табеле или индекса, прављење битмапе, спајање две табеле, спајање, пресецање или изузимање селекција. Извршавање упита укључује шетњу кроз чворове овог стабла.
Да бисте добили план упита, најлакши начин је да извршите наредбу EXPLAIN. Да бисте добили све стварне атрибуте, односно да бисте стварно извршили упит на бази - EXPLAIN (ANALYZE, BUFFERS) SELECT ....
Лош део: када га покренете, то се дешава „овде и сада“, тако да је погодан само за локално отклањање грешака. Ако узмете високо оптерећен сервер који је под јаким протоком промена података, и видите: „Ох! Овде имамо споро извршењецампинг захтев." Пре пола сата, сат - док сте радили и добијали овај захтев из евиденције, враћајући га назад на сервер, цео ваш скуп података и статистика су се променили. Покрените га да бисте отклонили грешке - и ради брзо! И не можете да разумете зашто, зашто био полако.
Да би разумели шта се тачно догодило у тренутку када је захтев извршен на серверу, писали су паметни људи . Присутан је у скоро свим најчешћим ПостгреСКЛ дистрибуцијама и може се једноставно активирати у конфигурационој датотеци.
Ако схвати да неки захтев траје дуже од ограничења које сте му рекли, то ради „снимка“ плана овог захтева и уписује их заједно у дневник.
Чини се да је сада све у реду, идемо до балвана и видимо тамо... [текст крпа]. Али не можемо ништа рећи о томе, осим чињенице да је то одличан план јер је било потребно 11 мс да се изврши.
Чини се да је све у реду - али ништа није јасно шта се заправо догодило. Осим општег времена, ми заправо не видимо ништа. Јер гледање у такво „јагње“ обичног текста углавном није визуелно.
Али чак и ако није очигледно, чак и ако је незгодно, постоје фундаменталнији проблеми:
- Чвор указује збир ресурса целог подстабла под њим. Односно, не можете само да сазнате колико је времена потрошено на ово конкретно скенирање индекса ако испод њега постоји неки угнежђени услов. Морамо динамички погледати да ли постоје „деца“ и условне варијабле, ЦТЕ-ови унутра – и одузети све ово „у нашим умовима“.
- Друга тачка: време које је назначено на чвору је време извршења једног чвора. Ако је овај чвор извршен као резултат, на пример, петље кроз записе табеле неколико пута, онда се број петљи — циклуса овог чвора — повећава у плану. Али само атомско време извршења остаје исто у смислу плана. Односно, да бисте разумели колико је овај чвор укупно изведен, потребно је да помножите једну ствар са другом - опет, „у својој глави“.
У таквим ситуацијама схватите „Ко је најслабија карика?“ готово немогуће. Стога чак и сами програмери пишу у „приручнику“ да „Разумевање плана је уметност која се мора научити, доживети...“.
Али имамо 1000 програмера и не можете пренети ово искуство сваком од њих. Ја, ти, он зна, али неко тамо више не зна. Можда ће научити, а можда и не, али сада треба да ради – а где би добио ово искуство?
Визуелизација плана
Стога смо схватили да нам је за решавање ових проблема потребно добра визуелизација плана.
Прво смо прошли „кроз тржиште“ – хајде да погледамо на Интернету да видимо шта уопште постоји.
Али показало се да постоји врло мало релативно „живих“ решења која се мање-више развијају – буквално, само једно: од Хуберта Лубацзевског. Када унесете у поље „феед“ текстуални приказ плана, он вам показује табелу са рашчлањеним подацима:
- сопствено време обраде чвора
- укупно време за цело подстабло
- број преузетих записа који су статистички очекивани
- само тело чвора
Ова услуга такође има могућност дељења архиве веза. Убацио си свој план и рекао: „Хеј, Васја, ево линка, ту нешто није у реду.
Али постоје и мали проблеми.
Прво, огромна количина „цопи-пасте“. Узмете комад трупца, забијете га унутра, и опет, и поново.
Друго, нема анализе количине прочитаних података — исти бафери који излазе EXPLAIN (ANALYZE, BUFFERS), ми то овде не видимо. Он једноставно не зна како да их раставља, разуме и ради са њима. Када читате много података и схватите да можда погрешно додељујете диск и кеш меморију, ове информације су веома важне.
Трећа негативна тачка је веома слаб развој овог пројекта. Урезивања су веома мала, добро је једном у шест месеци, а код је у Перлу.
Али ово је све „стихови”, могли бисмо некако да живимо са овим, али има једна ствар која нас је увелико одвратила од ове услуге. То су грешке у анализи Цоммон Табле Екпрессион (ЦТЕ) и разних динамичких чворова попут ИнитПлан/СубПлан.
Ако верујете овој слици, онда је укупно време извршења сваког појединачног чвора веће од укупног времена извршења целог захтева. То је једноставно - време генерисања овог ЦТЕ није одузето од чвора ЦТЕ скенирања. Због тога више не знамо тачан одговор колико је дуго трајало само ЦТЕ скенирање.
Онда смо схватили да је време да напишемо своје – ура! Сваки програмер каже: „Сада ћемо написати своје, биће супер лако!“
Узели смо стек типичан за веб сервисе: језгро засновано на Ноде.јс + Екпресс, користили Боотстрап и Д3.јс за лепе дијаграме. И наша очекивања су била потпуно оправдана - добили смо први прототип за 2 недеље:
- прилагођени анализатор плана
То јест, сада можемо рашчланити било који план од оних које генерише ПостгреСКЛ. - тачна анализа динамичких чворова - ЦТЕ скенирање, ИнитПлан, СубПлан
- анализа расподеле бафера - где се странице са подацима читају из меморије, где из локалне кеш меморије, где са диска
- добио јасноћу
Да не би све ово „копали“ по логу, већ да бисмо одмах на слици видели „најслабију карику“.
Добили смо нешто овако, са укљученим истицањем синтаксе. Али обично наши програмери више не раде са потпуним приказом плана, већ са краћим. На крају крајева, све бројеве смо већ рашчланили и бацили лево и десно, а у средини смо оставили само први ред, какав је то чвор: ЦТЕ Сцан, ЦТЕ генерација или Сек Сцан по неком знаку.
Ово је скраћени приказ који зовемо шаблон плана.
Шта би још било згодно? Било би згодно видети који део нашег укупног времена је додељен ком чвору - и само га „залепити“ на страну пие цхарт.
Показујемо на чвор и видимо - испоставило се да је Сек Сцан заузео мање од четвртине укупног времена, а преостале 3/4 је преузео ЦТЕ Сцан. Ужас! Ово је мала напомена о „брзи паљбе“ ЦТЕ скенирања ако их активно користите у својим упитима. Нису баш брзи - инфериорни су чак и од редовног скенирања стола.
Али обично су такви дијаграми занимљивији, сложенији, када одмах покажемо на сегмент и видимо, на пример, да више од половине времена „једе“ неки Сек Сцан. Штавише, унутра је била нека врста филтера, много записа је одбачено према њему... Можете директно бацити ову слику програмеру и рећи: „Васја, овде ти је све лоше! Схвати, види – нешто није у реду!“
Наравно, ту су биле неке „грабље“.
Прво на шта смо наишли је проблем заокруживања. Време сваког појединачног чвора у плану је назначено са тачношћу од 1 μс. А када број циклуса чвора пређе, на пример, 1000 - након извршења ПостгреСКЛ-а подељено „унутар тачности“, онда када се рачуна уназад добијамо укупно време „негде између 0.95 мс и 1.05 мс“. Када бројање иде на микросекунде, то је у реду, али када је већ [мили]секунде, морате узети у обзир ове информације када „одвезујете“ ресурсе на чворове плана „ко је колико потрошио“.
Друга тачка, сложенија, је расподела ресурса (ти бафери) међу динамичким чворовима. Ово нас је коштало прве 2 недеље прототипа плус још 4 недеље.
Прилично је лако добити ову врсту проблема - радимо ЦТЕ и наводно нешто читамо у њему. У ствари, ПостгреСКЛ је „паметан“ и неће читати ништа директно тамо. Затим из њега узимамо први запис, а њему сто први из истог ЦТЕ.
Гледамо план и разумемо – чудно је, имамо 3 бафера (странице са подацима) „потрошена“ у Сек Сцан, још 1 у ЦТЕ скенирању и још 2 у другом ЦТЕ скенирању. То јест, ако једноставно све саберемо, добићемо 6, али са таблета читамо само 3! ЦТЕ скенирање не чита ништа нигде, већ ради директно са процесном меморијом. Односно, овде нешто очигледно није у реду!
У ствари, испада да су овде све оне 3 странице података које су тражене од Сек Сцан-а, прво је 1 тражила 1. ЦТЕ скенирање, па 2. па су му прочитане још 2. То јест, укупно 3 странице су прочитани подаци, а не 6.
И ова слика нас је довела до схватања да извршење плана више није дрво, већ једноставно нека врста ацикличног графа. И добили смо овакав дијаграм, тако да разумемо „шта је уопште дошло“. То јест, овде смо креирали ЦТЕ од пг_цласс, и тражили смо га два пута, и скоро све наше време је потрошено на грани када смо то тражили други пут. Јасно је да је читање 2. уноса много скупље него само читање 101. уноса са таблета.
Издисали смо неко време. Рекли су: „Сада, Нео, знаш кунг фу! Сада је наше искуство право на вашем екрану. Сада га можете користити."
Консолидација дневника
Наших 1000 програмера је одахнуло. Али схватили смо да имамо само стотине „борбених“ сервера, а све ово „цопи-пасте“ од стране програмера није нимало згодно. Схватили смо да то морамо сами да прикупимо.
Генерално, постоји стандардни модул који може прикупљати статистику, међутим, он такође треба да се активира у конфигурацији - ово . Али он нам није одговарао.
Прво, додељује истим упитима користећи различите шеме унутар исте базе података различити КуериИдс. То јест, ако то прво урадите SET search_path = '01'; SELECT * FROM user LIMIT 1;и онда SET search_path = '02'; и исти захтев, онда ће статистика овог модула имати различите евиденције и нећу моћи да прикупљам општу статистику посебно у контексту овог профила захтева, без узимања у обзир шема.
Друга тачка која нас је спречила да га користимо је недостатак планова. Односно, нема плана, постоји само сам захтев. Видимо шта се успорава, али не разумемо зашто. И овде се враћамо на проблем скупа података који се брзо мења.
И последњи тренутак - недостатак "чињеница". То јест, не можете да се позабавите одређеном инстанцом извршења упита - не постоји, постоји само агрегирана статистика. Иако је могуће радити са овим, то је једноставно веома тешко.
Стога смо одлучили да се боримо против копирај-пејста и почели да пишемо цоллецтор.
Колектор се повезује преко ССХ-а, успоставља безбедну везу са сервером са базом података помоћу сертификата и tail -F „приања“ за њега у датотеци евиденције. Дакле, у овој седници добијамо комплетно „огледало“ целе датотеке евиденције, који сервер генерише. Оптерећење самог сервера је минимално, јер тамо ништа не анализирамо, само огледамо саобраћај.
Пошто смо већ почели да пишемо интерфејс у Ноде.јс, наставили смо са писањем колектора у њему. И ова технологија се оправдала, јер је веома згодно користити ЈаваСцрипт за рад са слабо форматираним текстуалним подацима, а то је дневник. И сама Ноде.јс инфраструктура као позадинска платформа омогућава вам да лако и удобно радите са мрежним везама, и заиста са било којим токовима података.
Сходно томе, „развлачимо“ две везе: прву да „преслушамо“ сам дневник и узмемо га себи, а другу да повремено питамо базу. „Али евиденција показује да је знак са оид 123 блокиран“, али то не значи ништа програмеру и било би лепо питати базу података: „Шта је уопште ОИД = 123?“ И тако периодично питамо базу шта још не знамо о себи.
„Постоји само једна ствар коју нисте узели у обзир, постоји врста пчела налик на слонове!..” Почели смо да развијамо овај систем када смо желели да надгледамо 10 сервера. Најкритичнији у нашем разумевању, где су се појавили проблеми са којима је било тешко решити се. Али током првог квартала добили смо стотину за праћење – јер је систем функционисао, сви су то желели, свима је било удобно.
Све ово треба сабрати, проток података је велики и активан. У ствари, оно што пратимо, оно са чиме можемо да се носимо је оно што користимо. Такође користимо ПостгреСКЛ као складиште података. И ништа није брже за „уливање“ података у њега од оператера COPY Још није.
Али једноставно „сипање“ података није наша технологија. Јер ако имате приближно 50 захтева у секунди на сто сервера, онда ће то генерисати 100-150 ГБ дневника дневно. Због тога смо морали пажљиво да "исечемо" базу.
Прво, јесмо подела по дану, јер, углавном, корелација између дана никога не занима. Какве везе има оно што сте имали јуче, ако сте вечерас избацили нову верзију апликације - и већ неку нову статистику.
Друго, научили смо (били смо присиљени) веома, веома брзо за писање користећи COPY. Односно, не само COPYјер је бржи од INSERT, па чак и брже.
Трећа тачка – морао сам напусти окидаче, односно стране кључеве. Односно, ми уопште немамо референтни интегритет. Јер ако имате табелу која има пар ФК-ова, а у структури базе података кажете да „овде је запис дневника на који ФК упућује, на пример, на групу записа“, онда када га убаците, ПостгреСКЛ не преостаје ништа осим како то узети и учинити поштено SELECT 1 FROM master_fk1_table WHERE ... са идентификатором који покушавате да убаците - само да бисте проверили да ли је овај запис присутан тамо, да не "прекидате" овај страни кључ својим уметањем.
Уместо једног записа у циљној табели и њеним индексима, добијамо додатну корист читања из свих табела на које се односи. Али ово нам уопште не треба - наш задатак је да снимимо што је више могуће и што је брже могуће уз најмање оптерећење. Па ФК - доле!
Следећа тачка је агрегација и хеширање. У почетку смо их имплементирали у базу података - уосталом, згодно је да одмах, када стигне запис, то урадите на некој врсти таблета "плус један" право у окидачу. Па, згодно је, али иста лоша ствар - убаците један запис, али сте приморани да читате и пишете нешто друго из друге табеле. Штавише, не само да читате и пишете, већ то радите сваки пут.
Сада замислите да имате табелу у којој једноставно бројите број захтева који су прошли кроз одређени хост: +1, +1, +1, ..., +1. А вама, у принципу, ово није потребно - све је могуће сума у меморији на колектору и послати у базу података у једном потезу +10.
Да, у случају неких проблема, ваш логички интегритет може да се „распадне“, али ово је скоро нереалан случај – зато што имате нормалан сервер, има батерију у контролеру, имате дневник трансакција, дневник на систем датотека... Генерално, не вреди. Губитак продуктивности који добијате од покретања окидача/ФК није вредан трошкова које имате.
Исто је и са хеширањем. Долети вам одређени захтев, ви из њега израчунате одређени идентификатор у бази, упишете га у базу и онда то кажете свима. Све је у реду док вам у време снимања не дође друга особа која жели да сними исту ствар - и будете блокирани, а ово је већ лоше. Стога, ако можете да пренесете генерисање неких ИД-а на клијента (у односу на базу података), боље је то учинити.
Било нам је савршено да користимо МД5 из текста - захтев, план, шаблон,... Рачунамо га на страни колектора, а готов ИД „сипамо“ у базу података. Дужина МД5 и дневно партиционисање нам омогућавају да не бринемо о могућим колизијама.
Али да бисмо све ово брзо снимили, морали смо да изменимо саму процедуру снимања.
Како обично пишете податке? Имамо неку врсту скупа података, поделимо га у неколико табела, па га КОПИРАЈМО – прво у прву, па у другу, у трећу... Незгодно је, јер изгледа да пишемо један ток података у три корака секвенцијално. Непријатно. Може ли се то учинити брже? Моћи!
Да бисте то урадили, довољно је само разложити ове токове паралелно једни с другима. Испоставило се да имамо грешке, захтеве, шаблоне, блокаде, ... лете у одвојеним нитима - и све то пишемо паралелно. Довољно за ово држати ЦОПИ канал стално отворен за сваку појединачну циљну табелу.
То јест, код колектора увек постоји поток, у који могу да упишем податке који су ми потребни. Али да база података види ове податке, и да неко не заглави чекајући да се ови подаци запишу, ЦОПИ мора бити прекинут у одређеним интервалима. За нас је најефикаснији период био око 100мс - затварамо га и одмах поново отварамо за исти сто. А ако немамо довољно једног протока током неких пикова, онда радимо удруживање до одређене границе.
Поред тога, открили смо да је за такав профил оптерећења свако здруживање, када се записи прикупљају у групама, зло. Класично зло је INSERT ... VALUES и још 1000 записа. Зато што у том тренутку имате врхунац писања на медију, а сви остали који покушавају да запишу нешто на диск ће чекати.
Да бисте се отарасили таквих аномалија, једноставно немојте ништа агрегирати, не тампонујте уопште. А ако дође до баферовања на диск (на срећу, Стреам АПИ у Ноде.јс вам омогућава да сазнате) - одложите ову везу. Када примите догађај да је поново бесплатан, пишите му из нагомиланог реда. И док је заузето, узмите следећи бесплатни из базена и пишите му.
Пре увођења оваквог приступа снимању података, имали смо отприлике 4К операција писања, и на тај начин смо смањили оптерећење за 4 пута. Сада су порасле још 6 пута због нових надгледаних база података - до 100МБ/с. А сада чувамо евиденције за последња 3 месеца у запремини од око 10-15ТБ, надајући се да ће за само три месеца било који програмер моћи да реши било који проблем.
Разумемо проблеме
Али једноставно прикупљање свих ових података је добро, корисно, релевантно, али недовољно – то треба разумети. Јер ово су милиони различитих планова дневно.
Али милиони су неуправљиви, прво морамо да урадимо „мање“. И, пре свега, треба да одлучите како ћете организовати ову „мању“ ствар.
Идентификовали смо три кључне тачке:
- који послао овај захтев
Односно, из које апликације је „стигао“: веб интерфејс, бацкенд, систем плаћања или нешто друго. - где то се десило
На ком конкретном серверу? Јер ако имате више сервера под једном апликацијом, а одједном један „поглупи“ (јер је „диск покварен“, „процурила меморија“, неки други проблем), онда се морате посебно обратити серверу. - као проблем се манифестовао на овај или онај начин
Да бисмо разумели „ко“ нам је послао захтев, користимо стандардни алат - подешавање променљиве сесије: SET application_name = '{bl-host}:{bl-method}'; — шаљемо име хоста пословне логике са којег долази захтев и назив методе или апликације која га је покренула.
Након што смо проследили „власника“ захтева, он се мора исписати у дневник - за то конфигуришемо променљиву log_line_prefix = ' %m [%p:%v] [%d] %r %a'. За заинтересоване, можда шта све то значи. Испоставило се да видимо у дневнику:
- време
- идентификатори процеса и трансакција
- Назив базе података
- ИП особе која је послала овај захтев
- и назив методе
Тада смо схватили да није баш занимљиво гледати корелацију за један захтев између различитих сервера. Није често да имате ситуацију да једна апликација подједнако зезне ту и тамо. Али чак и ако је исто, погледајте било који од ових сервера.
Дакле, ево резања "један сервер - један дан" показало се да нам је то било довољно за било какву анализу.
Први аналитички део је исти "узорак" - скраћени облик приказа плана, очишћен од свих бројчаних показатеља. Други рез је апликација или метода, а трећи рез је специфични чвор плана који нам је стварао проблеме.
Када смо са одређених инстанци прешли на шаблоне, добили смо две предности одједном:
- вишеструко смањење броја објеката за анализу
Проблем више не морамо анализирати хиљадама упита или планова, већ десетинама шаблона. - Временска линија
То јест, сумирањем „чињеница“ у оквиру одређеног одељка, можете приказати њихов изглед током дана. И овде можете разумети да ако имате неку врсту шаблона који се дешава, на пример, једном на сат, али би требало да се дешава једном дневно, требало би да размислите шта је пошло наопако - ко је то изазвао и зашто, можда би требало да буде овде не би требало. Ово је још један ненумерички, чисто визуелни, метод анализе.
Преостале методе су засноване на индикаторима које издвајамо из плана: колико пута се такав образац десио, укупно и просечно време, колико података је прочитано са диска, а колико из меморије...
Јер, на пример, дођете на страницу аналитике за хост, видите – нешто почиње да чита превише на диску. Диск на серверу не може да се носи са тим - ко чита са њега?
А можете сортирати по било којој колони и одлучити чиме ћете се тренутно бавити - оптерећењем процесора или диска, или укупним бројем захтева... Ми смо то сортирали, погледали „најбоље“, поправили и представила нову верзију апликације.
И одмах можете видети различите апликације које долазе са истим шаблоном из захтева попут SELECT * FROM users WHERE login = 'Vasya'. Фронтенд, бацкенд, обрада... И питате се зашто би обрада читала корисника ако не ступа у интеракцију са њим.
Супротан начин је да одмах видите из апликације шта ради. На пример, фронтенд је ово, ово, ово и ово једном на сат (временска линија помаже). И одмах се поставља питање: изгледа да није посао фронтенда да ради нешто једном на сат...
После неког времена, схватили смо да нам недостаје агрегација статистика по чворовима плана. Из планова смо изоловали само оне чворове који раде нешто са подацима самих табела (читају/уписују их по индексу или не). У ствари, само је један аспект додат у односу на претходну слику - колико нам је записа донео овај чвор?, и колико је одбачено (Редови уклоњени филтером).
Немате одговарајући индекс на табли, затражите га, он пролети поред индекса, упадне у Сек Сцан... филтрирали сте све записе осим једног. Зашто вам је потребно 100 милиона филтрираних записа дневно? Зар није боље да се индекс савије?
Анализирајући све планове чвор по чвор, схватили смо да у плановима постоје неке типичне структуре које ће врло вероватно изгледати сумњиво. И било би лепо рећи програмеру: „Пријатељу, овде прво читаш по индексу, затим сортирај, а затим одсечеш“ - по правилу постоји један запис.
Свако ко је писао упите вероватно је наишао на овај образац: „Дај ми последњу наруџбу за Васју, њен датум.“ А ако немате индекс по датуму, или нема датума у индексу који сте користили, онда ћете стане на потпуно исте „грабље“ .
Али знамо да је ово „грабље“ - па зашто не бисте одмах рекли програмеру шта треба да уради. Сходно томе, када сада отвори план, наш програмер одмах види прелепу слику са саветима, где му одмах кажу: „Имаш проблема ту и тамо, али они се решавају овако и онако“.
Као резултат тога, количина искуства која је била потребна за решавање проблема на почетку и сада је значајно опала. Ово је врста алата који имамо.
Извор: ввв.хабр.цом