Масова оптимизация на заявки в PostgreSQL. Кирил Боровиков (Тензор)

Докладът представя някои подходи, които позволяват да се следи производителността на SQL запитванията, когато те са милиони на ден, а контролирани сървъри PostgreSQL — стотици.

Кои технически решения ни позволяват ефективно да обработваме такъв обем информация и как това улеснява живота на обикновения разработчик.

На кого е интересно разглеждането на конкретни проблеми и различни техники за оптимизация на SQL запроси и решения на типични DBA задачи в PostgreSQL — може също така да се запознаете със серия статии по тази тема.


Казвам се Кирил Боровиков, представям компанията „Тензор“.. Конкретно специализацията ми е свързана с работата с бази данни в нашата компания.

Днес ще ви разкажа как оптимизираме запитвания, когато трябва не „да разглобим“ производителността на конкретно запитване, а да решим проблема в масов мащаб. Когато има милиони запитвания, и трябва да намерим подходи за решаване на този сериозен проблем.

Всъщност, „Тензор“ за милион нашите клиенти — това е СБИС — нашето приложение: корпоративна социална мрежа, решения за видеовръзки, за вътрешен и външен документооборот, счетоводни системи и складови… Тоест, подобен „мега-комбайн“ за комплексно управление на бизнеса, в който има над 100 различни вътрешни проекта.

За да функционират правилно и да се развиват всички те — имаме 10 центрове за разработка в цялата страна, в които работят над 1000 разработчици..

С PostgreSQL работим от 2008 година и натрупахме голям обем от това, което обработваме — клиентски данни, статистически, аналитични, данни от външни информационни системи — повече от 400TB.. Само в „производството“ имаме около 250 сървъра, а общо БД-сървърите, които наблюдаваме — около 1000.

SQL e декларативен език. Описвате не „как“ нещо трябва да работи, а „какво“ искате да получите. СУБД-то по-добре знае как да направи JOIN — как да свърже вашите таблици, какви условия да наложи, какво ще мине по индекса, какво не…

Някои СУБД приемат подсказки: „Не, свързвай тези две таблици в такава последователност“, но PostgreSQL не може да се справи с това. Това е осъзната позиция на водещите разработчици: „По-добре да усъвършенстваме оптимизатора на заявки, отколкото да разрешим на разработчиците да използват някакви подсказки“.

Но, въпреки че PostgreSQL не позволява "отвън" да се управлява, той предоставя отлична възможност да видите какво се случва "вътре", когато изпълнявате вашата заявка и къде възникват проблемите.

Обикновено, с какви класически проблеми се сблъсква разработчикът [к DBA]? "В изпълнението на заявка и всичко ни е бавно, всичко засяда, нещо се случва… Проблем!"

Причините почти винаги са едни и същи:

• неефективен алгоритъм на заявка
  Разработчикът: "Сега имам 10 таблици през JOIN в SQL…" — и очаква, че условията му прекрасно ще се "развържат" и той ще получи всичко бързо. Но чудеса не се случват, и всяка система при такава променливост (10 таблици в един FROM) винаги дава някаква неточност. [статия]
• неактуална статистика
  Моментът е изключително важен точно за PostgreSQL, когато сте "влили" голям набор от данни на сървъра, правите заявка — а той "сканира" таблицата. Защото вчера е имало 10 записа в нея, а днес 10 милиона, но PostgreSQL все още не е наясно с това, и трябва да му кажете. [статия]
• "стесняване" по ресурси
  Сложили сте голяма и натоварена база данни на слаб сървър, който няма достатъчно дисково пространство, памет или производителност на самия процесор. И това е всичко… Някъде има таван на производителността, над който вече не можете да скочите.
• блокиране
  Сложен момент, но те са най-актуални за различни модифициращи заявки (INSERT, UPDATE, DELETE) — това е отделна голяма тема.

Получаване на плана

… А за всичко останало ни е необходим план! Трябва да видим какво се случва вътре в сървъра.

Планът за изпълнение на заявката за PostgreSQL е дърво на алгоритъма за изпълнение на заявката в текстово представяне. Това е именно алгоритъмът, който в резултат на анализа е признат от планиращия за най-ефективен.

Всеки възел от дървото е операция: извличане на данни от таблица или индекс, изграждане на битова карта, свързване на две таблици, обединяване, пресичане или изключване на извадки. Изпълнението на заявката е преминаване през възлите на това дърво.

За да получите плана на заявката, най-простият начин е да изпълните оператора EXPLAIN. За да получите с всички реални атрибути, всъщност изпълнявате заявката на базата — EXPLAIN (ANALYZE, BUFFERS) SELECT ....

Лош момент: когато го изпълнявате, това се случва «тук и сега», което го прави подходящо само за локална отладка. Ако обаче вземете някой силно натоварен сървър, който е под силен поток от промени в данните, и видите: «О, не! Тук имаме бавно изпълнение назаявка.» Половин час, час назад — докато тичахте и извличахте тази заявка от логовете, носехте я обратно на сървъра, всичките ви набори от данни и статистики се промениха. Изпълнявате я, за да отладите — и тя се изпълнява бързо! И не можете да разберете «защо», защо бавно. да има За да разберете какво точно се е случвало в момента, когато заявката се изпълнява на сървъра, умните хора написаха

модул auto_explain . Той присъства практически във всички най-разпространени дистрибуции на PostgreSQL и може просто да се активира в конфиг файла.Ако разбере, че някоя заявка се изпълнява по-дълго от лимита, който сте му задали, той прави

«снимка» на плана на тази заявка и записва ги заедно в лог Изглежда всичко е добре, отиваме в логовете и виждаме там… [портянка текст]. Но не можем да кажем нищо за него, освен факта, че това е отличен план, защото е изпълняван 11 мс..

Изглежда всичко е наред — но нищо не е ясно какво наистина се е случвало. Освен общото време, почти нищо не виждаме. Защото да се гледа на такава «латуха» plain text е напълно неясно.

Но дори да е неясно, да е неудобно, има по-сериозни проблеми:

В възела се указва

• сумата на ресурсите на цялото поддърво под него. Тоест просто така да разберем колко време точно е било похарчено на този Index Scan — не можем, ако под него има някакво вложено условие. Трябва да гледаме динамично, дали няма «деца» и условни променливи, CTE — и да изчисляваме всичко това «в ума». Вторият момент: времето, което е указано на възела, — това е
• времето на единично изпълнение на възела . Ако този възел е изпълняван в резултат, например, на цикъл по записите на таблицата, многократно, тогава в плана увеличава броя на цикли — на цикли на този възел. Но самото време на атомарното изпълнение остава в плана същото. Тоест, за да разберем, колко време този възел е изпълняван общо, трябва да умножим едното по другото — отново «в ума».. Ако този възел е бил изпълнен в резултат, например, на цикъл през записите на таблицата, многократно, то в плана се увеличава броят на loops — циклите на този възел. Но самото времетраене на атомарното изпълнение остава в плана непроменено. Тоест, за да разберем колко точно е бил изпълняван този възел общо, трябва да умножим едното по другото — отново „в ума“.

При тези обстоятелства е практически невъзможно да се разбере кой е "най-слабото звено". Затова дори самите разработчици в "мануала" пишат, че "Разбирането на плана е изкуство, което трябва да се учи, опит...".

Но ние имаме 1000 разработчици, и на всеки от тях този опит не може да бъде предаден. Аз, ти, той — знаят, а някой там — вече не. Може да се научи, а може и да не се, но трябва да работи вече сега — а от къде да вземе този опит?

Визуализация на плана

Затова разбрахме — за да се справим с тези проблеми, ни е нужна добра визуализация на плана. [статия]

Започнахме "по пазара" — да видим какво съществува в интернет.

Но се оказа, че относно "живите" решения, които се развиват, има съвсем малко — буквално, едно: explain.depesz.com от Hubert Lubaczewski. Входно поле "вкарваш" текстовото представяне на плана и то ти показва таблица с анализираните данни:

• времето, необходимо за обработка на възел
• общото време за целия поддърво
• броя записи, които са били извлечени и които статистически се очакваха
• самото тяло на възела

Този сервис предлага също и възможност за споделяне на архив от връзки. Можеш да изпратиш своя план и да кажеш: "Хей, Васе, ето ти линк, там нещо не е наред."

Но има и малки проблеми.

На първо място, огромно количество "копипаста". Взимаш парче от лог, слагаш го там и отново, и отново.

На второ място, няма анализ на броя прочетени данни - същите тези buffers, които извежда EXPLAIN (ANALYZE, BUFFERS), тук не ги виждаме. Той просто не знае как да ги анализира, разбира и работи с тях. Когато четеш много данни и осъзнаеш, че можеш да се разпределиш неправилно по диска и кеша в паметта, тази информация е много важна.

Третият отрицателен момент — много слабо развитие на този проект. Комитите са много малки, добре е ако са веднъж на полгода, а кодът е на Perl.

Но всичко това е "лирика", с това може да се живее, но има едно нещо, което ни обърна силно от този сервис. Това са грешките в анализа на Common Table Expression (CTE) и различни динамични възли като InitPlan/SubPlan.

Ако вярваме на тази картинка, общото време за изпълнение на всеки отделен възел е повече от общото време за изпълнение на целия запит. Всичко е просто — не е извадено времето за генериране на тази CTE от възела CTE Scan.Затова вече не знаем правилния отговор, колко време отне самото сканиране CTE.

Тук разбрахме, че е време да напишем наше — ура-ура! Всеки разработчик казва: „Сега ще напишем наше, ще бъде супер лесно!“

Взехме типичен стек за уеб услуги: ядро на Node.js + Express, сложихме Bootstrap и за красивите диаграми — D3.js. И нашите очаквания се оправдаха — първият прототип получихме за 2 седмици:

• собствен парсер на плана
  Това означава, че сега можем да анализираме абсолютно всеки план, който генерира PostgreSQL.
• коректен анализ на динамичните възли — CTE Scan, InitPlan, SubPlan
• анализ на разпределението на buffers — къде се четат страниците с данни от паметта, къде от локалния кеш, къде от диска
• получихме забележителна визуализация
  За да не „копаем“ всичко това в логовете, а да видим „най-слабата връзка“ веднага на картината.

Получихме приблизително такава картина — веднага с подсветка на синтаксиса. Но обикновено нашите разработчици работят не с пълно представяне на плана, а с това, което е по-кратко. Всеки номер вече сме анализирали и отстранили, а посредата оставихме само първия ред, който показва какъв е възелът: CTE Scan, генерация на CTE или Seq Scan по някаква таблица.

Това опростено представяне наричаме шаблон на плана.

Какво още би било удобно? Щеше да е удобно да виждаме каква част от общото време се разпределя на кой възел — и просто „приклеихме“ отстрани диаграма с пай.

Навеждаме курсора на възела и виждаме — оказва се, че Seq Scan отнел по-малко от четвърт от всичкото време, а останалите 3/4 отиде за CTE Scan. Ужас! Това е малко забележка относно „скоростта“ на CTE Scan, ако активно ги използвате в своите запитвания. Те не са много бързи — дори губят на обикновеното сканиране на таблици. [статия] [статия]

Но обикновено такива диаграми са по-интересни, по-сложни, когато наведем курсора на сегмента и виждаме, например, че повече от половината от всичкото време е „изял“ някакъв Seq Scan. И вътре имаше някакъв Filter, куп записи бяха отхвърлени от него... Можем да изпратим тази картина направо на разработчика и да кажем: „Вася, при теб всичко е зле! Разбери, погледни — нещо не е наред!“

Естествено, не минахме без „грабли“.

Първото, което "натъкнахме", е проблемът с закръгленията. Времето на възела за всеки отделен елемент в плана се посочва с точност до 1 мкс. И когато броят на цикли на възела надвишава, например, 1000 — след изпълнението PostgreSQL дели "с точност до", то при обратно изчисление получаваме общото време "някъде между 0.95 мс и 1.05 мс". Когато времето се измерва в микросекунди — о, нищо особено, но когато вече говорим за [мили]секунди — при "разпределяне" на ресурсите по възлите на плана, трябва да вземем предвид тези данни за "колко кой е изразходвал".

Вторият момент, по-сложен, е разпределението на ресурсите (тези буфери) по динамичните възли. Това ни отне допълнителни 4 седмици през първите 2 седмици на прототипа.

Да получим подобен проблем е достатъчно просто — правим CTE и в нея нещо уж четем. Всъщност, PostgreSQL е "умен" и не ще чете нищо там директно. Следователно, взимаме първия запис от нея, а към него — стотния от същата CTE.

Гледаме плана и разбираме — странно, имаме 3 буфера (данни) били "изразходвани" в Seq Scan, още 1 в CTE Scan, и още 2 в втория CTE Scan. Тоест, ако всичко просто сумарираме, получаваме 6, но от табличката сме прочели само 3! CTE Scan всъщност не чете нищо отникъде, а работи направо с паметта на процеса. Ясно е, че нещо не е наред тук!

Всъщност, става така, че всичките 3 страници данни, които са били поискани от Seq Scan, първо 1 е поискал от 1-вия CTE Scan, а след това 2-рия, и за него са дочитали още 2. Тоест, всъщност са били прочетени 3 страници данни, а не 6.

Тази картина ни доведе до разбирането, че изпълнението на плана вече не е дърво, а просто някакъв ацикличен граф. И получихме приблизително такава диаграма, за да разберем "откъде какво е дошло". Тоест, тук създадохме CTE от pg_class и два пъти я поискахме, и почти всичкото време ни отне по клон, когато я поискахме 2-ри път. Ясно е, че прочитането на 101-ия запис е много по-скъпо, отколкото просто 1-ия от таблицата.

Ние за момент си поехме дъх. Казахме: "Сега, Нео, знаеш кунг-фу! Сега нашият опит е пред теб на екрана. Сега можеш да го използваш." [статия]

Консолидиране на логовете

Нашите 1000 разработчици облекчено дишаха. Но ние знаехме, че имаме само стотици "бойни" сървъри, и всичкото това "копи-пейст" от страна на разработчиците не беше удобно. Осъзнахме, че трябва да го съберем сами.

Всъщност, има вграден модул, който е способен да събира статистика, но също така трябва да бъде активиран в конфигурацията — това е модулът pg_stat_statements. Но той не ни удовлетворяваше.

Първо, същите заявки по различни схеми в рамките на една база данни получават различни QueryId. Тоест, ако първо изпълним SET search_path = '01'; SELECT * FROM user LIMIT 1;, а после SET search_path = '02'; и такава съща заявка, то в статистиката на този модул ще има различни записки, и аз няма да мога да събера обща статистика именно по профила на тази заявка, без да взимам предвид схемите.

Вторият момент, който ни попречи да го използваме — липсата на планове. Тоест, планът липсва, има само самата заявка. Виждаме какво е забавило, но не разбираме защо. И тук се връщаме към проблема с бързо променящите се данни.

И последният момент — липсата на "факти". Тоест не може да се адресираме към конкретен екземпляр на изпълнението на заявката — такъв няма, има само агрегирана статистика. С това макар и може да се работи, е много трудно.

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

Колекторът се подключва по SSH, "надежда" с помощта на сертификат защитено съединение до сървъра с базата данни и tail -F "захваща" логфайла. По този начин, в тази сесия получаваме пълно "огледало" на целия лог-файл, който генерира сървърът. Натоварването на самия сървър при това е минимално, тъй като не парсваме нищо, просто отразяваме трафика.

Тъй като вече започнахме да пишем интерфейса на Node.js, така продължихме да пишем и колектора. И тази технология се оправда, защото за работа с неформатирани текстови данни, каквито са логовете, използването на JavaScript е много удобно. А самата инфраструктура на Node.js като платформа за бекенд позволява лесно и удобно работа с мрежови съединения и въобще с каквито и да е потоци данни.

Съответно, ние "поддържаме" две свързания: първото, за да "слушаме" самия лог и да го импортираме, а второто — за да питаме базата периодично. "А ето в лога дойде, че е блокирана таблицата с oid 123", но на разработчика това не му казва нищо, и би било добре да попитаме базата "А какво наистина е OID = 123?" И така периодично питаме базата за това, което все още не знаем.

"Само едно не си взел под внимание, има вид слоноподобни пчели!.." Започнахме да разработваме тази система, когато искахме да мониторим 10 сървъра. Най-критичните според нас, на които имаше някакви проблеми, с които беше трудно да се справим. Но през първото тримесечие получихме за мониторинг стотина — защото системата "влезе", всички я поискаха, на всички беше удобно.

Всичко това трябва да се събира, потокът от данни е голям и активен. Всъщност, какво мониторим, с каквото можем да се справим — това и използваме. Използваме PostgreSQL и като хранилище на данни. А нищо по-бързо за "изливане" на данни в него, отколкото оператор COPY все още няма.

Но просто "изливане" на данни не е съвсем нашата технология. Защото ако на сто сървъра се случват около 50k запитвания в секунда, то това генерира 100-150GB логове на ден. Затова ни се наложи внимателно да "обработваме" базата.

На първо място, направихме разделение по дни, защото, по същество, никого не интересува корелацията между дните. Какво значение има какво си имал вчера, ако тази нощ си пуснал нова версия на приложението — и вече имаш нова статистика.

На второ място, научихме се (бяхме принудени) много-много бързо да пишем с помощта на COPY. Тоест не просто COPY, защото той е по-бърз от INSERT, а още по-бърз.

Третият момент — трябваше да се откажем от тригери, съответно и от Foreign Keys. Тоест, нямаме изобщо референтна цялост. Защото ако имате таблица, на която има двойка FK, и казвате в структурата на БД, че "ето записа от лога се отнася по FK, например, на група записи", то когато я вмъквате, PostgreSQL няма друга възможност, освен да вземе и честно да изпълни SELECT 1 FROM master_fk1_table WHERE ... с идентификатора, който опитвате да вмъкнете — просто за да проверите, че този запис там присъства, че не "разрушавате" Foreign Key с вашето вмъкване.

Получаваме вместо една запис в целевата таблица и индексирането ѝ, допълнително четене от всички таблици, на които тя се препраща. А ние не се нуждаем от това — задачата ни е да запишем възможно най-много и най-бързо с най-малко натоварване. Така че FK — да се махне!

Следващият момент — агрегацията и хеширането. Първоначално те бяха реализирани в базата данни — защото е удобно веднага, когато записа дойде, да се направи нещо в някоя таблица „плюс едно“ направо в тригера. Добре, удобно, но лошо с това — вмъквате един запис, а сте принудени да прочетете и запишете нещо друго от друга таблица. И не само че трябва да прочетете и запишете — трябва да го правите всеки път.

А сега си представете, че имате таблица, в която просто броите броя на заявките, преминали през конкретен хост: +1, +1, +1, ..., +1. А всъщност не ви е необходимо — всичко това може да се обобщи в паметта на колектора и да се изпрати в базата за един път +10.

Да, в случай на някакви проблеми може да се "развали" логическата цялост, но това е практически нереален случай — защото имате нормален сървър, на него има батерия в контролера, имате журнал на транзакции, журнал на файловата система… В крайна сметка, не си заслужава. Не си заслужава загубата на производителност, която получавате за сметка на работата на тригерите/FK, тези разходи, които носите.

Същото важи и за хеширането. Постъпва ви някаква заявка, изчислявате в БД някакъв идентификатор, записвате в базата и после казвате на всички него. Всичко е хубаво, докато в момента на записа не дойде втори желаещ да запише същото — и ще получите блокировка, а това вече е лошо. Затова, ако можете да изнесете генерирането на някакви ID на клиента (относно базата), по-добре е да го направите.

Идеално ни подхожда да използваме MD5 от текста — заявката, плана, шаблона,… Изчисляваме го на страната на колектора и "наливаме" в базата готовия ID. Дължината на MD5 и ежедневно секциониране ни позволяват да не се тревожим за възможни колизии.

Но за да запишем всичко това бързо, трябваше да модифицираме самата процедура на записа.

Как обикновено се записват данните? Имаме някакъв набор от данни, разлагаме го на няколко таблици, а после COPY — първо в първата, после във втората, в третата… Неудобно е, защото изглежда, че записваме един поток от данни на три стъпки последователно. Не е приятно. Може ли да стане по-бързо? Може!

За това е достатъчно само да разположим тези потоци паралелно един до друг. Така че имаме отделни потоци с грешки, заявки, шаблони, блокировки,… — и записваме всичко паралелно. За това е достатъчно да поддържаме постоянно отворен COPY-канал за всяка отделна целева таблица.

Тоест събирачът винаги има стрийм, в който мога да запиша нужните ми данни. Но за да види базата тези данни, а някой да не е блокиран, очаквайки записването им, COPY трябва да се прекъсва с определена периодичност. За нас най-ефективният период се оказа около 100ms — затваряме и веднага отново отваряме на същата таблица. А ако в някакви пикове недостатъчно течение, правим пул до определен предел.

Допълнително установихме, че за такъв профил на натоварване всяка агрегация, при която записите се събират в пакети — е зло. Класическото зло е INSERT ... VALUES и след това 1000 записа. Защото в този момент възниква пик на запис по носителя, и всички останали, които се опитват да записват на диска, ще чакат.

За да се избегнат такива аномалии, просто не агрегирайте нищо, не буферизирайте изобщо. И ако все пак възникне буферизация на диска (за щастие, Stream API в Node.js позволява да се установи това) — отложете това свързване. Ето когато получите съобщение, че отново е свободно — записвайте в него от натрупаната опашка. А докато е заето — вземете следващото, свободно от пула, и записвайте в него.

До внедряването на такъв подход за запис на данни имахме около 4K write ops, а по този начин намалихме натоварването с 4 пъти. Сега сме увеличили натоварването още 6 пъти благодарение на новите наблюдавани бази — до 100MB/s. И сега съхраняваме логове за последните 3 месеца с обем около 10-15TB, надеейки се, че за три месеца всеки разработчик може да реши всяка проблема.

Разбираме проблемите

Но просто събиране на всички тези данни е добре, полезно и уместно, но недостатъчно — трябва да ги разберем. Защото става въпрос за милиони различни планове на ден.

Но милионите са непосилни, първо трябва да направим "по-малко". И на първо място, трябва да решим как точно ще организираме това "по-малко".

Определихме три основни момента за себе си:

• кой този запит е изпратен от
  Т.е. от кое приложение е "пристигнал": уеб-интерфейс, бекенд, платежна система или нещо друго.
• където това се е случило
  На кой конкретен сървър. Защото ако под едно приложение имате няколко сървъра и изведнъж един "забави" (поради "гниене на диска", "протичане на паметта" или друга беда), трябва да адресирате конкретно до сървъра.
• как проблемът се е проявил в конкретен план

За да разберем "кой" ни е изпратил запитването, използваме стандартен инструмент — задаваме променлива на сесията: SET application_name = '{bl-host}:{bl-method}'; — получаваме името на хоста на бизнес логиката, от който идва запитването, и името на метода или приложението, което го е инициирало.

След като предадем "хозяина" на запитването, трябва да го изведем в лог — за това конфигурираме променливата log_line_prefix = ' %m [%p:%v] [%d] %r %a'. Който се интересува, може да погледне в ръководството, какво означава всичко това. Получава се, че в лога виждаме:

• времето
• идентификаторите на процеса и транзакцията
• името на базата
• IP адреса на този, който е изпратил запитването
• и името на метода

След това разбрахме, че не е много интересно да се наблюдава корелацията на едно запитване между различни сървъри. Не често се случва ситуация, в която едно приложение да "греши" еднакво и тук, и там. Но дори и да е така — погледнете на всеки от тези сървъри.

Така че, разреза "един сървър — един ден" се оказа достатъчен за всякакъв анализ.

Първият аналитичен разрез — това е същият "шаблон" — съкратена форма на представяне на плана, очиствана от всички числови показатели. Вторият разрез — приложението или метода, а третият — конкретният възел на плана, който е предизвикал проблемите.

Когато преминахме от конкретни екземпляри към шаблони, получихме веднага две предимства:

• значително намаляване на броя на обектите за анализ
  Вече не разглеждаме проблема по хиляди запитвания или планове, а по десетки шаблони.
• хронология
  И така, обобщавайки "фактите" в конкретен контекст, можем да отразим тяхното появление през деня. Тук можете да разберете, че ако имате някакъв шаблон, който се състоява например веднъж на час, а трябва да бъде веднъж на ден, струва си да се замислите какво не е наред — кой и защо го е задействал, може би той не трябва да бъде тук. Това е още един нечислов, чисто визуален, начин за анализ.

Другите методи са базирани на показателите, които извличаме от плана: колко пъти е настъпил такъв шаблон, общото и средното време, колко данни са изчетени от диска и колко от паметта...

Защото, например, влизате на страницата за анализ на хост, гледате — нещо е започнало да чете твърде много от диска. Дискът на сървъра не се справя — а кой чете от него?

И можете да сортирате по всяка колона и да решите с какво да се занимавате в момента — с натоварването на процесора или на диска, или с общия брой заявки... Сортирали сте, погледнали сте "топовите", поправили сте — пуснали сте нова версия на приложението.
[видеолекция]

И веднага можете да видите различни приложения, които работят с един и същи шаблон от запитването тип SELECT * FROM users WHERE login = 'Vasya'. Фронтенд, бекенд, процесинг... И започвате да се питате, защо на процесинга му е нужно да чете потребителя, ако не взаимодейства с него.

Обратният подход е веднага да видите какво прави приложението. Например, фронтендът — това, това, онова, а още и това веднъж на час (тъкмо таймлайнът помага). И веднага възниква въпросът — изглежда, че не е работа на фронтенда да прави нещо веднъж на час...

След известно време разбрахме, че ни липсва агрегираната статистика по възли на плана. Извлякохме само тези възли от плановете, които извършват нещо с данните на самите таблици (чета\/пиша ги по индекс или не). Всъщност, в сравнение с предишната картина, се добавя само един аспект — колко записа този възел ни е донесъл, а колко е отхвърлил (Rows Removed by Filter).

Нямате подходящ индекс на таблицата, правите запитване към нея, то минава покрай индекса, попада в Seq Scan... всички записи, с изключение на един, сте отфилтрирали. А защо ви трябват 100M отфилтрирани записи за ден, не е ли по-добре да сложите индекс?

След като разгледахме всички планове за възли, осъзнахме, че има определени типични структури в плановете, които с много голяма вероятност изглеждат подозрително. И не би било лошо да подскажем на разработчика: "Ти първо четеш по индекса, после сортиране, а след това отрязваш" — обикновено там има само една запис.

Всички, които са писали заявки с такъв патерн, със сигурност са се сблъсквали: "Дай ми последната поръчка за Васил, датата ѝ". И ако нямате индекс по дата, или в използвания индекс няма дата, точно на такива "грабли" ще стъпите.

Но ние знаем, че това са "грабли" — защо да не подскажем направо на разработчика какво трябва да направи. В резултат, отваряйки сега плана, нашият разработчик веднага вижда красива картинка с подсказки, където му говорят: "Имаш проблеми тук и тук, а те се решават така и така."

В резултат, обемът на опита, необходим за решаване на проблеми в началото и сега, е паднал многократно. Такъв инструмент създадохме.

Източник: habr.com