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

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

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

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


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

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

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

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

С PostgreSQL работим от 2008 година и сме натрупали голям обем от данни - клиентски, статистически, аналитични, данни от външни информационни системи - повече от 400TB.Само в ‘продукция’ имаме около 250 сървъра, а общо бази данни, които следим - около 1000.

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

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

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

Общо взето, с какви класически проблеми обикновено идва разработчикът [к DBA]? „Изпълнихме заявка и всичко е бавно, всичко е замръзнало, нещо се случва… Каква беда!“

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

• неефективен алгоритъм на заявката
  Разработчик: „Сега в SQL имам 10 таблици чрез JOIN…“ — и очаква, че условията му магически ще се „развържат“ и той ще получи всичко бързо. Но чудеса не се случват и всяка система при такава вариативност (10 таблици в един FROM) винаги дава някаква неточност. [статия]
• неактуална статистика
  Т Momentът е много актуален именно за 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 от Хуберт Лукачевски. На входа в полето „вкарваш“ текстово представление на плана, той ти показва таблица с анализирани данни:

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

Също така този сервиз има възможност да споделя архив от линкове. Кинуваш там своя план и казваш: „Ей, Васе, ето ти линка, там нещо не е наред.“

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

Първо, огромно количество „копипаста“. Взимаш парче лог, слагаш го там, отново и отново.

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

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

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

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

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

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

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

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

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

Какво още би било удобно? Би било удобно да виждаме каква част от общото време се разпределя на кой възел – и просто добавихме отстрани pie chart.

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

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

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

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

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

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

Гледаме плана и разбираме — странно, 3 buffers (страници данни) бяха "потребени" в 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 ... с идентификатора, който се опитвате да вмъкнете - просто, за да проверите, че този запис присъства, че не „разрушавате“ референтния ключ с вашето вмъкване.

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

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

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

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

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

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

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

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

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

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

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

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

До внедряването на такъв подход за запис на данни имахме около 4K операции за запис, а по този начин намалихме натоварването 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