Алексей Лесовскийдің 2015 жылғы «PostgreSQL ішкі статистикасына терең бойлау» баяндамасының транскрипциясы
Баяндама авторынан бас тарту: Бұл есептің 2015 жылдың қараша айына арналғанын ескертемін – 4 жылдан астам уақыт өтті және көп уақыт өтті. Есепте талқыланған 9.4 нұсқасына енді қолдау көрсетілмейді. Соңғы 4 жылда 5 жаңа шығарылым шығарылды, онда статистикаға қатысты көптеген жаңалықтар, жақсартулар мен өзгерістер бар, ал кейбір материалдар ескірген және өзекті емес. Шолу барысында оқырманды адастырмас үшін осы жерлерді белгілеуге тырыстым. Мен бұл үзінділерді қайта жазған жоқпын, олар өте көп және нәтиже мүлдем басқа есеп болады.
PostgreSQL ДҚБЖ үлкен механизм болып табылады және бұл механизм көптеген ішкі жүйелерден тұрады, олардың үйлестірілген жұмысы ДҚБЖ өнімділігіне тікелей әсер етеді. Жұмыс барысында PostgreSQL тиімділігін бағалауға және өнімділікті жақсарту бойынша шаралар қабылдауға мүмкіндік беретін компоненттердің жұмысы туралы статистика мен ақпарат жиналады. Дегенмен, бұл ақпарат өте көп және ол айтарлықтай жеңілдетілген түрде ұсынылған. Бұл ақпаратты өңдеу және оны түсіндіру кейде мүлдем тривиальды емес тапсырма болып табылады және құралдар мен утилиталардың «хайуанаттар бағы» тіпті жетілдірілген DBA-ны оңай шатастыруы мүмкін.
Қайырлы күн! Менің атым Алексей. Илья айтқандай, мен PostgreSQL статистикасы туралы айтатын боламын.
PostgreSQL белсенділік статистикасы. PostgreSQL-де екі статистика бар. Талқыланатын қызмет статистикасы. Және деректерді тарату туралы жоспарлаушы статистикасы. Мен өнімділікті бағалауға және оны қандай да бір жолмен жақсартуға мүмкіндік беретін PostgreSQL белсенділік статистикасы туралы арнайы айтатын боламын.
Мен сізде бар немесе болуы мүмкін әртүрлі мәселелерді шешу үшін статистиканы қалай тиімді пайдалану керектігін айтамын.
Есепте не болмайды? Есепте мен жоспарлаушы статистикасына тоқталмаймын, өйткені... Бұл деректердің дерекқорда қалай сақталатыны және сұрауды жоспарлаушы осы деректердің сапалық және сандық сипаттамалары туралы түсінікті қалай алатыны туралы жеке есеп үшін бөлек тақырып.
Және ешқандай құралға шолулар болмайды, мен бір өнімді екіншісімен салыстырмаймын. Жарнама болмайды. Мұны бір жаққа қояйық.
Мен сізге статистиканы пайдалану пайдалы екенін көрсеткім келеді. Бұл қажетті. Оны пайдалану қауіпсіз. Бізге тек тұрақты SQL және SQL бойынша негізгі білім қажет.
Мәселені шешу үшін қандай статистиканы таңдау керектігі туралы сөйлесейік.
Егер PostgreSQL-ге қарасақ және процестерді көру үшін операциялық жүйеде пәрменді іске қоссақ, біз «қара жәшік» көреміз. Біз бірдеңе істеп жатқан кейбір процестерді көреміз және атаудан олардың онда не істеп жатқанын, не істеп жатқанын шамамен елестете аламыз. Бірақ, шын мәнінде, бұл қара жәшік, біз оның ішіне қарай алмаймыз.
Біз CPU жүктемесін көре аламыз top, біз кейбір жүйелік утилиталардың жадты пайдалануын қарай аламыз, бірақ PostgreSQL ішіне қарай алмаймыз. Ол үшін бізге басқа құралдар қажет.
Әрі қарай жалғастыра отырып, мен сізге уақыттың қайда жұмсалатынын айтамын. Егер PostgreSQL-ті осындай диаграмма түрінде елестететін болсақ, онда уақыттың қайда кеткеніне жауап бере аламыз. Бұл екі нәрсе: ол қолданбалардан келген клиенттік сұрауларды өңдеу және PostgreSQL жұмыс істеп тұру үшін орындайтын фондық тапсырмалар.
Жоғарғы сол жақ бұрышқа қарай бастасақ, клиент сұрауларының қалай өңделетінін көре аламыз. Сұраныс қолданбадан келеді және одан әрі жұмыс үшін клиент сеансы ашылады. Сұраныс жоспарлаушыға жіберіледі. Жоспарлаушы сұрау жоспарын құрады. Оны әрі қарай орындауға жібереді. Кестелер мен индекстермен байланысты деректерді енгізу/шығару блоктарының қандай да бір түрі бар. Қажетті мәліметтер дискілерден жадқа арнайы «ортақ буферлер» аймағына оқылады. Сұраныс нәтижелері, егер олар жаңартулар, жоюлар болса, WAL транзакциялар журналында жазылады. Кейбір статистикалық ақпарат журналда немесе статистикалық коллекторда аяқталады. Ал сұраныстың нәтижесі клиентке кері жіберіледі. Осыдан кейін клиент жаңа сұраныспен бәрін қайталай алады.
Фондық тапсырмалар мен фондық процестер туралы не деуге болады? Бізде дерекқорды қалыпты жұмыс режимінде ұстап тұратын бірнеше процестер бар. Есепте бұл процестер де қозғалады: автовакуум, бақылаушы, репликацияға қатысты процестер, фондық жазушы. Олардың әрқайсысына есеп беру барысында тоқталамын.
Статистикаға қатысты қандай мәселелер бар?
- Ақпарат өте көп. PostgreSQL 9.4 статистикалық деректерді көру үшін 109 көрсеткішті қамтамасыз етеді. Дегенмен, егер дерекқорда көптеген кестелер, схемалар, дерекқорлар сақталса, онда бұл көрсеткіштердің барлығын кестелердің, дерекқорлардың сәйкес санына көбейту керек болады. Яғни, одан да көп ақпарат бар. Ал оған батып кету өте оңай.
- Келесі мәселе - статистика есептегіштермен көрсетіледі. Егер біз осы статистикаға қарасақ, біз үнемі өсіп келе жатқан есептегіштерді көреміз. Ал егер статистика қалпына келтірілгеннен бері көп уақыт өтсе, біз миллиардтаған мәндерді көреміз. Және олар бізге ештеңе айтпайды.
- Әңгіме жоқ. Егер сізде қандай да бір сәтсіздік болса, 15-30 минут бұрын бірдеңе құлап кетсе, сіз статистиканы пайдалана алмайсыз және 15-30 минут бұрын не болғанын көре алмайсыз. Бұл мәселе.
- PostgreSQL-де орнатылған құралдың болмауы мәселе болып табылады. Ядро әзірлеушілер ешқандай қызметтік бағдарламаны қамтамасыз етпейді. Оларда ондай ештеңе жоқ. Олар жай ғана деректер базасында статистиканы береді. Оны қолданыңыз, оған өтініш жасаңыз, қалағаныңызды жасаңыз.
- PostgreSQL-де ешқандай құрал жоқ болғандықтан, бұл басқа мәселені тудырады. Көптеген үшінші тарап құралдары. Азды-көпті тікелей қолдары бар әрбір компания өз бағдарламасын жазуға тырысады. Нәтижесінде, қауымдастықта статистикамен жұмыс істеуге болатын көптеген құралдар бар. Ал кейбір құралдардың белгілі бір мүмкіндіктері бар, басқа құралдардың басқа мүмкіндіктері жоқ немесе кейбір жаңа мүмкіндіктер бар. Және бір-бірімен қабаттасатын және әртүрлі қызметтері бар екі, үш немесе төрт құралдарды пайдалану қажет болатын жағдай туындайды. Бұл өте жағымсыз.
Бұдан не шығады? Бағдарламаларға тәуелді болмау үшін немесе бұл бағдарламаларды өзіңіз жетілдірмеу үшін тікелей статистиканы ала білу маңызды: өз пайдаңызды алу үшін кейбір функцияларды қосыңыз.
Және сізге SQL бойынша негізгі білім қажет. Статистикадан кейбір деректерді алу үшін сізге SQL сұрауларын жасау керек, яғни таңдау және біріктіру қалай құрастырылатынын білу керек.
Статистика бізге бірнеше нәрсені айтады. Оларды санаттарға бөлуге болады.
- Бірінші категория – дерекқорда орын алатын оқиғалар. Бұл дерекқорда қандай да бір оқиға орын алған кезде: сұрау, кестеге кіру, автовакуум, орындау, содан кейін бұл барлық оқиғалар. Осы оқиғаларға сәйкес есептегіштер көбейтіледі. Және біз бұл оқиғаларды бақылай аламыз.
- Екінші категория - кестелер мен деректер қоры сияқты объектілердің қасиеттері. Олардың қасиеттері бар. Бұл кестелердің өлшемі. Біз кестелердің өсуін және индекстердің өсуін бақылай аламыз. Біз динамикадағы өзгерістерді байқаймыз.
- Ал үшінші категория – іс-шараға кететін уақыт. Өтініш - бұл оқиға. Оның өзіндік ұзақтық өлшемі бар. Мұнда басталды, осында аяқталды. Біз оны қадағалай аламыз. Блокты дискіден оқуға немесе оны жазуға кететін уақыт. Мұндай жайттар да бақыланады.
Статистика көздері келесідей ұсынылған:
- Ортақ жадта (ортақ буферлерде) статикалық деректерді сақтауға арналған сегмент бар, сонымен қатар белгілі бір оқиғалар орын алған кезде немесе деректер қорының жұмысында кейбір сәттер туындаған кезде үнемі ұлғайтылатын есептегіштер бар.
- Бұл есептегіштердің барлығы пайдаланушыға қол жетімді емес, тіпті әкімшіге де қол жетімді емес. Бұл төмен деңгейдегі заттар. Оларға қол жеткізу үшін PostgreSQL SQL функциялары түріндегі интерфейсті ұсынады. Біз осы функцияларды пайдаланып таңдаулы лақтырулар жасай аламыз және қандай да бір метрика (немесе көрсеткіштер жиынтығы) аламыз.
- Дегенмен, бұл функцияларды пайдалану әрқашан ыңғайлы бола бермейді, сондықтан функциялар көріністердің (VIEWs) негізі болып табылады. Бұл белгілі бір ішкі жүйе бойынша немесе дерекқордағы оқиғалардың белгілі жиыны бойынша статистиканы қамтамасыз ететін виртуалды кестелер.
- Бұл ендірілген көріністер (КӨРІНІСТЕР) статистикамен жұмыс істеуге арналған негізгі пайдаланушы интерфейсі болып табылады. Олар әдепкі бойынша ешқандай қосымша параметрлерсіз қол жетімді, оларды бірден пайдалануға, қарауға және олардан ақпарат алуға болады. Сосын үлестері бар. Салымдар ресми болып табылады. Сіз postgresql-contrib бумасын (мысалы, postgresql94-contrib) орната аласыз, конфигурацияға қажетті модульді жүктей аласыз, оның параметрлерін көрсете аласыз, PostgreSQL-ді қайта іске қосып, оны пайдалана аласыз. (Ескерту. Таратуға байланысты соңғы нұсқаларда үлес пакеті негізгі буманың бөлігі болып табылады).
- Ал бейресми салымдар бар. Олар стандартты PostgreSQL дистрибутивіне кірмейді. Олар жинақталуы немесе кітапхана ретінде орнатылуы керек. Бұл бейресми үлесті әзірлеуші не ойлап тапқанына байланысты опциялар әртүрлі болуы мүмкін.
Бұл слайдта PostgreSQL 9.4 нұсқасында қол жетімді барлық КӨРІНІСТЕР мен кейбір функциялар берілген. Көріп отырғанымыздай, олардың саны өте көп. Егер сіз оны бірінші рет кездестірсеңіз, шатасу оңай.
Дегенмен, егер біз алдыңғы суретті алсақ Как тратится время на PostgreSQL және осы тізіммен үйлесімді, біз бұл суретті аламыз. PostgreSQL іске қосылған кезде сәйкес статистиканы алу үшін біз әрбір көріністі (КӨРІНІСТЕР) немесе әрбір функцияны бір немесе басқа мақсатта пайдалана аламыз. Ал біз ішкі жүйенің жұмысы туралы біраз ақпарат ала аламыз.
Біз қарастыратын бірінші нәрсе pg_stat_database. Көріп отырғанымыздай, бұл спектакль. Онда көптеген ақпарат бар. Ең әртүрлі ақпарат. Бұл біздің дерекқорымызда не болып жатқаны туралы өте пайдалы білім береді.
Ол жерден қандай пайдалы заттарды аламыз? Ең қарапайым нәрселерден бастайық.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;Біз қарастыратын бірінші нәрсе - кэшке кіру пайызы. Кэшті ұру жылдамдығы пайдалы көрсеткіш болып табылады. Бұл ортақ буфер кэшінен қанша деректер алынғанын және дискіден қанша оқылатынын бағалауға мүмкіндік береді.
Бұл анық бізде кэш хиттері неғұрлым көп болса, соғұрлым жақсы. Біз бұл көрсеткішті пайызбен өлшейміз. Және, мысалы, егер біздің кэш хиттерінің пайызы 90% -дан асса, бұл жақсы. Егер ол 90%-дан төмен түссе, бұл деректердің ыстық басын жадта ұстауға жеткілікті жадымыз жоқ дегенді білдіреді. Бұл деректерді пайдалану үшін PostgreSQL дискіге кіруге мәжбүр және бұл деректер жадтан оқылғанға қарағанда баяуырақ. Сіз жадты ұлғайту туралы ойлануыңыз керек: ортақ буферлерді көбейтіңіз немесе аппараттық жадты (RAM) көбейтіңіз.
select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;Бұл спектакльден тағы не ала аласыз? Дерекқорда орын алған ауытқуларды көре аласыз. Мұнда не көрсетілген? Міндеттемелер, кері қайтарулар, уақытша файлдарды жасау, олардың өлшемі, тығырықтанулар және қақтығыстар бар.
Біз бұл сұрауды пайдалана аламыз. Бұл SQL өте қарапайым. Ал біз бұл деректерді осы жерден қарай аламыз.
Міне, шекті мәндер. Біз міндеттемелер мен кері қайтарулардың арақатынасын қарастырамыз. Міндеттемелер – транзакцияның сәтті растауы. Кері қайтарулар - бұл кері қайтару, яғни транзакция біраз жұмыс жасады, дерекқорды шиелендірді, бірдеңені есептеді, содан кейін сәтсіздік орын алды және транзакция нәтижелері жойылады. Бұл үнемі өсіп келе жатқан кері қайтарулар саны нашар. Сіз қандай да бір жолмен олардан аулақ болуыңыз керек және бұл болмас үшін кодты өңдеңіз.
Қайшылықтар репликациямен байланысты. Және олардан аулақ болу керек. Егер сізде репликада орындалатын кейбір сұраулар болса және қайшылықтар туындаса, онда осы қайшылықтарды сұрыптап, не болып жатқанын көру керек. Толық мәліметтерді журналдардан табуға болады. Қолданба сұраулары қатесіз жұмыс істеуі үшін қайшылықты жағдайларды жойыңыз.
Тығырықтанулар да жағымсыз жағдай. Сұраулар ресурстар үшін күресіп жатқанда, бір сұрау бір ресурсқа кіріп, құлыпты алды, екінші сұрау екінші ресурсқа кіріп, құлыпты да алды, содан кейін екі сұрау да бір-бірінің ресурстарына қатынасып, көршінің құлыпты босатуын күту кезінде бұғатталды. Бұл да проблемалық жағдай. Оларды қосымшаларды қайта жазу және ресурстарға қол жеткізуді сериялау деңгейінде шешу қажет. Ал егер сіз тығырықтарыңыз үнемі артып келе жатқанын көрсеңіз, журналдардағы егжей-тегжейлерді қарап, туындаған жағдайларды талдап, мәселенің не екенін көру керек.
Уақытша файлдар (temp_files) да нашар. Пайдаланушы сұрауында жедел, уақытша деректерді орналастыру үшін жады жеткіліксіз болған кезде ол дискіде файл жасайды. Ал жадтағы уақытша буферде орындай алатын барлық операциялар дискіде орындала бастайды. Бұл баяу. Бұл сұрауды орындау уақытын арттырады. Ал PostgreSQL-ке сұрау жіберген клиент сәл кейінірек жауап алады. Егер осы операциялардың барлығы жадта орындалса, Postgres әлдеқайда жылдам жауап береді және клиент аз күтеді.
Pg_stat_bgwriter - Бұл көрініс екі PostgreSQL фондық ішкі жүйелерінің жұмысын сипаттайды: бұл checkpointer и background writer.
Алдымен, бақылау нүктелері деп аталатындарды қарастырайық. checkpoints. Бақылау нүктелері дегеніміз не? Бақылау нүктесі журналда жазылған барлық деректер өзгерістерінің дискідегі деректермен сәтті синхрондалғанын көрсететін транзакция журналындағы орын болып табылады. Жұмыс жүктемесі мен параметрлерге байланысты процесс ұзақ болуы мүмкін және негізінен ортақ буферлердегі лас беттерді дискідегі деректер файлдарымен синхрондаудан тұрады. Ол не үшін? Егер PostgreSQL үнемі дискіге қол жеткізіп, сол жерден деректерді алып отырса және әрбір кіруге деректерді жазып отырса, ол баяу болар еді. Сондықтан PostgreSQL-де өлшемі конфигурациядағы параметрлерге байланысты жад сегменті бар. Postgres кейінірек өңдеу немесе сұрау үшін осы жадта тірі деректерді сақтайды. Деректерді өзгерту туралы сұраулар болған жағдайда, ол өзгертіледі. Ал біз деректердің екі нұсқасын аламыз. Біреуі жадымызда, екіншісі дискіде. Және бұл деректерді мезгіл-мезгіл синхрондау қажет. Жадта өзгерген нәрсені дискіге синхрондау керек. Ол үшін бақылау пункттері қажет.
Бақылау нүктесі ортақ буферлерден өтеді, бақылау нүктесіне қажет лас беттерді белгілейді. Содан кейін ол ортақ буферлер арқылы екінші өтуді іске қосады. Ал бақылау нүктесі үшін белгіленген беттер, ол оларды синхрондауда. Осылайша деректер дискімен синхрондалады.
Бақылау пункттерінің екі түрі бар. Бір бақылау нүктесі күту уақытымен орындалады. Бұл бақылау нүктесі пайдалы және жақсы – checkpoint_timed. Сұраныс бойынша бақылау бекеттері бар - checkpoint required. Бұл бақылау нүктесі бізде өте үлкен деректер жазбасы болған кезде орын алады. Біз көптеген транзакция журналдарын жазып алдық. Ал PostgreSQL мұның барлығын мүмкіндігінше тез синхрондау, бақылау нүктесін жасап, әрі қарай жүру керек деп санайды.
Ал статистикаға қарасаңыз pg_stat_bgwriter және сізде бар нәрсені көрді checkpoint_req checkpoint_timed мәнінен әлдеқайда үлкен болса, бұл нашар. Неге жаман? Бұл PostgreSQL дискіге деректерді жазу қажет болғанда тұрақты күйзеліске ұшырайтынын білдіреді. Тайм-аут бақылау пункті стрессті азырақ және ішкі кестеге сәйкес орындалады және уақыт бойынша таралады. PostgreSQL жұмысты кідіртуге және дискінің ішкі жүйесін ауыртпауға мүмкіндігі бар. Бұл PostgreSQL үшін пайдалы. Бақылау нүктесінде орындалатын сұраулар дискінің ішкі жүйесі бос емес болғандықтан стресске ұшырамайды.
Ал бақылау нүктесін реттеу үшін үш параметр бар:
-
сheckpoint_segments. -
сheckpoint_timeout. -
сheckpoint_competion_target.
Олар басқару пункттерінің жұмысын реттеуге мүмкіндік береді. Бірақ мен оларға тоқталмаймын. Олардың әсері бөлек тақырып.
Ескерту: Есепте талқыланған 9.4 нұсқасы енді өзекті емес. PostgreSQL заманауи нұсқаларында параметр checkpoint_segments параметрлерімен ауыстырылады min_wal_size и max_wal_size.
Келесі ішкі жүйе - фон жазушы - background writer. Ол не істеп жатыр? Ол шексіз циклде үздіксіз жұмыс істейді. Ортақ буфердегі беттерді сканерлейді және дискіге тапқан лас беттерді тастайды. Осылайша, бұл бақылаушыға бақылау нүктесін орындау кезінде аз жұмыс істеуге көмектеседі.
Ол тағы не үшін қажет? Ол деректерді орналастыру үшін кенеттен (үлкен көлемде және бірден) қажет болса, ортақ буферлерде бос беттердің қажеттілігін қамтамасыз етеді. Сұрауды аяқтау үшін бос беттер қажет болған және олар ортақ буферлерде болған жағдай туындады делік. Постгрессивті backend ол оларды жай ғана алып, пайдаланады, ол ештеңені өзі тазалаудың қажеті жоқ. Бірақ кенеттен мұндай беттер болмаса, сервер жұмысын тоқтатады және оларды дискіге түсіріп, өз қажеттіліктері үшін алу үшін беттерді іздей бастайды - бұл қазіргі орындалып жатқан сұраудың уақытына теріс әсер етеді. Егер сізде параметр бар екенін көрсеңіз maxwritten_clean үлкен болса, бұл фондық жазушы өз жұмысын орындамай тұрғанын және параметрлерді арттыру қажет екенін білдіреді bgwriter_lru_maxpages, ол бір циклде көбірек жұмыс жасай алатындай етіп, көбірек беттерді тазалаңыз.
Және тағы бір өте пайдалы көрсеткіш buffers_backend_fsync. Баяу болғандықтан, серверлер синхрондалмайды. Олар IO стек тексеру нүктесін fsync арқылы өткізеді. Бақылау пунктінің өз кезегі бар, ол мерзімді түрде fsync өңдейді және жадтағы беттерді дискідегі файлдармен синхрондайды. Бақылау пунктіндегі кезек үлкен және толық болса, сервер fsync әрекетін өзі орындауға мәжбүр болады және бұл сервер жұмысын баяулатады., яғни клиент жауап мүмкін болғаннан кейінірек алады. Егер сіздің мәніңіз нөлден жоғары екенін көрсеңіз, бұл қазірдің өзінде мәселе және фондық жазушының параметрлеріне назар аудару керек, сонымен қатар дискінің ішкі жүйесінің өнімділігін бағалау керек.
Ескерту: _Келесі мәтін репликациямен байланысты статистикалық көріністерді сипаттайды. Көрініс пен функция атауларының көпшілігі Postgres 10-да қайта аталды. Атын өзгертудің мәні ауыстыру болды. xlog туралы wal и location туралы lsn функцияда/көрініс атауларында және т.б. Ерекше мысал, функция pg_xlog_location_diff() деп өзгертілді pg_wal_lsn_diff()._
Бізде де бұл жерде көп нәрсе бар. Бірақ бізге тек орынға қатысты заттар керек.
Егер біз барлық мәндердің тең екенін көрсек, онда бұл тамаша нұсқа және реплика шеберден артта қалмайды.
Бұл он алтылық позиция транзакция журналындағы орын болып табылады. Мәліметтер базасында қандай да бір әрекет болса, ол үнемі артады: кірістіру, жою және т.б.
сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());Егер бұл нәрселер әртүрлі болса, онда қандай да бір артта қалу бар. Кешігу – реплика мен шебер арасындағы кешігу, яғни деректер серверлер арасында әр түрлі болады.
Кешігудің үш себебі бар:
- Бұл дискінің ішкі жүйесі жазба файлдарын синхрондауды жеңе алмайды.
- Бұл деректердің көшірмеге жетуге уақыты болмаған және оны қайта жасай алмайтын кездегі ықтимал желі қателері немесе желіні шамадан тыс жүктеу.
- Және процессор. Процессор өте сирек кездесетін жағдай. Мен мұны екі-үш рет көрдім, бірақ бұл да болуы мүмкін.
Міне, статистиканы пайдалануға мүмкіндік беретін үш сұрау. Біз транзакция журналында қанша жазылғанымызды есептей аламыз. Мұндай функция бар pg_xlog_location_diff және біз репликацияның артта қалуын байт пен секундпен бағалай аламыз. Бұл үшін біз осы көріністегі мәнді (КӨРІНІСТЕР) пайдаланамыз.
Ескертпе: _pg_xlog_location орнынаdiff() функциясы азайту операторын қолдана алады және бір орынды екіншісінен шегереді. Ыңғайлы.
Секундтарда болатын артта қалған бір нүкте бар. Егер шеберде белсенділік болмаса, транзакция шамамен 15 минут бұрын болды және ешқандай белсенділік жоқ, ал егер көшірмедегі бұл лагты қарасақ, 15 минуттық кешігуді көреміз. Мұны есте ұстаған жөн. Бұл кешігуді көргенде бұл шатасуы мүмкін.
Pg_stat_all_tables - басқа пайдалы көрініс. Ол кестелердегі статистиканы көрсетеді. Деректер базасында кестелер болған кезде, онымен қандай да бір белсенділік, кейбір әрекеттер бар, біз бұл ақпаратты осы көріністен аламыз.
select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;Біз қарай алатын бірінші нәрсе - кесте бойынша дәйекті сканерлеу. Осы өтулерден кейінгі санның өзі міндетті түрде жаман емес және бізге бірдеңе жасау керек деген көрсеткіш емес.
Дегенмен, екінші көрсеткіш бар - seq_tup_read. Бұл дәйекті сканерлеуден қайтарылған жолдар саны. Егер орташа сан 1, 000, 10, 000-нан асса, бұл қазірдің өзінде сұраулар индекске негізделуі үшін индексті құру қажет болуы мүмкін немесе осындай дәйекті сканерлеуді пайдаланатын сұрауларды оңтайландыруға болатын көрсеткіш. бұл болмайтыны болды.
Қарапайым мысал - үлкен OFFSET және LIMIT шығындары бар сұранысты айтайық. Мысалы, кестедегі 100 000 жол сканерленеді және одан кейін 50 000 қажетті жол алынады және алдыңғы сканерленген жолдар жойылады. Бұл да жаман жағдай. Және мұндай сұрауларды оңтайландыру қажет. Міне, қарапайым SQL сұрауы, оны қарап шығуға және алынған сандарды бағалауға болады.
select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;Кесте өлшемдерін осы кесте арқылы және қосымша функцияларды пайдалану арқылы алуға болады pg_total_relation_size(), pg_relation_size().
Жалпы, метакомандтар бар dt и di, оны PSQL-де қолдануға болады, сонымен қатар кестелер мен индекстердің өлшемдерін көруге болады.
Дегенмен, функцияларды пайдалану бізге кестелердің өлшемдерін индекстерді ескере отырып немесе индекстерді есепке алмай-ақ қарауға көмектеседі және деректер қорының өсуіне негізделген кейбір бағалауларды жасауға көмектеседі, яғни ол қалай, қандай қарқындылықпен және өсуде. өлшемдерді оңтайландыру туралы кейбір қорытындылар жасаңыз.
Жазу әрекеті. Жазу дегеніміз не? Операцияны қарастырайық UPDATE – кестедегі жолдарды жаңарту операциясы. Шын мәнінде, жаңарту екі операция (немесе одан да көп). Бұл жолдың жаңа нұсқасын кірістіру және жолдың ескі нұсқасын ескірген деп белгілеу. Кейіннен автовакуум келіп, желілердің ескірген нұсқаларын тазалап, бұл орынды қайта пайдалануға қолжетімді деп белгілейді.
Сонымен қатар, жаңарту кестені жаңарту ғана емес. Бұл да индексті жаңарту. Егер кестеде көптеген индекстер болса, жаңарту кезінде сұрауда жаңартылған өрістерді қамтитын барлық индекстерді де жаңарту қажет болады. Бұл индекстерде тазалауды қажет ететін жолдардың ескірген нұсқалары болады.
select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;Және оның жаңа дизайнының арқасында UPDATE ауыр салмақты операция болып табылады. Бірақ оларды жеңілдетуге болады. Тамақ hot updates. Олар PostgreSQL 8.3 нұсқасында пайда болды. Ал бұл не? Бұл индекстерді қайта құруға әкелмейтін жеңіл жаңарту. Яғни, біз жазбаны жаңарттық, бірақ беттегі жазба ғана (кестеге тиесілі) жаңартылды, ал индекстер әлі де беттегі бірдей жазбаны көрсетеді. Біраз қызықты операциялық логика бар: вакуум келгенде, ол осы тізбектерді жасайды hot қалпына келтіреді және бәрі индекстерді жаңартпастан жұмысын жалғастырады және бәрі ресурстарды аз ысырап етумен болады.
Ал сіз қашан n_tup_hot_upd үлкен, онда бұл өте жақсы. Бұл жеңіл жаңартулардың басым екенін білдіреді және бұл ресурстар тұрғысынан біз үшін арзанырақ және бәрі жақсы.
ALTER TABLE table_name SET (fillfactor = 70);Көлемді қалай арттыруға болады hot updateов? пайдалана аламыз fillfactor. Ол INSERT көмегімен кестедегі бетті толтыру кезінде сақталған бос орынның өлшемін анықтайды. Кестеге кірістірулер қосылғанда, олар бетті толығымен толтырады және бос орын қалдырмайды. Содан кейін жаңа бет ерекшеленеді. Деректер қайтадан толтырылады. Және бұл әдепкі әрекет, толтыру факторы = 100%.
Біз толтырғышты 70% жасай аламыз. Яғни, кірістіру кезінде жаңа бет ерекшеленді, бірақ беттің 70% ғана толтырылды. Ал бізде 30 пайызы резервте қалды. Жаңарту қажет болғанда, ол бір бетте орын алуы мүмкін және жолдың жаңа нұсқасы сол бетте орналасады. Және hot_update орындалады. Бұл кестелерге жазуды жеңілдетеді.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));Автовакуумдық кезек. Автовакуум - бұл PostgreSQL-те статистика өте аз болатын ішкі жүйе. Қазіргі уақытта бізде қанша вакуум бар екенін pg_stat_activity ішіндегі кестелерден ғана көре аламыз. Дегенмен, қанша үстелдің кезекте тұрғанын бірден түсіну өте қиын.
Ескертпе: _Postgres 10-дан бастап, Vatovac бақылауының жағдайы айтарлықтай жақсарды - pg_stat_progress көрінісі пайда болдывакуум, бұл автомобиль вакуумын бақылау мәселесін айтарлықтай жеңілдетеді.
Біз бұл оңайлатылған сұрауды пайдалана аламыз. Біз вакуумды қашан жасау керектігін көре аламыз. Бірақ вакуумды қалай және қашан бастау керек? Бұл мен бұрын айтқан жолдардың бұрынғы нұсқалары. Жаңарту орын алды, жолдың жаңа нұсқасы енгізілді. Жолдың ескірген нұсқасы пайда болды. Кестеде pg_stat_user_tables мұндай параметр бар n_dead_tup. Ол «өлі» жолдардың санын көрсетеді. Ал өлі жолдардың саны белгілі бір шекті мәннен жоғары болған кезде, үстелге автовакуум келеді.
Ал бұл шек қалай есептеледі? Бұл кестедегі жолдардың жалпы санының өте нақты пайызы. Параметр бар autovacuum_vacuum_scale_factor. Ол пайыздық мөлшерін анықтайды. Айталық, 10% + 50 жолдан тұратын қосымша негізгі шек бар. Ал не болады? Кестедегі барлық жолдардың «10% + 50» санынан көп өлі жолдар болса, біз кестені автовакуумға қоямыз.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));Дегенмен, бір тармақ бар. Параметрлер үшін негізгі шекті мәндер av_base_thresh и av_scale_factor жеке тағайындауға болады. Және, тиісінше, шек жаһандық емес, кесте үшін жеке болады. Сондықтан, есептеу үшін сіз айла-амалдарды қолдануыңыз керек. Ал егер сізді қызықтыратын болса, онда сіз Avito-дағы әріптестеріміздің тәжірибесін көре аласыз (слайдтағы сілтеме жарамсыз және мәтінде жаңартылған).
Олар үшін жазды , бұл осы нәрселерді ескереді. Онда екі жайма аяқ киім бар. Бірақ ол дұрыс есептейді және өте тиімді, бізге аз кестелер үшін көп вакуум қажет жерде бағалауға мүмкіндік береді.
Бұл туралы не істей аламыз? Егер бізде үлкен кезек болса және автовакуум көтере алмаса, біз вакуумдық жұмысшылардың санын көбейте аламыз немесе вакуумды агрессивті ете аламыз., ол ертерек іске қосылуы үшін кестені кішкене бөліктерде өңдейді. Сөйтіп, кезек азаяды. — Мұнда ең бастысы - дискілердегі жүктемені бақылау, өйткені... вакуум - бұл тегін нәрсе емес, бірақ SSD/NVMe құрылғыларының пайда болуымен мәселе азырақ байқала бастады.
Pg_stat_all_indexes - индекстер бойынша статистика. Ол үлкен емес. Ал біз оны индекстерді пайдалану туралы ақпаратты алу үшін пайдалана аламыз. Мысалы, бізде қосымша қандай индекстер бар екенін анықтай аламыз.
Жоғарыда айтқанымдай, жаңарту тек кестелерді жаңарту ғана емес, сонымен қатар индекстерді жаңарту болып табылады. Тиісінше, егер бізде кестеде көптеген индекстер болса, онда кестедегі жолдарды жаңарту кезінде индекстелген өрістердің индекстері де жаңартылуы керек және егер бізде индекстік сканерлеу жоқ пайдаланылмаған индекстер болса, онда олар балласт ретінде ілінеді. Ал біз олардан құтылуымыз керек. Ол үшін бізге алаң қажет idx_scan. Біз жай ғана индексті сканерлеу санын қарастырамыз. Егер индекстерде статистикалық деректерді сақтаудың салыстырмалы түрде ұзақ кезеңі ішінде (кем дегенде 2-3 апта) нөлдік сканерлеу болса, онда бұл нашар индекстер болуы мүмкін, біз олардан құтылуымыз керек.
Ескертпе: Ағынды репликация кластерлері жағдайында пайдаланылмаған индекстерді іздеу кезінде барлық кластер түйіндерін тексеру қажет, себебі статистика жаһандық емес және егер индекс шеберде пайдаланылмаса, оны көшірмелерде қолдануға болады (егер ол жерде жүктеме болса).
Екі сілтеме:
Бұл пайдаланылмаған индекстерді іздеу жолындағы кеңейтілген сұрау мысалдары.
Екінші сілтеме өте қызықты сұраныс. Онда өте тривиальды емес логика бар. Мен оны анықтама үшін ұсынамын.
Индекстерді қолдану арқылы тағы нені қорытындылау керек?
-
Пайдаланылмаған индекстер нашар.
-
Олар кеңістікті алады.
-
Жаңарту әрекеттерін баяулатыңыз.
-
Шаңсорғыш үшін қосымша жұмыс.
Егер біз пайдаланылмаған индекстерді алып тастасақ, біз тек дерекқорды жақсартамыз.
Келесі презентация pg_stat_activity. Бұл қызметтік бағдарламаның аналогы ps, тек PostgreSQL-де. Егер psОлай болса, операциялық жүйедегі процестерді қараңыз pg_stat_activity Ол сізге PostgreSQL ішіндегі әрекетті көрсетеді.
Ол жерден қандай пайдалы заттарды аламыз?
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;Біз жалпы белсенділікті, мәліметтер базасында не болып жатқанын көреміз. Біз жаңа орналастыруды жасай аламыз. Мұнда бәрі жарылып кетті, жаңа қосылымдар қабылданбайды, қолданбаға қателер төгілуде.
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;Біз осындай сұрауды орындай аламыз және қосылымдардың максималды шегіне қатысты жалпы пайызын көре аламыз және кімнің ең көп қосылымы бар екенін көре аламыз. Бұл жағдайда біз сол пайдаланушыны көреміз cron_role 508 байланыс ашылды. Сол жерде оған бірдеңе болды. Біз онымен күресіп, оны қарауымыз керек. Және бұл қандай да бір аномальды байланыс саны болуы әбден мүмкін.
Егер бізде OLTP жұмыс жүктемесі болса, сұраулар жылдам, өте жылдам болуы керек және ұзақ сұраулар болмауы керек. Алайда, егер ұзақ сұраулар туындаса, онда қысқа мерзімде алаңдайтын ештеңе жоқ, бірақ Ұзақ мерзімді перспективада ұзақ сұраулар дерекқорға зиян келтіреді; олар кестенің фрагментациялануы орын алған кезде кестелердің толқу әсерін арттырады. Кептіруден де, ұзақ сұраулардан да арылу керек.
select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;Назар аударыңыз: осы сұрау арқылы біз ұзақ сұраулар мен транзакцияларды анықтай аламыз. функциясын қолданамыз clock_timestamp() жұмыс уақытын анықтау. Біз тапқан ұзақ сұраулар, біз оларды есте сақтай аламыз, орындай аламыз explain, жоспарларды қараңыз және қандай да бір жолмен оңтайландырыңыз. Біз ағымдағы ұзақ сұраныстарды түсіріп, өмірімізді жалғастырамыз.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';Нашар транзакциялар – транзакциядағы бос күйдегі және транзакциядағы әрекетсіз (тоқтатылған) күйдегі транзакциялар.
Бұл нені білдіреді? Транзакциялардың бірнеше күйі болады. Және бұл күйлердің біреуін кез келген уақытта болжауға болады. Күйлерді анықтауға арналған өріс бар state осы презентацияда. Ал біз оны күйді анықтау үшін пайдаланамыз.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';Және жоғарыда айтқанымдай, бұл екі күй транзакциядағы бос және транзакциядағы бос (тоқтатылған) нашар. Бұл не? Бұл қолданба транзакцияны ашқан кезде, кейбір әрекеттерді орындап, өз ісімен айналысты. Мәміле ашық күйінде қалады. Ол ілулі тұрады, онда ештеңе болмайды, ол қосылымды алады, өзгертілген жолдарды құлыптайды және Postrges транзакциялық қозғалтқышының архитектурасына байланысты басқа кестелердің кебуін арттыруы мүмкін. Және мұндай транзакцияларды да түсіру керек, өйткені олар кез келген жағдайда жалпы зиянды.
Дерекқорыңызда олардың 5-10-20-дан астамы бар екенін көрсеңіз, алаңдап, олармен бірдеңе істеуді бастау керек.
Мұнда біз есептеу уақытын да қолданамыз clock_timestamp(). Біз транзакцияларды жасаймыз және қолданбаны оңтайландырамыз.
Жоғарыда айтқанымдай, блоктау - екі немесе одан да көп транзакциялар бір немесе бір ресурстар тобы үшін күресу. Бұл үшін бізде алаң бар waiting логикалық мәнмен true немесе false.
Рас – бұл процесс күтілуде, бірдеңе істеу керек дегенді білдіреді. Процесс күтіп тұрғанда, бұл процесті бастаған клиент те күтіп тұрғанын білдіреді. Клиент браузерде отырады, сонымен қатар күтеді.
Ескерту: _Postgres нұсқасының 9.6 өрісінен бастап waiting жойылды және орнына тағы екі ақпараттық өріс қосылды wait_event_type и wait_event._
Не істеу? Егер сіз ұзақ уақыт бойы шындықты көрсеңіз, бұл мұндай сұраулардан құтылу керек дегенді білдіреді. Біз мұндай транзакцияларды жай ғана түсіреміз. Біз әзірлеушілерге ресурстар үшін жарыс болмас үшін қандай да бір жолмен оңтайландыру керек деп жазамыз. Содан кейін әзірлеушілер қолданбаны бұл болмас үшін оңтайландырады.
Және төтенше, бірақ өлімге әкелмейтін жағдай тұйықтардың пайда болуы. Екі транзакция екі ресурсты жаңартты, содан кейін оларға бұл жолы қарама-қарсы ресурстарға қайта кірді. Бұл жағдайда PostgreSQL транзакцияның өзін жояды, осылайша екіншісі жұмысын жалғастыра алады. Бұл тығырыққа тірелген жағдай және ол мұны өздігінен шеше алмайды. Сондықтан PostgreSQL төтенше шаралар қабылдауға мәжбүр.
Мұнда блоктауды қадағалауға мүмкіндік беретін екі сұрау бар. Біз көріністі қолданамыз pg_locks, бұл ауыр құлыптарды қадағалауға мүмкіндік береді.
Ал бірінші сілтеме сұраныс мәтінінің өзі. Бұл өте ұзақ.
Ал екінші сілтеме - құлыптар туралы мақала. Бұл оқуға пайдалы, бұл өте қызықты.
Сонымен не көріп тұрмыз? Біз екі сұрауды көреміз. -мен транзакция ALTER TABLE блоктау операциясы болып табылады. Ол басталды, бірақ аяқталмады және осы транзакцияны тіркеген қолданба бір жерде басқа нәрселерді істеп жатыр. Ал екінші сұраныс - жаңарту. Ол жұмысын жалғастырмас бұрын өзгерту кестесінің аяқталуын күтеді.
Кімді құлыптағанын, кімді ұстап отырғанын осылай анықтап, әрі қарай күресуге болады.
Келесі модуль pg_stat_statements. Мен айтқанымдай, бұл модуль. Оны пайдалану үшін оның кітапханасын конфигурацияға жүктеп, PostgreSQL қайта іске қосып, модульді орнату керек (бір пәрменмен), содан кейін бізде жаңа көрініс пайда болады.
Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;
Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;Ол жерден не аламыз? Қарапайым нәрселер туралы айтатын болсақ, сұрауды орындаудың орташа уақытын алуға болады. Уақыт өсіп келеді, яғни PostgreSQL баяу жауап береді және бізге бірдеңе істеу керек.
Біз ортақ буфердегі деректерді өзгертетін дерекқордағы ең белсенді жазу транзакцияларын қарай аламыз. Онда деректерді кім жаңартып немесе жойатынын қараңыз.
Және біз бұл сұраулар бойынша әртүрлі статистиканы қарастыра аламыз.
біз pg_stat_statements Біз оны есептерді құру үшін пайдаланамыз. Біз күніне бір рет статистиканы қалпына келтіреміз. Оны жинақтайық. Келесі жолы статистиканы қалпына келтірмес бұрын, есеп құрастырайық. Мұнда есептің сілтемесі берілген. Сіз оны көре аласыз.
Біз не істеп жатырмыз? Біз барлық сұраныстар бойынша жалпы статистиканы есептейміз. Содан кейін әрбір сұрау үшін біз оның осы жалпы статистикаға қосқан жеке үлесін есептейміз.
Ал біз не көре аламыз? Біз белгілі бір түрдегі барлық сұраулардың жалпы орындалу уақытын барлық басқа сұраулардың фонында қарай аламыз. Біз жалпы суретке қатысты процессор мен енгізу/шығару ресурстарын пайдалануды қарастыра аламыз. Бұл сұрауларды қазірдің өзінде оңтайландырыңыз. Біз осы есеп негізінде ең басты сұрауларды құрастырып жатырмыз және нені оңтайландыру керектігі туралы ойлануға дайынбыз.
Сахна артында не қалдырдық? Уақыт шектеулі болғандықтан ескермеген бірнеше өтініштер қалды.
бар pgstattuple сонымен қатар стандартты үлес пакетінің қосымша модулі болып табылады. бағалауға мүмкіндік береді bloat кестелер деп аталады кестені бөлшектеу. Ал егер фрагментация көп болса, оны алып тастап, әртүрлі құралдарды пайдалану керек. Және функция pgstattuple ұзақ уақыт жұмыс істейді. Ал кестелер неғұрлым көп болса, соғұрлым ол ұзақ жұмыс істейді.
Келесі үлес pg_buffercache. Ол ортақ буферлерді тексеруге мүмкіндік береді: буфер беттері қаншалықты қарқынды және қай кестелер үшін пайдаланылады. Және бұл жай ғана ортақ буферлерді қарауға және онда не болып жатқанын бағалауға мүмкіндік береді.
Келесі модуль pgfincore. Ол жүйелік қоңырау арқылы төмен деңгейлі кесте операцияларына мүмкіндік береді mincore(), яғни ол кестені ортақ буферлерге жүктеуге немесе оны босатуға мүмкіндік береді. Бұл басқа нәрселермен қатар, операциялық жүйенің бет кэшін тексеруге мүмкіндік береді, яғни кесте бет кэшінде, ортақ буферлерде қанша орын алады және жай ғана кестенің жұмыс жүктемесін бағалауға мүмкіндік береді.
Келесі модуль – pg_stat_kcache. Ол сондай-ақ жүйелік қоңырауды пайдаланады getrusage(). Және ол сұраныс орындалғанға дейін және кейін оны орындайды. Алынған статистикада ол дискідегі енгізу/шығару, яғни файлдық жүйемен жұмыс істеу және процессорды пайдалануды қарастыру үшін сұранысымыздың қанша жұмсалғанын бағалауға мүмкіндік береді. Дегенмен, модуль жас (жөтел жөтел) және оның жұмыс істеуі үшін мен жоғарыда айтқан PostgreSQL 9.4 және pg_stat_statements қажет.
-
Статистиканы қалай пайдалану керектігін білу пайдалы. Сізге үшінші тарап бағдарламалары қажет емес. Сіз кіре аласыз, көре аласыз, бірдеңе жасай аласыз, бірдеңе жасай аласыз.
-
Статистиканы пайдалану қиын емес, бұл қарапайым SQL. Өтінішті жинадың, құрастырдың, жібердің, қарадың.
-
Статистика сұрақтарға жауап беруге көмектеседі. Егер сізде сұрақтар туындаса, сіз статистикаға жүгінесіз - қараңыз, қорытынды жасаңыз, нәтижелерді талдаңыз.
-
Және эксперимент. Өтініш көп, деректер көп. Сіз әрқашан бұрыннан бар сұрауды оңтайландыра аласыз. Түпнұсқадан гөрі өзіңізге сәйкес келетін сұраудың нұсқасын жасап, оны пайдалана аласыз.
сілтемелер
Материалға негізделген мақалада табылған сәйкес сілтемелер есепте болды.
Автор толығырақ жазыңыз
(қазақ)
Статистика жинағы
Жүйені басқару функциялары
Үлес модульдері
SQL утилиталары және sql код мысалдары
Барлық назарыңызға рахмет!
Ақпарат көзі: www.habr.com