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

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

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

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


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

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

Като цяло "Тензор" за милион наши клиенти е VLSI - нашето приложение: корпоративна социална мрежа, решения за видеокомуникации, за вътрешно и външно управление на документи, счетоводни системи за счетоводство и склад, ... Тоест един такъв "мегакомбинат" за интегрирано управление на бизнеса, в който има повече от 100 различни вътрешни проекта .

За да работят и да се развиват всички те нормално, ние имаме 10 развойни центъра в цялата страна, те имат още 1000 разработчици.

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

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

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

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

Като цяло, с какви класически проблеми обикновено идва разработчикът [към DBA]? „Тук изпълнихме искането и ние сме бавни, всичко виси, нещо се случва ... Някаква неприятност!

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

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

Вземете план

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

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

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

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

Лоша точка: когато го изпълните, това се случва "тук и сега", така че е подходящо само за локално отстраняване на грешки. Ако вземете някой силно натоварен сървър, който е под силен поток от промени на данни, и видите: „Хей! Тук бавно се представихмеСя искане." Преди половин час, един час - докато изпълнявахте и получавахте тази заявка от регистрационните файлове, пренасяйки я обратно на сървъра, целият ви набор от данни и статистика се промениха. Стартирате го за отстраняване на грешки - и той работи бързо! И не можете да разберете "защо", защо беше бавно.

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

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

Сега всичко изглежда наред, отиваме до дневника и виждаме там ... [кърпа за крака от текст]. Но не можем да кажем нищо за него, освен факта, че това е отличен план, тъй като завършването му отне 11 милисекунди.

Всичко изглежда наред - но нищо не е ясно какво всъщност се е случило. В допълнение към общото време не виждаме нищо особено. Защото гледането на такъв "нахалник" в обикновен текст е общо взето очарователно.

Но дори и да не е очевидно, дори и да е неудобно, има по-фундаментални проблеми:

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

В такива ситуации разбирайте „Кой е най-слабото звено?“ практически нереалистично. Следователно дори самите разработчици в "ръководството" пишат това „Разбирането на плана е изкуство, което трябва да се научи, опит...“.

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

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

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

Първо отидохме „на пазара“ - нека да потърсим в Интернет какво общо съществува.

Но се оказа, че има много малко относително „живи“ решения, които са повече или по-малко разработени - буквално едно нещо: обясни.depesz.com от Хуберт Любачевски. На входа на полето „подайте“ текстовото представяне на плана, то ви показва табела с анализирани данни:

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

Освен това тази услуга има възможност за споделяне на архив от връзки. Хвърлихте плана си там и казахте: „Хей, Вася, ето линк за теб, нещо не е наред“.

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

Първо, огромно количество "copy-paste". Взимате парче от дънера, поставяте го там и отново, и отново.

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

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

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

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

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

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

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

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

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

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

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

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

Естествено, без "рейка" не можеше да направи.

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

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

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

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

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

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

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

Консолидация на регистрационни файлове

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

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

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

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

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

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

Колекторът се свързва чрез SSH, „дърпа“ защитена връзка към сървъра с базата данни с помощта на сертификат и tail -F "прилепва" към него в лог файла. Така че в тази сесия получаваме пълно "огледало" на целия лог файл, който се генерира от сървъра. В същото време натоварването на самия сървър е минимално, защото ние не анализираме нищо там, просто отразяваме трафика.

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

Съответно „разтягаме“ две връзки: първата, за да „слушаме“ самия дневник и да го вземем при себе си, а втората, за да питаме периодично базата. „Но в дневника се появи, че таблетът с oid 123 е блокиран“, но това не означава нищо за разработчика и би било хубаво да попитате базата „Какво е OID = 123 все пак?“ И така периодично питаме базата какво още не знаем.

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

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

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

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

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

Третият момент – трябваше отказват задействания, съответно, и от външни ключове. Тоест, ние изобщо нямаме референтна цялост. Защото, ако имате таблица, която има чифт FK върху нея, и кажете в структурата на базата данни, че "ето запис в журнала, препратен от FK, например към група записи", тогава, когато го вмъкнете, PostgreSQL не му остава нищо друго освен как да вземе и честно да изпълни SELECT 1 FROM master_fk1_table WHERE ... с идентификатора, който се опитвате да вмъкнете - само за да проверите дали този запис присъства там, че не "отчупвате" този чужд ключ с вмъкването си.

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

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

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

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

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

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

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

Как обикновено се записват данните? Имаме някакъв набор от данни, разлагаме го на няколко таблици и след това КОПИРАМЕ - първо в първата, след това във втората, в третата ... Неудобно е, защото изглежда, че пишем един поток от данни в три стъпки последователно . неприятно. Може ли да стане по-бързо? Мога!

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

Тоест колекционерът винаги има поток, в който мога да запиша необходимите ми данни. Но за да може базата данни да види тези данни и някой да не виси в ключалки, чакайки тези данни да бъдат записани, КОПИРАНЕТО трябва да се прекъсва на определени интервали. При нас периодът от около 100ms се оказа най-ефективен - затваряме го и веднага го отваряме отново на същата маса. И ако нямаме достатъчно от един поток при някои пикове, тогава правим обединяване до определен лимит.

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

За да се отървете от подобни аномалии, просто не събирайте нищо, изобщо не буферирайте. И ако се случи буфериране към диск (за щастие 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'. Frontend, backend, processing... И се чудите защо обработката трябва да чете потребителя, ако той не взаимодейства с него.

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

След известно време разбрахме, че ни липсва агрегат статистики по планови възли. Ние сме изолирали от плановете само онези възли, които правят нещо с данните от самите таблици (ги четат/записват по индекс или не). Всъщност по отношение на предишната снимка е добавен само един аспект - колко записа ни донесе този възели колко е отхвърлено (Редове, премахнати от филтъра).

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

След като анализирахме всички планове по възли, разбрахме, че има някои типични структури в плановете, които най-вероятно изглеждат подозрителни. И би било хубаво да кажете на разработчика: „Приятелю, тук първо четете по индекс, след това сортирате и след това отрязвате“ - като правило има един запис.

Всеки, който пише заявки, вероятно е срещал такъв модел: „Дайте ми последната поръчка за Вася, нейната дата.“ И ако нямате индекс по дата или няма дата в индекса, който сте използвали, тогава стъпете на точно такъв „рейк“ .

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

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

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