មូលដ្ឋានគ្រឹះនៃការត្រួតពិនិត្យ PostgreSQL ។ Alexey Lesovsky

ខ្ញុំស្នើឱ្យអ្នកអានប្រតិចារិកនៃរបាយការណ៍ដោយ Alexey Lesovsky ពី Data Egret "មូលដ្ឋានគ្រឹះនៃការត្រួតពិនិត្យ PostgreSQL"

នៅក្នុងរបាយការណ៍នេះ Alexey Lesovsky នឹងនិយាយអំពីចំណុចសំខាន់ៗនៃស្ថិតិក្រោយការឈ្លានពាន តើពួកគេមានន័យយ៉ាងណា និងហេតុអ្វីបានជាពួកគេគួរតែមានវត្តមានក្នុងការត្រួតពិនិត្យ។ អំពីក្រាហ្វដែលគួរស្ថិតនៅក្នុងការត្រួតពិនិត្យ របៀបបន្ថែមពួកវា និងរបៀបបកស្រាយវា។ របាយការណ៍នេះនឹងមានប្រយោជន៍ចំពោះអ្នកគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ អ្នកគ្រប់គ្រងប្រព័ន្ធ និងអ្នកអភិវឌ្ឍន៍ដែលចាប់អារម្មណ៍លើការដោះស្រាយបញ្ហា Postgres។

ឈ្មោះរបស់ខ្ញុំគឺ Alexey Lesovsky ខ្ញុំតំណាងឱ្យក្រុមហ៊ុន Data Egret ។

ពាក្យពីរបីអំពីខ្លួនខ្ញុំ។ ខ្ញុំបានចាប់ផ្តើមតាំងពីយូរយារណាស់មកហើយក្នុងនាមជាអ្នកគ្រប់គ្រងប្រព័ន្ធ។

ខ្ញុំបានគ្រប់គ្រងគ្រប់ប្រភេទនៃប្រព័ន្ធលីនុចផ្សេងៗគ្នា ធ្វើការលើអ្វីៗផ្សេងៗដែលទាក់ទងនឹងលីនុច ពោលគឺនិម្មិត ការត្រួតពិនិត្យ ធ្វើការជាមួយប្រូកស៊ី។ ខ្ញុំពិតជាចូលចិត្តគាត់ណាស់។ ហើយនៅចំណុចខ្លះខ្ញុំបានចាប់ផ្តើមធ្វើការលើ PostgreSQL ភាគច្រើននៃពេលវេលាធ្វើការរបស់ខ្ញុំ។ ដូច្នេះបន្តិចម្តងខ្ញុំបានក្លាយជា PostgreSQL DBA ។

ហើយពេញមួយអាជីពរបស់ខ្ញុំ ខ្ញុំតែងតែចាប់អារម្មណ៍លើប្រធានបទនៃស្ថិតិ ការត្រួតពិនិត្យ និងទូរលេខ។ ហើយនៅពេលដែលខ្ញុំជាអ្នកគ្រប់គ្រងប្រព័ន្ធ ខ្ញុំបានធ្វើការយ៉ាងជិតស្និទ្ធជាមួយ Zabbix ។ ហើយខ្ញុំបានសរសេរសំណុំតូចមួយនៃស្គ្រីបដូចជា zabbix-ផ្នែកបន្ថែម. គាត់មានប្រជាប្រិយភាពខ្លាំងនៅសម័យរបស់គាត់។ ហើយនៅទីនោះ វាអាចត្រួតពិនិត្យវត្ថុសំខាន់ៗផ្សេងៗគ្នា មិនត្រឹមតែលីនុចប៉ុណ្ណោះទេ ថែមទាំងមានសមាសធាតុផ្សេងៗទៀតផង។

ឥឡូវនេះខ្ញុំកំពុងធ្វើការលើ PostgreSQL ។ ខ្ញុំកំពុងសរសេររឿងមួយទៀតដែលអនុញ្ញាតឱ្យអ្នកធ្វើការជាមួយស្ថិតិ PostgreSQL ។ វា​ហៅថា pgCenter (អត្ថបទអំពី Habre - ស្ថិតិក្រោយការឆ្លងដោយគ្មានសរសៃប្រសាទ និងភាពតានតឹង).

សេចក្តីផ្តើមបន្តិច។ តើអតិថិជនរបស់យើង អតិថិជនរបស់យើងមានស្ថានភាពបែបណា? មានឧបទ្ទវហេតុមួយចំនួនទាក់ទងនឹងមូលដ្ឋានទិន្នន័យ។ ហើយនៅពេលដែលមូលដ្ឋានទិន្នន័យត្រូវបានស្ដារឡើងវិញរួចហើយ ប្រធាននាយកដ្ឋាន ឬប្រធានផ្នែកអភិវឌ្ឍន៍បានមក ហើយនិយាយថា៖ "មិត្តភ័ក្តិ យើងត្រូវត្រួតពិនិត្យមូលដ្ឋានទិន្នន័យ ព្រោះមានរឿងអាក្រក់បានកើតឡើង ហើយយើងត្រូវការពារកុំឱ្យវាកើតឡើងនៅពេលអនាគត"។ ហើយនៅទីនេះចាប់ផ្តើមដំណើរការគួរឱ្យចាប់អារម្មណ៍ក្នុងការជ្រើសរើសប្រព័ន្ធត្រួតពិនិត្យ ឬសម្របប្រព័ន្ធត្រួតពិនិត្យដែលមានស្រាប់ ដូច្នេះអ្នកអាចត្រួតពិនិត្យមូលដ្ឋានទិន្នន័យរបស់អ្នក - PostgreSQL, MySQL ឬមួយចំនួនផ្សេងទៀត។ ហើយសហសេវិកចាប់ផ្តើមផ្តល់យោបល់ថា “ខ្ញុំបានលឺថាមានមូលដ្ឋានទិន្នន័យបែបនេះ។ តោះ​ប្រើ​វា»។ មិត្តរួមការងារចាប់ផ្តើមឈ្លោះគ្នា។ ហើយនៅទីបញ្ចប់វាប្រែថាយើងជ្រើសរើសប្រភេទនៃមូលដ្ឋានទិន្នន័យមួយចំនួនប៉ុន្តែការត្រួតពិនិត្យ PostgreSQL ត្រូវបានបង្ហាញនៅក្នុងវាមិនសូវល្អហើយយើងតែងតែត្រូវបន្ថែមអ្វីមួយ។ យកឃ្លាំងខ្លះពី GitHub ក្លូនពួកវា សម្របស្គ្រីប និងប្ដូរតាមបំណង។ ហើយនៅទីបញ្ចប់វាបញ្ចប់ទៅជាប្រភេទនៃការងារដោយដៃមួយចំនួន។

ដូច្នេះហើយ នៅក្នុងការពិភាក្សានេះ ខ្ញុំនឹងព្យាយាមផ្ដល់ឱ្យអ្នកនូវចំណេះដឹងមួយចំនួនអំពីរបៀបជ្រើសរើសការត្រួតពិនិត្យមិនត្រឹមតែសម្រាប់ PostgreSQL ប៉ុណ្ណោះទេ ប៉ុន្តែសម្រាប់មូលដ្ឋានទិន្នន័យផងដែរ។ ហើយផ្តល់ឱ្យអ្នកនូវចំណេះដឹងដែលនឹងអនុញ្ញាតឱ្យអ្នកបំពេញការត្រួតពិនិត្យរបស់អ្នក ដើម្បីទទួលបានអត្ថប្រយោជន៍មួយចំនួនពីវា ដូច្នេះអ្នកអាចត្រួតពិនិត្យមូលដ្ឋានទិន្នន័យរបស់អ្នកជាមួយនឹងអត្ថប្រយោជន៍ ដើម្បីការពារភ្លាមៗនូវស្ថានភាពអាសន្នដែលអាចកើតឡើងនាពេលខាងមុខ។

ហើយ​គំនិត​ដែល​នឹង​មាន​នៅ​ក្នុង​របាយ​ការណ៍​នេះ​អាច​ត្រូវ​បាន​សម្រប​ដោយ​ផ្ទាល់​ទៅ​នឹង​មូលដ្ឋាន​ទិន្នន័យ​ណា​មួយ មិន​ថា​វា​ជា DBMS ឬ noSQL ទេ។ ដូច្នេះហើយ វាមិនត្រឹមតែមាន PostgreSQL ប៉ុណ្ណោះទេ ប៉ុន្តែវានឹងមានរូបមន្តជាច្រើនអំពីរបៀបធ្វើវានៅក្នុង PostgreSQL ។ វានឹងមានឧទាហរណ៍នៃសំណួរឧទាហរណ៍នៃអង្គភាពដែល PostgreSQL មានសម្រាប់ការត្រួតពិនិត្យ។ ហើយប្រសិនបើ DBMS របស់អ្នកមានរបស់ដូចគ្នាដែលអនុញ្ញាតឱ្យអ្នកដាក់ពួកវាក្នុងការត្រួតពិនិត្យ អ្នកក៏អាចសម្របពួកវា បន្ថែមពួកវា ហើយវានឹងល្អ។

ខ្ញុំនឹងមិននៅក្នុងរបាយការណ៍ទេ។
និយាយអំពីរបៀបចែកចាយ និងរក្សាទុកម៉ែត្រ។ ខ្ញុំនឹងមិននិយាយអ្វីអំពីក្រោយដំណើរការទិន្នន័យ និងបង្ហាញវាដល់អ្នកប្រើប្រាស់នោះទេ។ ហើយខ្ញុំនឹងមិននិយាយអ្វីអំពីការជូនដំណឹងទេ។
ប៉ុន្តែនៅពេលដែលរឿងដំណើរការទៅមុខ ខ្ញុំនឹងបង្ហាញរូបថតអេក្រង់ផ្សេងៗគ្នានៃការត្រួតពិនិត្យដែលមានស្រាប់ ហើយធ្វើការរិះគន់ពួកគេ។ ប៉ុន្តែយ៉ាងណាក៏ដោយ ខ្ញុំនឹងព្យាយាមមិនដាក់ឈ្មោះម៉ាកយីហោ ដើម្បីកុំឱ្យបង្កើតការផ្សាយពាណិជ្ជកម្ម ឬប្រឆាំងការផ្សាយពាណិជ្ជកម្មសម្រាប់ផលិតផលទាំងនេះ។ ដូច្នេះ ភាពចៃដន្យទាំងអស់គឺចៃដន្យ ហើយទុកជាការស្រមើលស្រមៃរបស់អ្នក។

ជាដំបូង ចូរយើងស្វែងយល់ថាតើការត្រួតពិនិត្យគឺជាអ្វី។ ការ​តាម​ដាន​ជា​រឿង​សំខាន់​ណាស់​ដែល​ត្រូវ​មាន។ មនុស្សគ្រប់គ្នាយល់ពីរឿងនេះ។ ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះ ការត្រួតពិនិត្យមិនទាក់ទងនឹងផលិតផលអាជីវកម្មទេ ហើយមិនប៉ះពាល់ផ្ទាល់ដល់ប្រាក់ចំណេញរបស់ក្រុមហ៊ុនទេ ដូច្នេះពេលវេលាតែងតែត្រូវបានបែងចែកទៅឱ្យការត្រួតពិនិត្យលើមូលដ្ឋានសំណល់។ ប្រសិនបើយើងមានពេល នោះយើងធ្វើការត្រួតពិនិត្យ ប្រសិនបើយើងមិនមានពេលទេ នោះយល់ព្រម យើងនឹងដាក់វានៅក្នុង backlog ហើយថ្ងៃណាមួយ យើងនឹងត្រលប់ទៅកិច្ចការទាំងនេះវិញ។

ដូច្នេះ ពីការអនុវត្តរបស់យើង នៅពេលដែលយើងមករកអតិថិជន ការត្រួតពិនិត្យជាញឹកញាប់មិនពេញលេញ ហើយមិនមានអ្វីដែលគួរឱ្យចាប់អារម្មណ៍ដែលនឹងជួយយើងឱ្យធ្វើការងារកាន់តែប្រសើរជាមួយមូលដ្ឋានទិន្នន័យ។ ដូច្នេះហើយ ការត្រួតពិនិត្យតែងតែត្រូវការបញ្ចប់។

មូលដ្ឋានទិន្នន័យគឺជារឿងដ៏ស្មុគស្មាញដែលត្រូវតែត្រួតពិនិត្យផងដែរ ពីព្រោះមូលដ្ឋានទិន្នន័យគឺជាឃ្លាំងផ្ទុកព័ត៌មាន។ ហើយព័ត៌មានមានសារៈសំខាន់ណាស់សម្រាប់ក្រុមហ៊ុន វាមិនអាចបាត់បង់តាមមធ្យោបាយណាមួយឡើយ។ ប៉ុន្តែនៅពេលជាមួយគ្នានោះ មូលដ្ឋានទិន្នន័យគឺជាផ្នែកដ៏ស្មុគស្មាញនៃកម្មវិធី។ ពួកវាមានសមាសធាតុមួយចំនួនធំ។ ហើយសមាសធាតុទាំងនេះជាច្រើនចាំបាច់ត្រូវត្រួតពិនិត្យ។

ប្រសិនបើយើងកំពុងនិយាយជាពិសេសអំពី PostgreSQL នោះវាអាចត្រូវបានតំណាងនៅក្នុងទម្រង់នៃគ្រោងការណ៍ដែលមានសមាសធាតុមួយចំនួនធំ។ សមាសធាតុទាំងនេះមានអន្តរកម្មគ្នាទៅវិញទៅមក។ ហើយនៅពេលជាមួយគ្នានោះ PostgreSQL មានប្រព័ន្ធរងដែលហៅថា Stats Collector ដែលអនុញ្ញាតឱ្យអ្នកប្រមូលស្ថិតិអំពីប្រតិបត្តិការនៃប្រព័ន្ធរងទាំងនេះ និងផ្តល់ប្រភេទនៃចំណុចប្រទាក់មួយចំនួនដល់អ្នកគ្រប់គ្រង ឬអ្នកប្រើប្រាស់ដើម្បីឱ្យគាត់អាចមើលស្ថិតិទាំងនេះបាន។

ស្ថិតិទាំងនេះត្រូវបានបង្ហាញក្នុងទម្រង់នៃសំណុំមុខងារ និងទិដ្ឋភាពជាក់លាក់។ ពួកគេក៏អាចត្រូវបានគេហៅថាតុ។ នោះគឺដោយប្រើម៉ាស៊ីនភ្ញៀវ psql ធម្មតា អ្នកអាចភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ ធ្វើការជ្រើសរើសលើមុខងារ និងទិដ្ឋភាពទាំងនេះ និងទទួលបានលេខជាក់លាក់មួយចំនួនអំពីប្រតិបត្តិការនៃប្រព័ន្ធរង PostgreSQL ។

អ្នកអាចបន្ថែមលេខទាំងនេះទៅក្នុងប្រព័ន្ធត្រួតពិនិត្យដែលអ្នកចូលចិត្ត គូរក្រាហ្វ បន្ថែមមុខងារ និងទទួលបានការវិភាគក្នុងរយៈពេលវែង។

ប៉ុន្តែនៅក្នុងរបាយការណ៍នេះ ខ្ញុំនឹងមិនគ្របដណ្តប់មុខងារទាំងអស់នេះទាំងស្រុងនោះទេ ព្រោះវាអាចចំណាយពេលពេញមួយថ្ងៃ។ ខ្ញុំនឹងនិយាយជាពីរ បី ឬបួនរឿង ហើយប្រាប់អ្នកពីរបៀបដែលពួកគេជួយធ្វើឱ្យការត្រួតពិនិត្យកាន់តែប្រសើរឡើង។

ហើយ​ប្រសិន​បើ​យើង​និយាយ​អំពី​ការ​ត្រួត​ពិនិត្យ​មូលដ្ឋាន​ទិន្នន័យ តើ​ត្រូវ​ត្រួត​ពិនិត្យ​អ្វី​ខ្លះ? ជាដំបូង យើងត្រូវតាមដានភាពអាចរកបាន ពីព្រោះមូលដ្ឋានទិន្នន័យគឺជាសេវាកម្មដែលផ្តល់ការចូលប្រើទិន្នន័យដល់អតិថិជន ហើយយើងត្រូវតាមដានភាពអាចរកបាន ហើយក៏ផ្តល់នូវលក្ខណៈគុណភាព និងបរិមាណមួយចំនួនផងដែរ។

យើងក៏ត្រូវត្រួតពិនិត្យអតិថិជនដែលភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យរបស់យើងផងដែរ ព្រោះវាអាចជាទាំងអតិថិជនធម្មតា និងអតិថិជនដែលមានគ្រោះថ្នាក់ដែលអាចបង្កគ្រោះថ្នាក់ដល់មូលដ្ឋានទិន្នន័យ។ ពួកគេក៏ត្រូវត្រួតពិនិត្យ និងតាមដានសកម្មភាពរបស់ពួកគេផងដែរ។

នៅពេលអតិថិជនភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ វាច្បាស់ណាស់ថាពួកគេចាប់ផ្តើមធ្វើការជាមួយទិន្នន័យរបស់យើង ដូច្នេះយើងត្រូវតាមដានពីរបៀបដែលអតិថិជនធ្វើការជាមួយទិន្នន័យ៖ ជាមួយនឹងតារាងមួយណា និងក្នុងកម្រិតតិចជាងនេះ ជាមួយនឹងសន្ទស្សន៍ណាមួយ។ នោះគឺយើងត្រូវវាយតម្លៃបន្ទុកការងារដែលត្រូវបានបង្កើតឡើងដោយអតិថិជនរបស់យើង។

ប៉ុន្តែជាការពិតណាស់ បន្ទុកការងារក៏មានសំណើផងដែរ។ កម្មវិធីភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ ចូលប្រើទិន្នន័យដោយប្រើសំណួរ ដូច្នេះវាជាការសំខាន់ដើម្បីវាយតម្លៃថាតើសំណួរណាដែលយើងមាននៅក្នុងមូលដ្ឋានទិន្នន័យ តាមដានភាពគ្រប់គ្រាន់របស់ពួកគេ ថាពួកគេមិនត្រូវបានសរសេរខុសទេ ដែលជម្រើសមួយចំនួនត្រូវសរសេរឡើងវិញ និងបង្កើតដើម្បីឱ្យពួកគេដំណើរការលឿនជាងមុន។ និងជាមួយនឹងការអនុវត្តកាន់តែប្រសើរ។

ហើយចាប់តាំងពីយើងកំពុងនិយាយអំពីមូលដ្ឋានទិន្នន័យ មូលដ្ឋានទិន្នន័យតែងតែដំណើរការផ្ទៃខាងក្រោយ។ ដំណើរការផ្ទៃខាងក្រោយជួយរក្សាដំណើរការមូលដ្ឋានទិន្នន័យក្នុងកម្រិតល្អ ដូច្នេះពួកគេត្រូវការធនធានមួយចំនួនសម្រាប់ខ្លួនគេដើម្បីដំណើរការ។ ហើយក្នុងពេលជាមួយគ្នានេះ ពួកគេអាចជាន់គ្នាជាមួយនឹងធនធានសំណើរបស់អតិថិជន ដូច្នេះដំណើរការផ្ទៃខាងក្រោយលោភលន់អាចប៉ះពាល់ដោយផ្ទាល់ដល់ការអនុវត្តសំណើរបស់អតិថិជន។ ដូច្នេះហើយ ពួកគេក៏ត្រូវត្រួតពិនិត្យ និងតាមដានផងដែរ ដើម្បីកុំឱ្យមានការបង្ខូចទ្រង់ទ្រាយក្នុងលក្ខខណ្ឌនៃដំណើរការផ្ទៃខាងក្រោយ។

ហើយទាំងអស់នេះនៅក្នុងលក្ខខណ្ឌនៃការត្រួតពិនិត្យមូលដ្ឋានទិន្នន័យនៅតែមាននៅក្នុងប្រព័ន្ធម៉ែត្រ។ ប៉ុន្តែ​ដោយ​ពិចារណា​ថា​ហេដ្ឋារចនាសម្ព័ន្ធ​ភាគច្រើន​របស់​យើង​កំពុង​ផ្លាស់​ទី​ទៅ​លើ​ពពក​នោះ រង្វាស់​ប្រព័ន្ធ​នៃ​ម៉ាស៊ីន​បុគ្គល​តែងតែ​ធ្លាក់​ចុះ​ក្នុង​ផ្ទៃ​ខាង​ក្រោយ។ ប៉ុន្តែនៅក្នុងមូលដ្ឋានទិន្នន័យពួកគេនៅតែពាក់ព័ន្ធ ហើយជាការពិតណាស់ វាក៏ចាំបាច់ក្នុងការត្រួតពិនិត្យប្រព័ន្ធម៉ែត្រផងដែរ។

អ្វីគ្រប់យ៉ាងគឺល្អច្រើន ឬតិចជាមួយនឹងរង្វាស់ប្រព័ន្ធ ប្រព័ន្ធត្រួតពិនិត្យទំនើបទាំងអស់គាំទ្ររង្វាស់ទាំងនេះរួចហើយ ប៉ុន្តែជាទូទៅ សមាសធាតុមួយចំនួននៅតែមិនគ្រប់គ្រាន់ ហើយអ្វីៗខ្លះត្រូវបន្ថែម។ ខ្ញុំក៏នឹងប៉ះពួកវាដែរ វានឹងមានស្លាយជាច្រើនអំពីពួកគេ។

ចំណុចដំបូងនៃផែនការគឺភាពងាយស្រួល។ តើអ្វីជាភាពងាយស្រួល? ភាពអាចរកបាននៅក្នុងការយល់ដឹងរបស់ខ្ញុំគឺជាសមត្ថភាពនៃមូលដ្ឋានទៅនឹងការតភ្ជាប់សេវាកម្ម ពោលគឺមូលដ្ឋានត្រូវបានលើកឡើង វាដូចជាសេវាកម្មមួយ ទទួលយកការតភ្ជាប់ពីអតិថិជន។ ហើយលទ្ធភាពប្រើប្រាស់នេះអាចត្រូវបានវាយតម្លៃដោយលក្ខណៈជាក់លាក់។ វាងាយស្រួលណាស់ក្នុងការបង្ហាញលក្ខណៈទាំងនេះនៅលើផ្ទាំងគ្រប់គ្រង។

មនុស្សគ្រប់គ្នាដឹងថាផ្ទាំងគ្រប់គ្រងគឺជាអ្វី។ នេះគឺជាពេលដែលអ្នកមើលអេក្រង់មួយ ដែលព័ត៌មានចាំបាច់ត្រូវបានសង្ខេប។ ហើយអ្នកអាចកំណត់ភ្លាមៗថាតើមានបញ្ហានៅក្នុងមូលដ្ឋានទិន្នន័យឬអត់។
ដូច្នោះហើយ ភាពអាចរកបាននៃមូលដ្ឋានទិន្នន័យ និងលក្ខណៈសំខាន់ៗផ្សេងទៀតគួរតែត្រូវបានបង្ហាញនៅលើផ្ទាំងគ្រប់គ្រងជានិច្ច ដូច្នេះព័ត៌មាននេះគឺនៅនឹងដៃ ហើយតែងតែមានសម្រាប់អ្នក។ ព័ត៌មានលម្អិតបន្ថែមមួយចំនួនដែលជួយក្នុងការស៊ើបអង្កេតឧប្បត្តិហេតុរួចហើយ នៅពេលស៊ើបអង្កេតស្ថានភាពអាសន្នមួយចំនួន ពួកវាត្រូវដាក់នៅលើផ្ទាំងគ្រប់គ្រងបន្ទាប់បន្សំរួចហើយ ឬលាក់នៅក្នុងតំណភ្ជាប់ខួងដែលនាំទៅដល់ប្រព័ន្ធត្រួតពិនិត្យភាគីទីបី។

ឧទាហរណ៍នៃប្រព័ន្ធត្រួតពិនិត្យដ៏ល្បីមួយ។ នេះគឺជាប្រព័ន្ធត្រួតពិនិត្យដ៏ត្រជាក់បំផុត។ នាងប្រមូលទិន្នន័យជាច្រើន ប៉ុន្តែតាមទស្សនៈរបស់ខ្ញុំ នាងមានគំនិតចម្លែកនៃផ្ទាំងគ្រប់គ្រង។ មានតំណភ្ជាប់ទៅ "បង្កើតផ្ទាំងគ្រប់គ្រង" ។ ប៉ុន្តែនៅពេលអ្នកបង្កើតផ្ទាំងគ្រប់គ្រង អ្នកបង្កើតបញ្ជីជួរឈរពីរ បញ្ជីក្រាហ្វ។ ហើយនៅពេលដែលអ្នកត្រូវមើលអ្វីមួយ អ្នកចាប់ផ្តើមចុចកណ្ដុរ រមូររកមើលតារាងដែលចង់បាន។ ហើយវាត្រូវការពេលវេលា ពោលគឺមិនមានផ្ទាំងគ្រប់គ្រងបែបនេះទេ។ មានតែបញ្ជីតារាងប៉ុណ្ណោះ។

តើអ្នកគួរបន្ថែមអ្វីទៅផ្ទាំងគ្រប់គ្រងទាំងនេះ? អ្នកអាចចាប់ផ្តើមជាមួយនឹងលក្ខណៈដូចជាពេលវេលាឆ្លើយតប។ PostgreSQL មានទិដ្ឋភាព pg_stat_statements ។ វាត្រូវបានបិទតាមលំនាំដើម ប៉ុន្តែវាគឺជាទិដ្ឋភាពប្រព័ន្ធដ៏សំខាន់មួយដែលគួរតែត្រូវបានបើក និងប្រើប្រាស់ជានិច្ច។ វាផ្ទុកព័ត៌មានអំពីសំណួរដែលកំពុងដំណើរការទាំងអស់ដែលត្រូវបានប្រតិបត្តិក្នុងមូលដ្ឋានទិន្នន័យ។

ដូច្នោះហើយ យើងអាចចាប់ផ្តើមពីការពិតដែលថាយើងអាចយកពេលវេលាប្រតិបត្តិសរុបនៃសំណើទាំងអស់ ហើយបែងចែកវាដោយចំនួនសំណើដោយប្រើវាលខាងលើ។ ប៉ុន្តែនេះគឺជាសីតុណ្ហភាពជាមធ្យមនៅក្នុងមន្ទីរពេទ្យ។ យើងអាចចាប់ផ្តើមពីវាលផ្សេងទៀត - ពេលវេលាប្រតិបត្តិសំណួរអប្បបរមា អតិបរមា និងមធ្យម។ ហើយយើងថែមទាំងអាចបង្កើតភាគរយបាន PostgreSQL មានមុខងារដែលត្រូវគ្នាសម្រាប់រឿងនេះ។ ហើយយើងអាចទទួលបានលេខមួយចំនួនដែលកំណត់លក្ខណៈពេលវេលាឆ្លើយតបនៃមូលដ្ឋានទិន្នន័យរបស់យើងសម្រាប់សំណើដែលបានបញ្ចប់រួចហើយ ពោលគឺយើងមិនប្រតិបត្តិសំណើក្លែងក្លាយ 'ជ្រើសរើស 1' ហើយមើលពេលវេលាឆ្លើយតបទេ ប៉ុន្តែយើងវិភាគពេលវេលាឆ្លើយតបសម្រាប់សំណើដែលបានបំពេញរួចហើយ និងគូរ។ ទាំងតួលេខដាច់ដោយឡែក ឬយើងបង្កើតក្រាហ្វដោយផ្អែកលើវា។

វាក៏សំខាន់ផងដែរក្នុងការត្រួតពិនិត្យចំនួនកំហុសដែលបច្ចុប្បន្នត្រូវបានបង្កើតដោយប្រព័ន្ធ។ ហើយសម្រាប់វាអ្នកអាចប្រើទិដ្ឋភាព pg_stat_database ។ យើងផ្តោតលើវាល xact_rollback ។ វាលនេះបង្ហាញមិនត្រឹមតែចំនួននៃការវិលត្រឡប់មកវិញដែលកើតឡើងនៅក្នុងមូលដ្ឋានទិន្នន័យប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងគិតដល់ចំនួនកំហុសផងដែរ។ បើនិយាយទាក់ទងគ្នា យើងអាចបង្ហាញតួលេខនេះនៅក្នុងផ្ទាំងគ្រប់គ្រងរបស់យើង ហើយមើលថាតើយើងមានកំហុសប៉ុន្មាននាពេលបច្ចុប្បន្ននេះ។ ប្រសិនបើមានកំហុសច្រើន នោះគឺជាហេតុផលដ៏ល្អមួយដើម្បីពិនិត្យមើលកំណត់ហេតុ និងមើលថាតើវាមានកំហុសប្រភេទណា ហើយហេតុអ្វីបានជាវាកើតឡើង ហើយបន្ទាប់មកវិនិយោគ និងដោះស្រាយវា។

អ្នកអាចបន្ថែមវត្ថុដូចជា Tachometer ។ ទាំងនេះគឺជាចំនួននៃប្រតិបត្តិការក្នុងមួយវិនាទី និងចំនួនសំណើក្នុងមួយវិនាទី។ និយាយដោយទាក់ទងគ្នា អ្នកអាចប្រើលេខទាំងនេះជាការដំណើរការបច្ចុប្បន្ននៃមូលដ្ឋានទិន្នន័យរបស់អ្នក ហើយសង្កេតមើលថាតើមានកម្រិតខ្ពស់ក្នុងសំណើ កម្រិតខ្ពស់ក្នុងប្រតិបត្តិការ ឬផ្ទុយទៅវិញថាតើមូលដ្ឋានទិន្នន័យត្រូវបានផ្ទុកដោយសារផ្នែកខាងក្រោយមួយចំនួនបានបរាជ័យ។ វាជារឿងសំខាន់ដែលត្រូវមើលតួលេខនេះជានិច្ច ហើយចងចាំថាសម្រាប់គម្រោងរបស់យើង ប្រភេទនៃការអនុវត្តនេះគឺធម្មតា ប៉ុន្តែតម្លៃខាងលើ និងខាងក្រោមគឺជាប្រភេទនៃបញ្ហា និងមិនអាចយល់បានរួចទៅហើយ ដែលមានន័យថាយើងត្រូវពិនិត្យមើលថាហេតុអ្វីបានជាលេខទាំងនេះ ខ្ពស់​ណាស់។

ដើម្បីប៉ាន់ប្រមាណចំនួនប្រតិបត្តិការ យើងអាចយោងទៅលើទិដ្ឋភាព pg_stat_database ម្តងទៀត។ យើងអាចបន្ថែមចំនួននៃ commits និងចំនួន rollbacks និងទទួលបានចំនួននៃប្រតិបត្តិការក្នុងមួយវិនាទី។

តើគ្រប់គ្នាយល់ថាសំណើជាច្រើនអាចសមនឹងប្រតិបត្តិការតែមួយទេ? ដូច្នេះ TPS និង QPS គឺខុសគ្នាបន្តិចបន្តួច។

ចំនួនសំណើក្នុងមួយវិនាទីអាចទទួលបានពី pg_stat_statements ហើយគ្រាន់តែគណនាផលបូកនៃសំណើដែលបានបញ្ចប់ទាំងអស់។ វាច្បាស់ណាស់ថាយើងប្រៀបធៀបតម្លៃបច្ចុប្បន្នជាមួយតម្លៃមុន ដកវា ទទួលបានដីសណ្ត និងទទួលបានបរិមាណ។

អ្នក​អាច​បន្ថែម​ម៉ែត្រ​បន្ថែម​ប្រសិន​បើ​ចង់​បាន ដែល​ក៏​ជួយ​វាយ​តម្លៃ​ភាព​អាច​រក​បាន​នៃ​មូលដ្ឋាន​ទិន្នន័យ​របស់​យើង និង​តាម​ដាន​ថា​តើ​មាន​ការ​ធ្លាក់​ចុះ​ឬ​អត់។

មួយក្នុងចំនោមរង្វាស់ទាំងនេះគឺម៉ោងធ្វើការ។ ប៉ុន្តែម៉ោងធ្វើការនៅក្នុង PostgreSQL គឺពិបាកបន្តិច។ ខ្ញុំនឹងប្រាប់អ្នកពីមូលហេតុ។ នៅពេលដែល PostgreSQL បានចាប់ផ្តើម ពេលវេលាដំណើរការចាប់ផ្តើមរាយការណ៍។ ប៉ុន្តែប្រសិនបើនៅចំណុចមួយចំនួន ឧទាហរណ៍ កិច្ចការមួយចំនួនកំពុងដំណើរការនៅពេលយប់ ឃាតករ OOM បានមក ហើយបង្ខំឱ្យបញ្ចប់ដំណើរការកូន PostgreSQL បន្ទាប់មកក្នុងករណីនេះ PostgreSQL បញ្ចប់ការតភ្ជាប់របស់អតិថិជនទាំងអស់ កំណត់តំបន់អង្គចងចាំដែលបានរុះរើឡើងវិញ ហើយចាប់ផ្តើមការងើបឡើងវិញពី ប៉ុស្តិ៍ត្រួតពិនិត្យចុងក្រោយ។ ហើយខណៈពេលដែលការងើបឡើងវិញពីចំណុចត្រួតពិនិត្យនេះមានរយៈពេល មូលដ្ឋានទិន្នន័យមិនទទួលយកការតភ្ជាប់ទេ ពោលគឺស្ថានភាពនេះអាចត្រូវបានគេវាយតម្លៃថាជាពេលវេលារងចាំ។ ប៉ុន្តែការរាប់ម៉ោងធ្វើការនឹងមិនត្រូវបានកំណត់ឡើងវិញទេ ព្រោះវាគិតពីពេលវេលាចាប់ផ្តើមមេប្រៃសណីយ៍ចាប់ពីពេលដំបូង។ ដូច្នេះស្ថានភាពបែបនេះអាចត្រូវបានរំលង។

អ្នកក៏គួរតាមដានចំនួនអ្នកធ្វើការបូមធូលីផងដែរ។ តើអ្នកទាំងអស់គ្នាដឹងថា autovacuum ជាអ្វីនៅក្នុង PostgreSQL ទេ? នេះគឺជាប្រព័ន្ធរងគួរឱ្យចាប់អារម្មណ៍នៅក្នុង PostgreSQL ។ អត្ថបទជាច្រើនត្រូវបានសរសេរអំពីនាង របាយការណ៍ជាច្រើនត្រូវបានធ្វើឡើង។ មានការពិភាក្សាជាច្រើនអំពីម៉ាស៊ីនបូមធូលី និងរបៀបដែលវាគួរដំណើរការ។ មនុស្សជាច្រើនចាត់ទុកវាជាអំពើអាក្រក់ចាំបាច់។ ប៉ុន្តែនោះហើយជារបៀបដែលវាគឺជា។ នេះគឺជាប្រភេទនៃ analogue របស់អ្នកប្រមូលសំរាមដែលសម្អាតជួរដែលហួសសម័យដែលមិនត្រូវការដោយប្រតិបត្តិការណាមួយ ហើយបង្កើនទំហំទំនេរនៅក្នុងតារាង និងលិបិក្រមសម្រាប់ជួរថ្មី។

ហេតុអ្វីបានជាអ្នកត្រូវការតាមដានវា? ព្រោះ​ពេល​ខ្លះ​ការ​ខ្វះ​ចន្លោះ​ឈឺ​ខ្លាំង។ វាប្រើប្រាស់ធនធានយ៉ាងច្រើន ហើយសំណើរបស់អតិថិជនចាប់ផ្តើមរងទុក្ខជាលទ្ធផល។

ហើយវាគួរតែត្រូវបានត្រួតពិនិត្យតាមរយៈទិដ្ឋភាព pg_stat_activity ដែលខ្ញុំនឹងនិយាយអំពីនៅក្នុងផ្នែកបន្ទាប់។ ទិដ្ឋភាពនេះបង្ហាញពីសកម្មភាពបច្ចុប្បន្ននៅក្នុងមូលដ្ឋានទិន្នន័យ។ ហើយតាមរយៈសកម្មភាពនេះ យើងអាចតាមដានចំនួនម៉ាស៊ីនបូមធូលីដែលកំពុងដំណើរការនៅពេលនេះ។ យើងអាចតាមដានការខ្វះចន្លោះ ហើយឃើញថាប្រសិនបើយើងលើសដែនកំណត់នោះ នេះជាហេតុផលដើម្បីពិនិត្យមើលការកំណត់ PostgreSQL និងអាចបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការរបស់ម៉ាស៊ីនបូមធូលី។

រឿងមួយទៀតអំពី PostgreSQL គឺថា PostgreSQL ឈឺខ្លាំងចំពោះប្រតិបត្តិការយូរ។ ជាពិសេសពីប្រតិបត្តិការដែលព្យួរនៅជុំវិញរយៈពេលយូរនិងមិនធ្វើអ្វីសោះ។ នេះគឺជាអ្វីដែលហៅថា stat idle-in-transaction។ ប្រតិបត្តិការបែបនេះរក្សាសោ និងការពារការខ្វះចន្លោះមិនដំណើរការ។ ហើយជាលទ្ធផលតារាងហើមនិងបង្កើនទំហំ។ ហើយសំណួរដែលដំណើរការជាមួយតារាងទាំងនេះចាប់ផ្តើមដំណើរការយឺតជាងមុន ពីព្រោះអ្នកត្រូវរុញជួរចាស់ទាំងអស់ពីអង្គចងចាំទៅថាស និងខាងក្រោយ។ ដូច្នេះ ពេលវេលា រយៈពេលនៃប្រតិបត្តិការដ៏វែងបំផុត សំណើបូមធូលីវែងបំផុត ក៏ត្រូវត្រួតពិនិត្យផងដែរ។ ហើយប្រសិនបើយើងឃើញដំណើរការមួយចំនួនដែលបានដំណើរការអស់រយៈពេលជាយូរមកហើយ លើសពី 10-20-30 នាទីសម្រាប់ការផ្ទុក OLTP នោះ យើងត្រូវយកចិត្តទុកដាក់លើពួកវា ហើយបិទវាដោយបង្ខំ ឬបង្កើនប្រសិទ្ធភាពកម្មវិធីដើម្បីឱ្យពួកគេ មិនត្រូវបានហៅហើយកុំព្យួរយូរ។ សម្រាប់បន្ទុកការងារវិភាគ 10-20-30 នាទីគឺធម្មតា ហើយក៏មានការងារវែងជាងនេះផងដែរ។

បន្ទាប់យើងមានជម្រើសជាមួយអតិថិជនដែលបានភ្ជាប់។ នៅពេលដែលយើងបានបង្កើតផ្ទាំងគ្រប់គ្រងរួចហើយ និងបានបង្ហោះការវាស់វែងភាពអាចរកបានសំខាន់ៗនៅលើវា យើងក៏អាចបន្ថែមព័ត៌មានបន្ថែមអំពីអតិថិជនដែលបានភ្ជាប់នៅទីនោះផងដែរ។

ព័ត៌មានអំពីអតិថិជនដែលបានភ្ជាប់គឺមានសារៈសំខាន់ពីព្រោះតាមទស្សនៈរបស់ PostgreSQL អតិថិជនគឺខុសគ្នា។ មានអតិថិជនល្អ និងមានអតិថិជនមិនល្អ។

ឧទាហរណ៍សាមញ្ញមួយ។ ដោយអតិថិជនខ្ញុំយល់ពីកម្មវិធី។ កម្មវិធីបានភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ ហើយភ្លាមៗចាប់ផ្តើមផ្ញើសំណើរបស់វានៅទីនោះ មូលដ្ឋានទិន្នន័យដំណើរការ និងប្រតិបត្តិពួកវា ហើយបញ្ជូនលទ្ធផលទៅអតិថិជនវិញ។ ទាំងនេះគឺជាអតិថិជនល្អ និងត្រឹមត្រូវ។

មានស្ថានភាពនៅពេលដែលអតិថិជនបានភ្ជាប់ វារក្សាការភ្ជាប់ប៉ុន្តែមិនធ្វើអ្វីសោះ។ វាស្ថិតនៅក្នុងស្ថានភាពទំនេរ។

ប៉ុន្តែមានអតិថិជនអាក្រក់។ ឧទាហរណ៍ អតិថិជនដូចគ្នាបានភ្ជាប់ បើកប្រតិបត្តិការ ធ្វើអ្វីមួយនៅក្នុងមូលដ្ឋានទិន្នន័យ ហើយបន្ទាប់មកចូលទៅក្នុងកូដ ឧទាហរណ៍ ដើម្បីចូលប្រើប្រភពខាងក្រៅ ឬដំណើរការទិន្នន័យដែលទទួលបាននៅទីនោះ។ ប៉ុន្តែគាត់មិនបានបិទប្រតិបត្តិការទេ។ ហើយប្រតិបត្តិការព្យួរនៅក្នុងមូលដ្ឋានទិន្នន័យ ហើយត្រូវបានចាក់សោរនៅលើបន្ទាត់។ នេះគឺជាស្ថានភាពមិនល្អ។ ហើយប្រសិនបើភ្លាមៗនោះកម្មវិធីណាមួយនៅក្នុងខ្លួនវាបរាជ័យដោយមានករណីលើកលែង នោះប្រតិបត្តិការអាចនៅតែបើកក្នុងរយៈពេលយូរ។ ហើយនេះប៉ះពាល់ដល់ដំណើរការ PostgreSQL ដោយផ្ទាល់។ PostgreSQL នឹងយឺតជាង។ ដូច្នេះ វាមានសារៈសំខាន់ណាស់ក្នុងការតាមដានអតិថិជនបែបនេះឱ្យបានទាន់ពេលវេលា និងបញ្ឈប់ការងាររបស់ពួកគេដោយបង្ខំ។ ហើយអ្នកត្រូវបង្កើនប្រសិទ្ធភាពកម្មវិធីរបស់អ្នកដើម្បីកុំឱ្យស្ថានភាពបែបនេះកើតឡើង។

អតិថិជនអាក្រក់ផ្សេងទៀតកំពុងរង់ចាំអតិថិជន។ ប៉ុន្តែពួកគេក្លាយជាអាក្រក់ដោយសារតែកាលៈទេសៈ។ ឧទាហរណ៍ ប្រតិបត្តិការទំនេរសាមញ្ញ៖ វាអាចបើកប្រតិបត្តិការ ចាក់សោរលើបន្ទាត់មួយចំនួន បន្ទាប់មកកន្លែងណាមួយនៃកូដវានឹងបរាជ័យ ដោយបន្សល់ទុកនូវប្រតិបត្តិការព្យួរ។ អតិថិជនផ្សេងទៀតនឹងមកស្នើសុំទិន្នន័យដូចគ្នា ប៉ុន្តែគាត់នឹងជួបប្រទះនឹងការចាក់សោរ ពីព្រោះប្រតិបត្តិការព្យួរនោះបានចាក់សោរនៅលើជួរដែលត្រូវការមួយចំនួនរួចហើយ។ ហើយប្រតិបត្តិការទីពីរនឹងរង់ចាំសម្រាប់ប្រតិបត្តិការដំបូងបញ្ចប់ ឬបង្ខំឱ្យបិទវាដោយអ្នកគ្រប់គ្រង។ ដូច្នេះ ប្រតិបត្តិការដែលមិនទាន់សម្រេចអាចកកកុញ និងបំពេញដែនកំណត់នៃការតភ្ជាប់មូលដ្ឋានទិន្នន័យ។ ហើយនៅពេលដែលដែនកំណត់ពេញ កម្មវិធីមិនអាចដំណើរការជាមួយមូលដ្ឋានទិន្នន័យបានទេ។ នេះគឺជាស្ថានភាពបន្ទាន់សម្រាប់គម្រោងរួចហើយ។ ដូច្នេះ​អតិថិជន​មិន​ល្អ​ត្រូវ​តាមដាន និង​ឆ្លើយតប​ទាន់​ពេល​វេលា។

ឧទាហរណ៍មួយទៀតនៃការត្រួតពិនិត្យ។ ហើយមានផ្ទាំងគ្រប់គ្រងសមរម្យនៅទីនេះរួចហើយ។ មានព័ត៌មានអំពីការតភ្ជាប់ខាងលើ។ ការតភ្ជាប់ DB - 8 បំណែក។ ហើយវាទាំងអស់។ យើង​មិន​មាន​ព័ត៌មាន​អំពី​អតិថិជន​ណា​ដែល​សកម្ម អតិថិជន​ណា​ដែល​គ្រាន់តែ​នៅ​ទំនេរ មិន​ធ្វើ​អ្វី​ឡើយ។ មិនមានព័ត៌មានអំពីប្រតិបត្តិការដែលកំពុងរង់ចាំ និងការភ្ជាប់ដែលមិនទាន់សម្រេចនោះទេ ពោលគឺនេះគឺជាតួលេខដែលបង្ហាញពីចំនួននៃការតភ្ជាប់ ហើយនោះជាវា។ ហើយបន្ទាប់មកទាយដោយខ្លួនឯង។

ដូច្នោះហើយ ដើម្បីបន្ថែមព័ត៌មាននេះទៅការត្រួតពិនិត្យ អ្នកត្រូវចូលទៅកាន់ទិដ្ឋភាពប្រព័ន្ធ pg_stat_activity ។ ប្រសិនបើអ្នកចំណាយពេលច្រើននៅក្នុង PostgreSQL នោះនេះគឺជាទិដ្ឋភាពល្អណាស់ដែលគួរតែក្លាយជាមិត្តរបស់អ្នក ព្រោះវាបង្ហាញពីសកម្មភាពបច្ចុប្បន្ននៅក្នុង PostgreSQL ពោលគឺអ្វីដែលកំពុងកើតឡើងនៅក្នុងនោះ។ សម្រាប់ដំណើរការនីមួយៗមានបន្ទាត់ដាច់ដោយឡែកដែលបង្ហាញព័ត៌មានអំពីដំណើរការនេះ៖ ពីម៉ាស៊ីនណាដែលការតភ្ជាប់ត្រូវបានធ្វើឡើង ក្រោមអ្នកប្រើប្រាស់ ក្រោមឈ្មោះអ្វី នៅពេលប្រតិបត្តិការត្រូវបានចាប់ផ្តើម សំណើអ្វីដែលកំពុងដំណើរការ សំណើអ្វីដែលត្រូវបានប្រតិបត្តិចុងក្រោយ។ ហើយតាមនោះ យើងអាចវាយតម្លៃស្ថានភាពរបស់អតិថិជនដោយប្រើវាលស្ថិតិ។ និយាយដោយទាក់ទងគ្នា យើងអាចដាក់ជាក្រុមតាមវាលនេះ និងទទួលបានស្ថិតិទាំងនោះដែលបច្ចុប្បន្ននៅក្នុងមូលដ្ឋានទិន្នន័យ និងចំនួននៃការតភ្ជាប់ដែលមានស្ថិតិនេះនៅក្នុងមូលដ្ឋានទិន្នន័យ។ ហើយ​យើង​អាច​ផ្ញើ​លេខ​ដែល​បាន​ទទួល​រួច​ទៅ​កាន់​ការ​ត្រួត​ពិនិត្យ​របស់​យើង និង​គូរ​ក្រាហ្វ​ដោយ​ផ្អែក​លើ​លេខ​ទាំងនោះ។
វាក៏សំខាន់ផងដែរក្នុងការវាយតម្លៃរយៈពេលនៃប្រតិបត្តិការ។ ខ្ញុំបាននិយាយរួចហើយថាវាមានសារៈសំខាន់ក្នុងការវាយតម្លៃរយៈពេលនៃការខ្វះចន្លោះ ប៉ុន្តែប្រតិបត្តិការត្រូវបានវាយតម្លៃតាមរបៀបដូចគ្នា។ មាន xact_start និង query_start ។ ពួកគេនិយាយដោយទាក់ទងគ្នា បង្ហាញពីពេលវេលាចាប់ផ្តើមនៃប្រតិបត្តិការ និងពេលវេលាចាប់ផ្តើមនៃសំណើ។ យើងយកមុខងារ now() ដែលបង្ហាញត្រាពេលវេលាបច្ចុប្បន្ន ហើយដកប្រតិបត្តិការ និងស្នើសុំត្រាពេលវេលា។ ហើយយើងទទួលបានរយៈពេលនៃប្រតិបត្តិការរយៈពេលនៃការស្នើសុំ។

ប្រសិនបើយើងឃើញប្រតិបត្តិការយូរ យើងគួរតែបំពេញវារួចហើយ។ សម្រាប់ការផ្ទុក OLTP ប្រតិបត្តិការដ៏វែងគឺច្រើនជាង 1-2-3 នាទីរួចទៅហើយ. សម្រាប់បន្ទុកការងាររបស់ OLAP ប្រតិបត្តិការដ៏យូរគឺជារឿងធម្មតា ប៉ុន្តែប្រសិនបើពួកគេចំណាយពេលលើសពីពីរម៉ោងដើម្បីបញ្ចប់ នោះក៏ជាសញ្ញាមួយដែលបង្ហាញថាយើងមានការងឿងឆ្ងល់នៅកន្លែងណាមួយដែរ។

នៅពេលដែលអតិថិជនបានភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ ពួកគេចាប់ផ្តើមធ្វើការជាមួយទិន្នន័យរបស់យើង។ ពួកគេចូលប្រើតារាង ពួកគេចូលប្រើលិបិក្រមដើម្បីទទួលបានទិន្នន័យពីតារាង។ ហើយវាជារឿងសំខាន់ក្នុងការវាយតម្លៃពីរបៀបដែលអតិថិជនធ្វើអន្តរកម្មជាមួយទិន្នន័យនេះ។

នេះគឺចាំបាច់ដើម្បីវាយតម្លៃបន្ទុកការងាររបស់យើង ហើយយល់យ៉ាងមិចៗថាតើតារាងមួយណាជា "ក្តៅបំផុត" សម្រាប់យើង។ ជាឧទាហរណ៍ វាត្រូវការជាចាំបាច់ក្នុងស្ថានភាពដែលយើងចង់ដាក់តារាង "ក្តៅ" លើប្រភេទអង្គផ្ទុកទិន្នន័យ SSD ដែលមានល្បឿនលឿនមួយចំនួន។ ជាឧទាហរណ៍ តារាងបណ្ណសារមួយចំនួនដែលយើងមិនបានប្រើយូរមកហើយ អាចត្រូវបានផ្លាស់ទីទៅបណ្ណសារប្រភេទ "ត្រជាក់" មួយចំនួនទៅកាន់ SATA drives ហើយអនុញ្ញាតឱ្យពួកគេរស់នៅទីនោះ ពួកគេនឹងត្រូវបានចូលប្រើតាមតម្រូវការ។

នេះ​ក៏​មាន​ប្រយោជន៍​សម្រាប់​ការ​រក​ឃើញ​ភាព​មិន​ប្រក្រតី​បន្ទាប់​ពី​ការ​ចេញ​ផ្សាយ និង​ការ​ដាក់​ពង្រាយ​ណា​មួយ​។ ឧបមាថាគម្រោងនេះបានបញ្ចេញមុខងារថ្មីមួយចំនួន។ ឧទាហរណ៍ យើងបានបន្ថែមមុខងារថ្មីសម្រាប់ធ្វើការជាមួយមូលដ្ឋានទិន្នន័យ។ ហើយ​ប្រសិនបើ​យើង​រៀបចំ​ក្រាហ្វ​នៃ​ការប្រើប្រាស់​តារាង នោះ​យើង​អាច​រកឃើញ​ភាពមិនប្រក្រតី​ទាំងនេះ​យ៉ាង​ងាយស្រួល​នៅលើ​ក្រាហ្វ​ទាំងនេះ។ ឧទាហរណ៍ ធ្វើបច្ចុប្បន្នភាពការផ្ទុះឡើង ឬលុបការផ្ទុះឡើង។ វានឹងអាចមើលឃើញយ៉ាងខ្លាំង។

អ្នកក៏អាចរកឃើញភាពមិនប្រក្រតីនៅក្នុងស្ថិតិ "អណ្តែត" ផងដែរ។ តើ​វា​មានន័យ​យ៉ាង​ដូចម្តេច? PostgreSQL មានកម្មវិធីរៀបចំសំណួរដ៏រឹងមាំ និងល្អណាស់។ ហើយអ្នកអភិវឌ្ឍន៍បានលះបង់ពេលវេលាច្រើនក្នុងការអភិវឌ្ឍន៍របស់វា។ តើគាត់ធ្វើការយ៉ាងដូចម្តេច? ដើម្បីបង្កើតផែនការល្អ PostgreSQL ប្រមូលស្ថិតិស្តីពីការចែកចាយទិន្នន័យក្នុងតារាងក្នុងចន្លោះពេលជាក់លាក់មួយ និងជាមួយនឹងប្រេកង់ជាក់លាក់មួយ។ ទាំងនេះគឺជាតម្លៃទូទៅបំផុត៖ ចំនួននៃតម្លៃតែមួយគត់ ព័ត៌មានអំពី NULL ក្នុងតារាង ព័ត៌មានជាច្រើន។

ដោយផ្អែកលើស្ថិតិទាំងនេះ អ្នករៀបចំផែនការបង្កើតសំណួរជាច្រើន ជ្រើសរើសជម្រើសដ៏ប្រសើរបំផុត ហើយប្រើផែនការសំណួរនេះ ដើម្បីប្រតិបត្តិសំណួរដោយខ្លួនឯង និងបញ្ជូនទិន្នន័យមកវិញ។

ហើយវាកើតឡើងដែលស្ថិតិ "អណ្តែត" ។ ទិន្នន័យគុណភាព និងបរិមាណផ្លាស់ប្តូរដូចម្ដេចនៅក្នុងតារាង ប៉ុន្តែស្ថិតិមិនត្រូវបានប្រមូលទេ។ ហើយផែនការដែលបានបង្កើតឡើងប្រហែលជាមិនល្អបំផុតទេ។ ហើយប្រសិនបើផែនការរបស់យើងមានភាពល្អប្រសើរដោយផ្អែកលើការត្រួតពិនិត្យដែលប្រមូលបាន ដោយផ្អែកលើតារាង នោះយើងនឹងអាចឃើញភាពមិនប្រក្រតីទាំងនេះ។ ជាឧទាហរណ៍ នៅកន្លែងណាមួយដែលទិន្នន័យបានផ្លាស់ប្តូរគុណភាព ហើយជំនួសឱ្យលិបិក្រម ការឆ្លងកាត់តាមតារាងបន្តបន្ទាប់គ្នាបានចាប់ផ្តើមប្រើ ពោលគឺឧ។ ប្រសិនបើសំណួរត្រូវការត្រឡប់ត្រឹមតែ 100 ជួរ (មានដែនកំណត់ 100) នោះការស្វែងរកពេញលេញនឹងត្រូវបានអនុវត្តសម្រាប់សំណួរនេះ។ ហើយ​នេះ​តែង​មាន​ឥទ្ធិពល​អាក្រក់​ខ្លាំង​ដល់​ការ​អនុវត្ត។

ហើយយើងអាចមើលឃើញរឿងនេះនៅក្នុងការត្រួតពិនិត្យ។ ហើយមើលសំណួរនេះរួចហើយ ដំណើរការពន្យល់សម្រាប់វា ប្រមូលស្ថិតិ បង្កើតលិបិក្រមបន្ថែមថ្មី។ ហើយ​បាន​ឆ្លើយ​តប​នឹង​បញ្ហា​នេះ​រួច​ហើយ។ នោះហើយជាមូលហេតុដែលវាសំខាន់។

ឧទាហរណ៍មួយទៀតនៃការត្រួតពិនិត្យ។ ខ្ញុំ​គិត​ថា​មនុស្ស​ជា​ច្រើន​បាន​ទទួល​ស្គាល់​គាត់​ព្រោះ​គាត់​មាន​ប្រជាប្រិយ​ភាព​ខ្លាំង។ អ្នកណាប្រើវានៅក្នុងគម្រោងរបស់ពួកគេ។ Prometheus? តើអ្នកណាប្រើផលិតផលនេះជាមួយ Prometheus? ការពិតគឺថានៅក្នុងឃ្លាំងស្តង់ដារនៃការត្រួតពិនិត្យនេះមានផ្ទាំងគ្រប់គ្រងសម្រាប់ធ្វើការជាមួយ PostgreSQL - postgres_អ្នកនាំចេញ Prometheus ។ ប៉ុន្តែមានព័ត៌មានលម្អិតអាក្រក់មួយ។

មានក្រាហ្វជាច្រើន។ ហើយបៃត្រូវបានចង្អុលបង្ហាញថាជាឯកភាព ពោលគឺមាន 5 ក្រាហ្វ។ ទាំងនេះគឺជា បញ្ចូលទិន្នន័យ ធ្វើបច្ចុប្បន្នភាពទិន្នន័យ លុបទិន្នន័យ ទាញយកទិន្នន័យ និងត្រឡប់ទិន្នន័យ។ ការវាស់វែងឯកតាគឺបៃ។ ប៉ុន្តែរឿងនេះគឺថាស្ថិតិនៅក្នុង PostgreSQL ត្រឡប់ទិន្នន័យជា tuple (ជួរដេក) ។ ហើយតាមនោះ ក្រាហ្វទាំងនេះគឺជាវិធីដ៏ល្អមួយដើម្បីមើលស្រាលបន្ទុកការងាររបស់អ្នកច្រើនដង រាប់សិបដង ពីព្រោះ tuple មិនមែនជាបៃទេ tuple គឺជាខ្សែអក្សរ វាមានច្រើនបៃ ហើយវាតែងតែមានប្រវែងអថេរ។ នោះគឺការគណនាបន្ទុកការងារជាបៃដោយប្រើ tuples គឺជាកិច្ចការមិនប្រាកដប្រជា ឬពិបាកខ្លាំងណាស់។ ដូច្នេះហើយ នៅពេលដែលអ្នកប្រើផ្ទាំងគ្រប់គ្រង ឬការត្រួតពិនិត្យដែលភ្ជាប់មកជាមួយ វាតែងតែសំខាន់ក្នុងការយល់ដឹងថាវាដំណើរការបានត្រឹមត្រូវ និងបញ្ជូនទិន្នន័យដែលបានវាយតម្លៃយ៉ាងត្រឹមត្រូវ។

តើធ្វើដូចម្តេចដើម្បីទទួលបានស្ថិតិនៅលើតារាងទាំងនេះ? ចំពោះគោលបំណងនេះ PostgreSQL មានទិដ្ឋភាពគ្រួសារជាក់លាក់។ ហើយទិដ្ឋភាពសំខាន់គឺ pg_stat_user_tables. User_tables - នេះមានន័យថាតារាងដែលបានបង្កើតក្នុងនាមអ្នកប្រើប្រាស់។ ផ្ទុយទៅវិញ មានទិដ្ឋភាពប្រព័ន្ធដែលប្រើដោយ PostgreSQL ខ្លួនវាផ្ទាល់។ ហើយមានតារាងសង្ខេប Alltables ដែលរួមមានទាំងប្រព័ន្ធ និងអ្នកប្រើប្រាស់។ អ្នកអាចចាប់ផ្តើមពីពួកគេណាមួយដែលអ្នកចូលចិត្តបំផុត។

ដោយប្រើវាលខាងលើ អ្នកអាចប៉ាន់ស្មានចំនួននៃការបញ្ចូល ការអាប់ដេត និងការលុប។ ឧទាហរណ៍នៃផ្ទាំងគ្រប់គ្រងដែលខ្ញុំបានប្រើប្រើវាលទាំងនេះដើម្បីវាយតម្លៃលក្ខណៈនៃបន្ទុកការងារ។ ដូច្នេះ​ហើយ យើង​ក៏​អាច​បង្កើត​វា​បាន​ដែរ។ ប៉ុន្តែវាគួរអោយចងចាំថាទាំងនេះគឺជា tuples មិនមែន bytes ដូច្នេះយើងមិនអាចធ្វើវាត្រឹមជាបៃទេ។

ដោយផ្អែកលើទិន្នន័យនេះ យើងអាចបង្កើតអ្វីដែលគេហៅថាតារាង TopN ។ ឧទាហរណ៍ Top-5, Top-10 ។ ហើយ​អ្នក​អាច​តាម​ដាន​តុ​ក្តៅ​ទាំងនោះ​ដែល​ត្រូវ​បាន​កែច្នៃ​ច្រើន​ជាង​កន្លែង​ផ្សេង​ទៀត។ ឧទាហរណ៍ 5 តារាង "ក្តៅ" សម្រាប់ការបញ្ចូល។ ហើយការប្រើតារាង TopN ទាំងនេះ យើងវាយតម្លៃបន្ទុកការងាររបស់យើង ហើយអាចវាយតម្លៃបន្ទុកការងារបន្ទាប់ពីការចេញផ្សាយ ការអាប់ដេត និងការដាក់ឱ្យប្រើប្រាស់ណាមួយ។

វាក៏សំខាន់ផងដែរក្នុងការវាយតម្លៃទំហំនៃតារាង ព្រោះពេលខ្លះអ្នកអភិវឌ្ឍន៍បញ្ចេញមុខងារថ្មី ហើយតារាងរបស់យើងចាប់ផ្តើមហើមក្នុងទំហំធំ ដោយសារពួកគេបានសម្រេចចិត្តបន្ថែមចំនួនទិន្នន័យបន្ថែម ប៉ុន្តែមិនបានទាយថាតើវានឹងទៅជាយ៉ាងណានោះទេ។ ប៉ះពាល់ដល់ទំហំមូលដ្ឋានទិន្នន័យ។ ករណី​បែប​នេះ​ក៏​ធ្វើ​ឱ្យ​យើង​ភ្ញាក់​ផ្អើល​ផង​ដែរ។

ហើយឥឡូវនេះសំណួរតូចមួយសម្រាប់អ្នក។ តើ​មាន​សំណួរ​អ្វី​កើតឡើង​នៅ​ពេល​អ្នក​សម្គាល់​ឃើញ​ការ​ផ្ទុក​នៅ​លើ​ម៉ាស៊ីន​បម្រើ​មូលដ្ឋាន​ទិន្នន័យ​របស់​អ្នក? តើអ្នកមានសំណួរអ្វីបន្ទាប់?

ប៉ុន្តែការពិតសំណួរកើតឡើងដូចខាងក្រោម។ តើបន្ទុកបណ្តាលឱ្យមានសំណើអ្វីខ្លះ? នោះគឺវាមិនគួរឱ្យចាប់អារម្មណ៍ក្នុងការមើលដំណើរការដែលបណ្តាលមកពីបន្ទុកនោះទេ។ វាច្បាស់ណាស់ថាប្រសិនបើម៉ាស៊ីនមានមូលដ្ឋានទិន្នន័យ នោះមូលដ្ឋានទិន្នន័យកំពុងដំណើរការនៅទីនោះ ហើយវាច្បាស់ណាស់ថាមានតែមូលដ្ឋានទិន្នន័យប៉ុណ្ណោះដែលនឹងត្រូវបោះចោលនៅទីនោះ។ ប្រសិនបើយើងបើក Top យើងនឹងឃើញមានបញ្ជីនៃដំណើរការនៅក្នុង PostgreSQL ដែលកំពុងធ្វើអ្វីមួយ។ វា​នឹង​មិន​ច្បាស់​ពី​កំពូល​ថា​ពួកគេ​កំពុង​ធ្វើ​អ្វី​ទេ។

ដូច្នោះហើយ អ្នកត្រូវស្វែងរកសំណួរទាំងនោះដែលបណ្តាលឱ្យមានបន្ទុកខ្ពស់បំផុត ពីព្រោះការលៃតម្រូវសំណួរជាក្បួនផ្តល់ប្រាក់ចំណេញច្រើនជាងការលៃតម្រូវការកំណត់រចនាសម្ព័ន្ធ PostgreSQL ឬប្រព័ន្ធប្រតិបត្តិការ ឬសូម្បីតែលៃតម្រូវផ្នែករឹង។ យោងតាមការប៉ាន់ស្មានរបស់ខ្ញុំនេះគឺប្រហែល 80-85-90% ។ ហើយនេះត្រូវបានធ្វើលឿនជាងមុន។ វាលឿនជាងមុនក្នុងការកែតម្រូវសំណើជាជាងកែតម្រូវការកំណត់ កំណត់ពេលចាប់ផ្ដើមឡើងវិញ ជាពិសេសប្រសិនបើមូលដ្ឋានទិន្នន័យមិនអាចចាប់ផ្តើមឡើងវិញ ឬបន្ថែមផ្នែករឹង។ វាកាន់តែងាយស្រួលក្នុងការសរសេរសំណួរនៅកន្លែងណាមួយ ឬបន្ថែមលិបិក្រមដើម្បីទទួលបានលទ្ធផលប្រសើរជាងមុនពីសំណួរនេះ។

ដូច្នោះហើយ ចាំបាច់ត្រូវត្រួតពិនិត្យសំណើ និងភាពគ្រប់គ្រាន់របស់ពួកគេ។ សូមលើកឧទាហរណ៍មួយទៀតនៃការត្រួតពិនិត្យ។ ហើយនៅទីនេះផងដែរ ហាក់ដូចជាមានការត្រួតពិនិត្យដ៏ល្អ។ មានព័ត៍មានស្តីពីការចម្លង មានព័ត៍មានស្តីពីឆ្លងកាត់ ការទប់ស្កាត់ ការប្រើប្រាស់ធនធាន។ អ្វីៗគឺល្អ ប៉ុន្តែមិនមានព័ត៌មានអំពីសំណើទេ។ វាមិនច្បាស់ទេថាតើសំណួរអ្វីខ្លះដែលកំពុងដំណើរការនៅក្នុងមូលដ្ឋានទិន្នន័យរបស់យើង រយៈពេលដែលពួកគេកំពុងដំណើរការ តើសំណួរទាំងនេះមានចំនួនប៉ុន្មាន។ យើងត្រូវតែមានព័ត៌មាននេះជានិច្ចនៅក្នុងការត្រួតពិនិត្យរបស់យើង។

ហើយដើម្បីទទួលបានព័ត៌មាននេះ យើងអាចប្រើម៉ូឌុល pg_stat_statements ។ ដោយផ្អែកលើវា អ្នកអាចបង្កើតក្រាហ្វផ្សេងៗ។ ឧទាហរណ៍ អ្នកអាចទទួលបានព័ត៌មានអំពីសំណួរញឹកញាប់បំផុត នោះគឺនៅលើសំណួរទាំងនោះដែលត្រូវបានប្រតិបត្តិញឹកញាប់បំផុត។ បាទ/ចាស បន្ទាប់ពីការដាក់ឱ្យប្រើប្រាស់ វាមានប្រយោជន៍ខ្លាំងណាស់ក្នុងការមើលវា ហើយយល់ថាតើមានការកើនឡើងនៅក្នុងសំណើ។

អ្នកអាចតាមដានសំណួរដែលវែងបំផុត នោះគឺសំណួរទាំងនោះដែលចំណាយពេលយូរបំផុតដើម្បីបញ្ចប់។ ពួកគេដំណើរការលើ processor ពួកគេប្រើប្រាស់ I/O ។ យើងក៏អាចវាយតម្លៃវាដោយប្រើវាល total_time, mean_time, blk_write_time និង blk_read_time ។

យើងអាចវាយតម្លៃ និងត្រួតពិនិត្យសំណើដែលធ្ងន់បំផុតក្នុងលក្ខខណ្ឌនៃការប្រើប្រាស់ធនធាន ដែលអានពីថាស ដែលដំណើរការជាមួយអង្គចងចាំ ឬផ្ទុយទៅវិញ បង្កើតប្រភេទនៃការសរសេរមួយចំនួន។

យើងអាចវាយតម្លៃសំណើដ៏សប្បុរសបំផុត។ ទាំងនេះគឺជាសំណួរដែលត្រឡប់ជួរមួយចំនួនធំ។ ឧទាហរណ៍ នេះអាចជាសំណើមួយចំនួនដែលពួកគេភ្លេចកំណត់ដែនកំណត់។ ហើយវាគ្រាន់តែត្រឡប់មាតិកាទាំងមូលនៃតារាង ឬសំណួរឆ្លងកាត់តារាងដែលបានសួរ។

ហើយអ្នកក៏អាចត្រួតពិនិត្យសំណួរដែលប្រើឯកសារបណ្តោះអាសន្ន ឬតារាងបណ្តោះអាសន្នផងដែរ។

ហើយយើងនៅតែមានដំណើរការផ្ទៃខាងក្រោយ។ ដំណើរការផ្ទៃខាងក្រោយគឺជាចំណុចត្រួតពិនិត្យជាចម្បង ឬពួកគេត្រូវបានគេហៅថាប៉ុស្តិ៍ត្រួតពិនិត្យផងដែរ ទាំងនេះគឺជា autovacuum និងការចម្លង។

ឧទាហរណ៍មួយទៀតនៃការត្រួតពិនិត្យ។ មានផ្ទាំងថែទាំនៅខាងឆ្វេង សូមចូលទៅកាន់វា ហើយសង្ឃឹមថានឹងឃើញអ្វីដែលមានប្រយោជន៍។ ប៉ុន្តែនៅទីនេះគ្រាន់តែជាពេលវេលានៃប្រតិបត្តិការបូមធូលី និងការប្រមូលស្ថិតិប៉ុណ្ណោះ គ្មានអ្វីទៀតទេ។ នេះគឺជាព័ត៌មានមិនល្អខ្លាំងណាស់ ដូច្នេះយើងត្រូវតែមានព័ត៌មានអំពីរបៀបដែលដំណើរការផ្ទៃខាងក្រោយដំណើរការនៅក្នុងមូលដ្ឋានទិន្នន័យរបស់យើង និងថាតើមានបញ្ហាអ្វីពីការងាររបស់ពួកគេ។

នៅពេលយើងមើលប៉ុស្តិ៍ត្រួតពិនិត្យ យើងគួរចងចាំថា ប៉ុស្តិ៍ត្រួតពិនិត្យ លុបទំព័រកខ្វក់ពីតំបន់អង្គចងចាំដែលបានបំបែកទៅជាថាស បន្ទាប់មកបង្កើតចំណុចត្រួតពិនិត្យ។ ហើយប៉ុស្តិ៍ត្រួតពិនិត្យនេះអាចត្រូវបានប្រើជាកន្លែងសម្រាប់ការស្តារឡើងវិញ ប្រសិនបើ PostgreSQL ត្រូវបានបញ្ចប់ភ្លាមៗក្នុងគ្រាអាសន្ន។

ដូច្នោះហើយ ដើម្បីលុបទំព័រ "កខ្វក់" ទាំងអស់ទៅក្នុងថាស អ្នកត្រូវធ្វើចំនួនជាក់លាក់នៃការសរសេរ។ ហើយជាក្បួននៅលើប្រព័ន្ធដែលមានអង្គចងចាំធំ នេះគឺមានច្រើន។ ហើយប្រសិនបើយើងធ្វើការឆែកឆេរជាញឹកញាប់ក្នុងចន្លោះពេលខ្លី នោះដំណើរការឌីសនឹងធ្លាក់ចុះយ៉ាងខ្លាំង។ ហើយសំណើរបស់អតិថិជននឹងទទួលរងពីការខ្វះខាតធនធាន។ ពួកគេនឹងប្រកួតប្រជែងដើម្បីធនធាន និងខ្វះផលិតភាព។

ដូច្នោះហើយ តាមរយៈ pg_stat_bgwriter ដោយប្រើវាលដែលបានបញ្ជាក់ យើងអាចត្រួតពិនិត្យចំនួនចំណុចត្រួតពិនិត្យដែលកើតឡើង។ ហើយប្រសិនបើយើងមានប៉ុស្តិ៍ត្រួតពិនិត្យច្រើនក្នុងរយៈពេលជាក់លាក់មួយ (ក្នុងរយៈពេល 10-15-20 នាទីក្នុងរយៈពេលកន្លះម៉ោង) ឧទាហរណ៍ 3-4-5 នោះវាអាចជាបញ្ហារួចទៅហើយ។ ហើយអ្នកត្រូវរកមើលនៅក្នុងមូលដ្ឋានទិន្នន័យរួចហើយ រកមើលនៅក្នុងការកំណត់ តើអ្វីដែលបណ្តាលឱ្យមានច្រកត្រួតពិនិត្យបែបនេះ។ ប្រហែល​ជា​មាន​ការ​ថត​រឿង​ធំ​មួយ​កំពុង​បន្ត។ យើង​អាច​វាយ​តម្លៃ​បន្ទុក​ការងារ​បាន​ហើយ ព្រោះ​យើង​បាន​បន្ថែម​ក្រាហ្វ​បន្ទុក​ការងារ​រួច​ហើយ។ យើង​អាច​កែប្រែ​ប៉ារ៉ាម៉ែត្រ​ចំណុច​ត្រួតពិនិត្យ​បាន​ហើយ ហើយ​ធ្វើ​ឱ្យ​ប្រាកដ​ថា​ពួកវា​មិន​ប៉ះពាល់​ខ្លាំង​ដល់​ដំណើរការ​សំណួរ។

ខ្ញុំត្រលប់មក autovacuum ម្តងទៀតព្រោះវាជារឿងដូចដែលខ្ញុំបាននិយាយ ដែលអាចបន្ថែមទាំងដំណើរការ disk និង query បានយ៉ាងងាយស្រួល ដូច្នេះវាតែងតែមានសារៈសំខាន់ក្នុងការប៉ាន់ប្រមាណបរិមាណ autovacuum ។

ចំនួនបុគ្គលិក autovacuum នៅក្នុងមូលដ្ឋានទិន្នន័យមានកំណត់។ តាមលំនាំដើម វាមានបីនាក់ ដូច្នេះប្រសិនបើយើងតែងតែមានកម្មករ XNUMX នាក់ធ្វើការនៅក្នុងមូលដ្ឋានទិន្នន័យ នេះមានន័យថា autovacuum របស់យើងមិនត្រូវបានកំណត់រចនាសម្ព័ន្ធទេ យើងត្រូវបង្កើនដែនកំណត់ កែប្រែការកំណត់ autovacuum និងចូលទៅក្នុងការកំណត់។
វាមានសារៈសំខាន់ណាស់ក្នុងការវាយតម្លៃថាតើបុគ្គលិកបូមធូលីណាដែលយើងមាន។ ទាំងវាត្រូវបានចាប់ផ្តើមពីអ្នកប្រើប្រាស់ DBA បានមក និងបើកដំណើរការម៉ាស៊ីនបូមធូលីមួយចំនួនដោយដៃ ហើយវាបានបង្កើតបន្ទុកមួយ។ យើងមានបញ្ហាមួយចំនួន។ ឬនេះគឺជាចំនួននៃការខ្វះចន្លោះដែល unscrew បញ្ជរប្រតិបត្តិការ។ សម្រាប់កំណែមួយចំនួននៃ PostgreSQL ទាំងនេះគឺជាកន្លែងទំនេរខ្លាំង។ ហើយពួកគេអាចបន្ថែមការសម្តែងបានយ៉ាងងាយស្រួល ដោយសារពួកគេអានតារាងទាំងមូល ស្កេនគ្រប់ប្លុកនៅក្នុងតារាងនោះ។

ហើយជាការពិតណាស់រយៈពេលនៃការបូមធូលី។ ប្រសិនបើយើងមានម៉ាស៊ីនបូមធូលីដែលមានរយៈពេលយូរ ដែលដំណើរការក្នុងរយៈពេលយូរ នោះមានន័យថា យើងត្រូវយកចិត្តទុកដាក់ម្តងទៀតចំពោះការកំណត់ម៉ាស៊ីនបូមធូលី ហើយប្រហែលជាពិចារណាឡើងវិញនូវការកំណត់របស់វា។ ដោយសារតែស្ថានភាពមួយអាចកើតឡើងនៅពេលដែលកន្លែងទំនេរធ្វើការនៅលើតុរយៈពេលយូរ (3-4 ម៉ោង) ប៉ុន្តែក្នុងអំឡុងពេលដែលម៉ាស៊ីនបូមធូលីកំពុងដំណើរការ ជួរដែលងាប់មួយចំនួនធំបានប្រមូលផ្តុំនៅក្នុងតុម្តងទៀត។ ហើយដរាបណាការបូមធូលីត្រូវបានបញ្ចប់ គាត់ត្រូវបូមធូលីតារាងនេះម្តងទៀត។ ហើយយើងមកដល់ស្ថានភាពមួយ - កន្លែងទំនេរគ្មានទីបញ្ចប់។ ហើយក្នុងករណីនេះម៉ាស៊ីនបូមធូលីមិនអាចទប់ទល់នឹងការងាររបស់វាបានទេហើយតារាងចាប់ផ្តើមហើមបន្តិចម្តង ៗ ទោះបីជាបរិមាណនៃទិន្នន័យមានប្រយោជន៍នៅក្នុងវានៅតែដដែល។ ដូច្នេះក្នុងអំឡុងពេលទំនេរយូរ យើងតែងតែមើលការកំណត់រចនាសម្ព័ន្ធ ហើយព្យាយាមបង្កើនប្រសិទ្ធភាពវា ប៉ុន្តែនៅពេលជាមួយគ្នានេះ ដើម្បីឱ្យដំណើរការនៃសំណើរបស់អតិថិជនមិនរងទុក្ខ។

សព្វថ្ងៃនេះមិនមានការដំឡើង PostgreSQL ដែលមិនមានការចម្លងស្ទ្រីមទេ។ ការចម្លងគឺជាដំណើរការនៃការផ្លាស់ប្តូរទិន្នន័យពីមេទៅចម្លង។

ការចម្លងនៅក្នុង PostgreSQL ត្រូវបានធ្វើឡើងតាមរយៈកំណត់ហេតុប្រតិបត្តិការ។ អ្នកជំនួយបង្កើតកំណត់ហេតុប្រតិបត្តិការ។ កំណត់ហេតុប្រតិបត្តិការធ្វើដំណើរលើការភ្ជាប់បណ្តាញទៅឧបករណ៍ចម្លង ហើយបន្ទាប់មកវាត្រូវបានបង្កើតឡើងវិញនៅលើការចម្លង។ វាសាមញ្ញ។

ដូច្នោះហើយ ទិដ្ឋភាព pg_stat_replication ត្រូវបានប្រើដើម្បីតាមដានភាពយឺតយ៉ាវនៃការចម្លង។ ប៉ុន្តែមិនមែនអ្វីៗទាំងអស់គឺសាមញ្ញជាមួយនាងទេ។ នៅក្នុងកំណែទី 10 ទិដ្ឋភាពបានឆ្លងកាត់ការផ្លាស់ប្តូរជាច្រើន។ ទីមួយ វាលមួយចំនួនត្រូវបានប្តូរឈ្មោះ។ ហើយ​វាល​មួយ​ចំនួន​ត្រូវ​បាន​បន្ថែម។ នៅក្នុងកំណែ 10 វាលបានលេចឡើងដែលអនុញ្ញាតឱ្យអ្នកប៉ាន់ស្មានភាពយឺតយ៉ាវនៃការចម្លងក្នុងរយៈពេលប៉ុន្មានវិនាទី។ វាមានផាសុកភាពណាស់។ មុនពេលកំណែ 10 វាអាចប៉ាន់ស្មានភាពយឺតយ៉ាវនៃការចម្លងជាបៃ។ ជម្រើសនេះនៅតែមាននៅក្នុងកំណែ 10 ពោលគឺអ្នកអាចជ្រើសរើសអ្វីដែលកាន់តែងាយស្រួលសម្រាប់អ្នក - ប៉ាន់ប្រមាណភាពយឺតយ៉ាវជាបៃ ឬប៉ាន់ស្មានភាពយឺតយ៉ាវក្នុងរយៈពេលប៉ុន្មានវិនាទី។ មនុស្សជាច្រើនធ្វើទាំងពីរ។

ប៉ុន្តែយ៉ាងណាក៏ដោយ ដើម្បីវាយតម្លៃភាពយឺតយ៉ាវនៃការចម្លង អ្នកត្រូវដឹងពីទីតាំងនៃកំណត់ហេតុក្នុងប្រតិបត្តិការ។ ហើយទីតាំងកំណត់ហេតុប្រតិបត្តិការទាំងនេះគឺពិតជានៅក្នុងទិដ្ឋភាព pg_stat_replication ។ បើនិយាយទាក់ទងគ្នា យើងអាចយកពីរចំណុចក្នុងកំណត់ហេតុប្រតិបត្តិការដោយប្រើមុខងារ pg_xlog_location_diff() ។ គណនា delta រវាងពួកវា និងទទួលបានភាពយឺតយ៉ាវនៃការចម្លងជាបៃ។ វាងាយស្រួល និងសាមញ្ញណាស់។

នៅក្នុងកំណែ 10 មុខងារនេះត្រូវបានប្តូរឈ្មោះទៅជា pg_wal_lsn_diff()។ ជាទូទៅ នៅក្នុងមុខងារ ទិដ្ឋភាព និងឧបករណ៍ប្រើប្រាស់ទាំងអស់ ដែលពាក្យ "xlog" លេចឡើង វាត្រូវបានជំនួសដោយតម្លៃ "wal" ។ នេះអនុវត្តទាំងទិដ្ឋភាព និងមុខងារ។ នេះគឺជាការច្នៃប្រឌិតបែបនេះ។

លើសពីនេះទៀតនៅក្នុងកំណែ 10 បន្ទាត់ត្រូវបានបន្ថែមដែលបង្ហាញពីភាពយឺតយ៉ាវ។ ទាំងនេះ​ជា​ការ​សរសេរ​យឺត, យឺត, លេង​យឺត។ នោះគឺវាមានសារៈសំខាន់ណាស់ក្នុងការត្រួតពិនិត្យរឿងទាំងនេះ។ ប្រសិនបើយើងឃើញថាយើងមានការយឺតយ៉ាវក្នុងការចម្លង នោះយើងត្រូវស៊ើបអង្កេតពីមូលហេតុដែលវាលេចឡើង តើវាមកពីណា ហើយដោះស្រាយបញ្ហានោះ។

ស្ទើរតែអ្វីៗទាំងអស់គឺស្ថិតនៅក្នុងលំដាប់ជាមួយនឹងរង្វាស់ប្រព័ន្ធ។ នៅពេលដែលការត្រួតពិនិត្យណាមួយចាប់ផ្តើម វាចាប់ផ្តើមជាមួយនឹងការវាស់វែងប្រព័ន្ធ។ នេះគឺជាការចោលនូវ processors, memory, swap, network និង disk។ ទោះយ៉ាងណាក៏ដោយ ប៉ារ៉ាម៉ែត្រជាច្រើនមិនមាននៅទីនោះតាមលំនាំដើមទេ។

ប្រសិនបើអ្វីៗមានសណ្តាប់ធ្នាប់ជាមួយនឹងដំណើរការកែច្នៃឡើងវិញនោះ មានបញ្ហាជាមួយនឹងការកែច្នៃថាស។ តាមក្បួនមួយ ការត្រួតពិនិត្យអ្នកអភិវឌ្ឍន៍បន្ថែមព័ត៌មានអំពីលំហូរចូល។ វាអាចជា iops ឬ bytes ។ ប៉ុន្តែពួកគេភ្លេចអំពីភាពយឺតយ៉ាវ និងការប្រើប្រាស់ឧបករណ៍ឌីស។ ទាំងនេះគឺជាប៉ារ៉ាម៉ែត្រសំខាន់ៗដែលអនុញ្ញាតឱ្យយើងវាយតម្លៃថាតើថាសរបស់យើងផ្ទុកបានកម្រិតណា និងយឺតប៉ុណ្ណា។ ប្រសិនបើយើងមានភាពយឺតយ៉ាវខ្ពស់ នោះមានន័យថាមានបញ្ហាមួយចំនួនជាមួយថាស។ ប្រសិនបើ​យើង​មាន​ការ​ប្រើ​ប្រាស់​ខ្ពស់ វា​មាន​ន័យ​ថា​ថាស​មិន​អាច​ទប់ទល់​បាន។ ទាំងនេះគឺជាលក្ខណៈប្រសើរជាងការបញ្ជូន។

ជាងនេះទៅទៀត ស្ថិតិទាំងនេះក៏អាចទទួលបានពីប្រព័ន្ធឯកសារ /proc ដូចដែលត្រូវបានធ្វើសម្រាប់ដំណើរការកែច្នៃឡើងវិញ។ ខ្ញុំមិនដឹងថាហេតុអ្វីបានជាព័ត៌មាននេះមិនត្រូវបានបញ្ចូលទៅក្នុងការត្រួតពិនិត្យនោះទេ។ ប៉ុន្តែទោះជាយ៉ាងនេះក្តី វាមានសារៈសំខាន់ណាស់ក្នុងការមានចំណុចនេះក្នុងការត្រួតពិនិត្យរបស់អ្នក។

ដូចគ្នានេះដែរអនុវត្តចំពោះចំណុចប្រទាក់បណ្តាញ។ មានព័ត៌មានអំពីការបញ្ចូលបណ្តាញនៅក្នុងកញ្ចប់ព័ត៌មានជាបៃ ប៉ុន្តែទោះជាយ៉ាងណាមិនមានព័ត៌មានអំពីភាពយឺតយ៉ាវ និងគ្មានព័ត៌មានអំពីការប្រើប្រាស់ ទោះបីជានេះក៏ជាព័ត៌មានមានប្រយោជន៍ផងដែរ។

ការត្រួតពិនិត្យណាមួយមានគុណវិបត្តិ។ ហើយ​មិន​ថា​អ្នក​ធ្វើ​ការ​ត្រួត​ពិនិត្យ​បែប​ណា​នោះ​ទេ វា​តែង​តែ​មិន​បំពេញ​តាម​លក្ខណៈ​វិនិច្ឆ័យ​មួយ​ចំនួន។ ប៉ុន្តែយ៉ាងណាក៏ដោយ ពួកគេកំពុងអភិវឌ្ឍ មុខងារថ្មីៗ និងរបស់ថ្មីកំពុងត្រូវបានបន្ថែម ដូច្នេះសូមជ្រើសរើសអ្វីមួយ ហើយបញ្ចប់វា។

ហើយដើម្បីបញ្ចប់ អ្នកត្រូវតែមានគំនិតជានិច្ចអំពីអ្វីដែលស្ថិតិដែលបានផ្តល់មានន័យ និងរបៀបដែលអ្នកអាចប្រើពួកវាដើម្បីដោះស្រាយបញ្ហា។

និងចំណុចសំខាន់ៗមួយចំនួន៖

• អ្នកគួរតែតាមដានភាពអាចរកបានជានិច្ច និងមានផ្ទាំងគ្រប់គ្រង ដូច្នេះអ្នកអាចវាយតម្លៃបានយ៉ាងឆាប់រហ័សថាអ្វីៗគ្រប់យ៉ាងស្ថិតក្នុងលំដាប់ជាមួយនឹងមូលដ្ឋានទិន្នន័យ។
• អ្នកតែងតែត្រូវមានគំនិតអំពីអ្វីដែលអតិថិជនកំពុងធ្វើការជាមួយមូលដ្ឋានទិន្នន័យរបស់អ្នក ដើម្បីកម្ចាត់អតិថិជនអាក្រក់ និងបាញ់ទម្លាក់ពួកគេ។
• វាមានសារៈសំខាន់ណាស់ក្នុងការវាយតម្លៃពីរបៀបដែលអតិថិជនទាំងនេះធ្វើការជាមួយទិន្នន័យ។ អ្នកត្រូវមានគំនិតអំពីបន្ទុកការងាររបស់អ្នក។
• វាចាំបាច់ក្នុងការវាយតម្លៃពីរបៀបដែលបន្ទុកការងារនេះត្រូវបានបង្កើតឡើង ដោយមានជំនួយពីសំណួរអ្វី។ អ្នកអាចវាយតម្លៃសំណួរ អ្នកអាចបង្កើនប្រសិទ្ធភាពពួកវា កែលម្អពួកវា បង្កើតលិបិក្រមសម្រាប់ពួកគេ។ វា​ពិតជា​សំខាន់ណាស់។
• ដំណើរការផ្ទៃខាងក្រោយអាចជះឥទ្ធិពលអវិជ្ជមានដល់សំណើរបស់អតិថិជន ដូច្នេះវាមានសារៈសំខាន់ណាស់ក្នុងការត្រួតពិនិត្យថាពួកគេមិនប្រើប្រាស់ធនធានច្រើនពេកទេ។
• រង្វាស់ប្រព័ន្ធអនុញ្ញាតឱ្យអ្នកធ្វើផែនការសម្រាប់ធ្វើមាត្រដ្ឋាន និងបង្កើនសមត្ថភាពម៉ាស៊ីនមេរបស់អ្នក ដូច្នេះវាជាការសំខាន់ក្នុងការតាមដាន និងវាយតម្លៃពួកវាផងដែរ។

ប្រសិនបើអ្នកចាប់អារម្មណ៍លើប្រធានបទនេះ អ្នកអាចធ្វើតាមតំណទាំងនេះ។
http://bit.do/stats_collector - នេះគឺជាឯកសារផ្លូវការពីអ្នកប្រមូលស្ថិតិ។ មានការពិពណ៌នាអំពីទិដ្ឋភាពស្ថិតិទាំងអស់ និងការពិពណ៌នាអំពីវាលទាំងអស់។ អ្នកអាចអាន យល់ និងវិភាគពួកគេ។ ហើយផ្អែកលើពួកវា បង្កើតក្រាហ្វរបស់អ្នក ហើយបន្ថែមវាទៅក្នុងការត្រួតពិនិត្យរបស់អ្នក។

សំណើឧទាហរណ៍៖
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

នេះជាឃ្លាំងសាជីវកម្មរបស់យើង និងផ្ទាល់ខ្លួនរបស់ខ្ញុំ។ ពួកវាមានសំណួរឧទាហរណ៍។ មិនមានសំណួរពីការជ្រើសរើស* ពីស៊េរីនៅទីនោះទេ។ មានសំណួរដែលត្រៀមរួចជាស្រេចជាមួយនឹងការភ្ជាប់ ដោយប្រើមុខងារគួរឱ្យចាប់អារម្មណ៍ដែលអនុញ្ញាតឱ្យអ្នកប្រែក្លាយលេខឆៅទៅជាតម្លៃដែលអាចអានបាន ងាយស្រួល ពោលគឺទាំងនេះជាបៃ ពេលវេលា។ អ្នកអាចយកវាឡើង មើលពួកវា វិភាគពួកវា បន្ថែមពួកវាទៅក្នុងការត្រួតពិនិត្យរបស់អ្នក បង្កើតការត្រួតពិនិត្យរបស់អ្នកដោយផ្អែកលើពួកគេ។

សំណួរ

សំណួរ៖ អ្នក​បាន​និយាយ​ថា​អ្នក​នឹង​មិន​ផ្សាយ​ពាណិជ្ជកម្ម​ម៉ាក ប៉ុន្តែ​ខ្ញុំ​នៅ​តែ​ចង់​ដឹង​ថា តើ​ផ្ទាំង​គ្រប់គ្រង​ប្រភេទ​ណា​ដែល​អ្នក​ប្រើ​ក្នុង​គម្រោង​របស់​អ្នក?
ចម្លើយ៖ វាប្រែប្រួល។ វាកើតឡើងថាយើងមករកអតិថិជនហើយគាត់មានការត្រួតពិនិត្យផ្ទាល់ខ្លួនរបស់គាត់រួចហើយ។ ហើយយើងណែនាំអតិថិជនអំពីអ្វីដែលត្រូវបន្ថែមទៅការត្រួតពិនិត្យរបស់ពួកគេ។ ស្ថានភាពដ៏អាក្រក់បំផុតគឺជាមួយ Zabbix ។ ដោយសារតែវាមិនមានសមត្ថភាពក្នុងការបង្កើតក្រាហ្វ TopN ។ យើងខ្លួនយើងប្រើ Okmeterដោយ​សារ​យើង​បាន​ប្រឹក្សា​ជាមួយ​អ្នក​ទាំង​នេះ​លើ​ការ​ត្រួត​ពិនិត្យ។ ពួកគេបានត្រួតពិនិត្យ PostgreSQL ដោយផ្អែកលើលក្ខណៈបច្ចេកទេសរបស់យើង។ ខ្ញុំកំពុងសរសេរគម្រោងសត្វចិញ្ចឹមផ្ទាល់ខ្លួនរបស់ខ្ញុំ ដែលប្រមូលទិន្នន័យតាមរយៈ Prometheus ហើយបង្ហាញវានៅក្នុង ហ្គ្រេណាណា. ភារកិច្ចរបស់ខ្ញុំគឺបង្កើតអ្នកនាំចេញផ្ទាល់ខ្លួនរបស់ខ្ញុំនៅក្នុង Prometheus ហើយបន្ទាប់មកបង្ហាញអ្វីគ្រប់យ៉ាងនៅក្នុង Grafana ។

សំណួរ៖ តើមាន analogues នៃរបាយការណ៍ AWR ឬ... សរុបដែរឬទេ? ដឹងរឿងបែបនេះទេ?
ចម្លើយ៖ បាទ ខ្ញុំដឹងថា AWR ជាអ្វី វាជារឿងល្អមួយ។ នៅ​ពេល​នេះ មាន​កង់​ជា​ច្រើន​ប្រភេទ​ដែល​អនុវត្ត​ប្រមាណ​ជា​គំរូ​ដូច​ខាង​ក្រោម។ នៅចន្លោះពេលខ្លះ បន្ទាត់មូលដ្ឋានមួយចំនួនត្រូវបានសរសេរទៅ PostgreSQL ដូចគ្នា ឬទៅកន្លែងផ្ទុកដាច់ដោយឡែក។ អ្នកអាច google ពួកគេនៅលើអ៊ីនធឺណិត ពួកគេនៅទីនោះ។ អ្នកអភិវឌ្ឍន៍ម្នាក់នៃរឿងបែបនេះកំពុងអង្គុយនៅលើវេទិកា sql.ru នៅក្នុងខ្សែស្រឡាយ PostgreSQL ។ អ្នកអាចចាប់គាត់នៅទីនោះ។ បាទ មានរបស់បែបនេះ គេអាចប្រើប្រាស់បាន។ បូកនៅក្នុងរបស់វា។ pgCenter ខ្ញុំក៏កំពុងសរសេររឿងមួយដែលអនុញ្ញាតឱ្យអ្នកធ្វើរឿងដូចគ្នា។

PS1 ប្រសិនបើអ្នកប្រើ postgres_exporter តើអ្នកកំពុងប្រើ dashboard អ្វី? មានពួកគេមួយចំនួន។ ពួកវាហួសសម័យហើយ។ ប្រហែលជាសហគមន៍នឹងបង្កើតគំរូដែលបានធ្វើបច្ចុប្បន្នភាព?

PS2 បានយកចេញ pganalze ព្រោះវាគឺជាការផ្តល់ជូន SaaS ដែលមានកម្មសិទ្ធិដែលផ្តោតលើការត្រួតពិនិត្យការអនុវត្ត និងការផ្ដល់យោបល់ការលៃតម្រូវដោយស្វ័យប្រវត្តិ។

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើការត្រួតពិនិត្យ postgresql ដែលបង្ហោះដោយខ្លួនឯង (ជាមួយផ្ទាំងគ្រប់គ្រង) តើអ្នកចាត់ទុកថាល្អបំផុត?

• 30,0%Zabbix + ការបន្ថែមពី Alexey Lesovsky ឬ zabbix 4.4 ឬ libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze គឺជា SaaS ដែលមានកម្មសិទ្ធិ - ខ្ញុំមិនអាចលុបវាបានទេ 1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

អ្នកប្រើប្រាស់ 10 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ១៤ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com