ការបង្កើនប្រសិទ្ធភាពភាគច្រើននៃសំណួរ PostgreSQL ។ Kirill Borovikov (Tensor)

របាយការណ៍បង្ហាញពីវិធីសាស្រ្តមួយចំនួនដែលអនុញ្ញាត តាមដានដំណើរការនៃសំណួរ SQL នៅពេលដែលមានពួកគេរាប់លានក្នុងមួយថ្ងៃហើយមានម៉ាស៊ីនមេ PostgreSQL រាប់រយដែលត្រូវបានត្រួតពិនិត្យ។

តើដំណោះស្រាយបច្ចេកទេសអ្វីខ្លះដែលអនុញ្ញាតឱ្យយើងដំណើរការបរិមាណនៃព័ត៌មានបែបនេះប្រកបដោយប្រសិទ្ធភាព ហើយតើវាធ្វើឱ្យជីវិតរបស់អ្នកអភិវឌ្ឍន៍ធម្មតាងាយស្រួលជាងមុនដោយរបៀបណា?

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


ឈ្មោះរបស់ខ្ញុំគឺ Kirill Borovikov ខ្ញុំតំណាង ក្រុមហ៊ុន Tensor. ជាពិសេស ខ្ញុំមានជំនាញក្នុងការធ្វើការជាមួយមូលដ្ឋានទិន្នន័យនៅក្នុងក្រុមហ៊ុនរបស់យើង។

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

ជាទូទៅ Tensor សម្រាប់អតិថិជនមួយលាននាក់របស់យើងគឺ VLSI គឺជាកម្មវិធីរបស់យើង។៖ បណ្តាញសង្គមសាជីវកម្ម ដំណោះស្រាយសម្រាប់ការទំនាក់ទំនងតាមវីដេអូ សម្រាប់លំហូរឯកសារខាងក្នុង និងខាងក្រៅ ប្រព័ន្ធគណនេយ្យសម្រាប់គណនេយ្យ និងឃ្លាំង... នោះគឺជា "ការរួមបញ្ចូលគ្នាដ៏ធំ" សម្រាប់ការគ្រប់គ្រងអាជីវកម្មរួមបញ្ចូលគ្នា ដែលក្នុងនោះមានច្រើនជាង 100 ផ្សេងៗគ្នា។ គម្រោងផ្ទៃក្នុង។

ដើម្បីធានាថាពួកគេទាំងអស់ដំណើរការ និងអភិវឌ្ឍជាធម្មតា យើងមានមជ្ឈមណ្ឌលអភិវឌ្ឍន៍ចំនួន 10 នៅទូទាំងប្រទេស ដោយមានច្រើនទៀតនៅក្នុងពួកគេ។ អ្នកអភិវឌ្ឍន៍ 1000.

យើងបានធ្វើការជាមួយ PostgreSQL តាំងពីឆ្នាំ 2008 ហើយបានប្រមូលផ្តុំនូវចំនួនដ៏ច្រើននៃអ្វីដែលយើងដំណើរការ - ទិន្នន័យអតិថិជន ស្ថិតិ ការវិភាគ ទិន្នន័យពីប្រព័ន្ធព័ត៌មានខាងក្រៅ - ច្រើនជាង 400TB. មានម៉ាស៊ីនមេប្រហែល 250 នៅក្នុងការផលិតតែមួយ ហើយសរុបទៅមានម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យប្រហែល 1000 ដែលយើងត្រួតពិនិត្យ។

SQL គឺជាភាសាប្រកាស។ អ្នកពណ៌នាមិនមែន "របៀប" អ្វីមួយដែលគួរដំណើរការទេ ប៉ុន្តែ "អ្វី" ដែលអ្នកចង់សម្រេចបាន។ DBMS ដឹងកាន់តែច្បាស់ពីរបៀបបង្កើត JOIN - របៀបភ្ជាប់តារាងរបស់អ្នក លក្ខខណ្ឌដែលត្រូវដាក់ អ្វីនឹងឆ្លងកាត់លិបិក្រម អ្វីដែលនឹងមិន...

DBMSs មួយចំនួនទទួលយកព័ត៌មានជំនួយ៖ "ទេ ភ្ជាប់តារាងទាំងពីរនេះនៅក្នុងជួរបែបនេះ" ប៉ុន្តែ PostgreSQL មិនអាចធ្វើវាបានទេ។ នេះ​ជា​ជំហរ​ដឹង​ខ្លួន​របស់​អ្នក​អភិវឌ្ឍន៍​ឈាន​មុខ​គេ៖ "យើង​ចង់​បញ្ចប់​កម្មវិធី​បង្កើន​ប្រសិទ្ធភាព​សំណួរ ជាជាង​អនុញ្ញាត​ឱ្យ​អ្នក​អភិវឌ្ឍន៍​ប្រើ​តម្រុយ​មួយ​ចំនួន។"

ប៉ុន្តែទោះបីជាការពិតដែលថា PostgreSQL មិនអនុញ្ញាតឱ្យ "ខាងក្រៅ" គ្រប់គ្រងខ្លួនឯងក៏ដោយក៏វាអនុញ្ញាតយ៉ាងល្អឥតខ្ចោះ មើលអ្វីដែលកំពុងកើតឡើងនៅក្នុងគាត់នៅពេលអ្នកដំណើរការសំណួររបស់អ្នក និងកន្លែងដែលវាមានបញ្ហា។

ជាទូទៅ តើបញ្ហាបុរាណអ្វីខ្លះដែលអ្នកអភិវឌ្ឍន៍ [ទៅ DBA] តែងតែមកជាមួយ? “នៅទីនេះ យើងបានបំពេញសំណើរហើយ អ្វីគ្រប់យ៉ាងគឺយឺតជាមួយយើងអ្វីគ្រប់យ៉ាងកំពុងព្យួរ អ្វីមួយកំពុងកើតឡើង... បញ្ហាមួយចំនួន!”

ហេតុផលគឺស្ទើរតែតែងតែដូចគ្នា៖

• ក្បួនដោះស្រាយសំណួរគ្មានប្រសិទ្ធភាព
  អ្នកអភិវឌ្ឍន៍៖ "ឥឡូវនេះខ្ញុំកំពុងផ្តល់ឱ្យគាត់នូវតារាងចំនួន 10 នៅក្នុង SQL តាមរយៈ JOIN ... " - ហើយរំពឹងថាលក្ខខណ្ឌរបស់គាត់នឹងមានប្រសិទ្ធភាពដោយអព្ភូតហេតុ "ស្រាយ" ហើយគាត់នឹងទទួលបានអ្វីគ្រប់យ៉ាងយ៉ាងឆាប់រហ័ស។ ប៉ុន្តែអព្ភូតហេតុមិនកើតឡើងទេហើយប្រព័ន្ធណាមួយដែលមានការប្រែប្រួលបែបនេះ (10 តារាងក្នុងមួយ FROM) តែងតែផ្តល់នូវប្រភេទនៃកំហុសមួយចំនួន។ [អត្ថបទ]
• ស្ថិតិមិនពាក់ព័ន្ធ
  ចំណុចនេះគឺពាក់ព័ន្ធជាពិសេសសម្រាប់ PostgreSQL នៅពេលដែលអ្នក "ចាក់" សំណុំទិន្នន័យដ៏ធំមួយទៅលើម៉ាស៊ីនមេ ធ្វើការស្នើសុំ ហើយវា "រួមភេទ" កុំព្យូទ័របន្ទះរបស់អ្នក។ ដោយសារតែកាលពីម្សិលមិញមានកំណត់ត្រាចំនួន 10 នៅក្នុងនោះ ហើយថ្ងៃនេះមាន 10 លាននាក់ ប៉ុន្តែ PostgreSQL មិនទាន់ដឹងអំពីរឿងនេះទេ ហើយយើងត្រូវប្រាប់វាអំពីវា។ [អត្ថបទ]
• "ដោត" លើធនធាន
  អ្នក​បាន​ដំឡើង​មូលដ្ឋាន​ទិន្នន័យ​ធំ និង​ផ្ទុក​ខ្លាំង​លើ​ម៉ាស៊ីន​បម្រើ​ខ្សោយ ដែល​មិន​មាន​ដំណើរការ​គ្រប់គ្រាន់​នៃ​ថាស អង្គចងចាំ ឬ​ដំណើរការ​របស់​ដំណើរការ។ ហើយនោះហើយជាទាំងអស់ ... កន្លែងណាមួយមានពិដានការសម្តែងនៅខាងលើ ដែលអ្នកមិនអាចលោតបានទៀតទេ។
• ការទប់ស្កាត់
  នេះគឺជាចំណុចពិបាក ប៉ុន្តែពួកគេពាក់ព័ន្ធបំផុតសម្រាប់សំណួរកែប្រែផ្សេងៗ (បញ្ចូល អាប់ដេត លុប) - នេះគឺជាប្រធានបទធំដាច់ដោយឡែកមួយ។

ការទទួលបានផែនការ

... ហើយសម្រាប់អ្វីផ្សេងទៀតយើង ត្រូវការផែនការ! យើងត្រូវមើលអ្វីដែលកំពុងកើតឡើងនៅខាងក្នុងម៉ាស៊ីនមេ។

ផែនការប្រតិបត្តិសំណួរសម្រាប់ PostgreSQL គឺជាមែកធាងនៃក្បួនដោះស្រាយការប្រតិបត្តិសំណួរនៅក្នុងតំណាងអត្ថបទ។ វាច្បាស់ណាស់ថាជាក្បួនដោះស្រាយដែល ជាលទ្ធផលនៃការវិភាគដោយអ្នករៀបចំផែនការ ត្រូវបានរកឃើញថាមានប្រសិទ្ធភាពបំផុត។

ថ្នាំងមែកធាងនីមួយៗគឺជាប្រតិបត្តិការមួយ៖ ការទាញយកទិន្នន័យពីតារាង ឬលិបិក្រម ការកសាងផែនទីប៊ីត ការភ្ជាប់តារាងពីរ ការចូលរួម ការប្រសព្វគ្នា ឬការមិនរាប់បញ្ចូលការជ្រើសរើស។ ការប្រតិបត្តិសំណួរពាក់ព័ន្ធនឹងការដើរកាត់ថ្នាំងនៃមែកធាងនេះ។

ដើម្បីទទួលបានផែនការសំណួរ មធ្យោបាយងាយស្រួលបំផុតគឺអនុវត្តសេចក្តីថ្លែងការណ៍ EXPLAIN. ដើម្បីទទួលបានជាមួយនឹងគុណលក្ខណៈពិតទាំងអស់ នោះគឺជាការប្រតិបត្តិសំណួរនៅលើមូលដ្ឋាន - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

ផ្នែកអាក្រក់៖ នៅពេលអ្នកដំណើរការវា វាកើតឡើង "នៅទីនេះ និងឥឡូវនេះ" ដូច្នេះ វាសមរម្យសម្រាប់តែការកែកំហុសក្នុងតំបន់ប៉ុណ្ណោះ។ ប្រសិនបើអ្នកយកម៉ាស៊ីនមេដែលមានផ្ទុកខ្ពស់ដែលស្ថិតនៅក្រោមលំហូរខ្លាំងនៃការផ្លាស់ប្តូរទិន្នន័យ ហើយអ្នកឃើញ៖ “អូ! នៅទីនេះយើងមានការអនុវត្តយឺតសៀ សំណើ។" កន្លះម៉ោង មួយម៉ោងមុន - ខណៈពេលដែលអ្នកកំពុងដំណើរការ និងទទួលបានសំណើនេះពីកំណត់ហេតុ នាំវាត្រឡប់ទៅម៉ាស៊ីនមេវិញ សំណុំទិន្នន័យ និងស្ថិតិទាំងមូលរបស់អ្នកបានផ្លាស់ប្តូរ។ អ្នក​រត់​វា​ដើម្បី​បំបាត់​កំហុស - ហើយ​វា​រត់​យ៉ាង​លឿន! ហើយអ្នកមិនអាចយល់បានថាហេតុអ្វី? គឺ យ៉ាង​យឺត។

ដើម្បីយល់ពីអ្វីដែលបានកើតឡើងពិតប្រាកដនៅពេលសំណើត្រូវបានប្រតិបត្តិនៅលើម៉ាស៊ីនមេ មនុស្សឆ្លាតបានសរសេរ ម៉ូឌុល auto_explain. វាមានវត្តមាននៅក្នុងការចែកចាយ PostgreSQL ស្ទើរតែទាំងអស់ ហើយវាអាចត្រូវបានធ្វើឱ្យសកម្មនៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធ។

ប្រសិនបើវាដឹងថាសំណើមួយចំនួនដំណើរការយូរជាងដែនកំណត់ដែលអ្នកបានប្រាប់វា នោះវានឹងកើតឡើង "រូបថត" នៃផែនការនៃសំណើនេះ ហើយសរសេរពួកវាជាមួយគ្នានៅក្នុងកំណត់ហេតុ.

អ្វីៗហាក់ដូចជាល្អឥឡូវនេះ យើងទៅមើលកំណត់ហេតុនៅទីនោះ... [ text footcloth]។ ប៉ុន្តែ​យើង​មិន​អាច​និយាយ​អ្វី​អំពី​វា​បាន​ទេ ក្រៅ​ពី​ការ​ពិត​ថា​វា​ជា​គម្រោង​ដ៏​ល្អ​មួយ​ព្រោះ​វា​ចំណាយ​ពេល 11ms ដើម្បី​ប្រតិបត្តិ។

អ្វីៗ​ហាក់​ដូច​ជា​ល្អ ប៉ុន្តែ​មិន​មាន​អ្វី​ច្បាស់​លាស់​ថា​តើ​អ្វី​បាន​កើត​ឡើង​ពិត​ប្រាកដ។ ក្រៅពីពេលវេលាទូទៅ យើងពិតជាមិនឃើញអ្វីទាំងអស់។ ដោយសារតែការក្រឡេកមើល "សាច់ចៀម" នៃអត្ថបទធម្មតាជាទូទៅមិនអាចមើលឃើញទេ។

ប៉ុន្តែទោះបីជាវាមិនច្បាស់ក៏ដោយ ទោះបីជាវាមានការរអាក់រអួលក៏ដោយ ក៏មានបញ្ហាជាមូលដ្ឋានជាច្រើនទៀត៖

• ថ្នាំងចង្អុលបង្ហាញ ផលបូកនៃធនធាននៃមែកធាងរងទាំងមូល នៅក្រោមគាត់។ នោះគឺអ្នកមិនអាចរកឱ្យឃើញថាតើត្រូវចំណាយពេលវេលាប៉ុន្មានលើការស្កែនសន្ទស្សន៍ពិសេសនេះទេ ប្រសិនបើមានលក្ខខណ្ឌដាក់នៅក្រោមវា។ យើងត្រូវតែមើលទៅយ៉ាងស្វាហាប់ដើម្បីមើលថាតើមាន "កុមារ" និងអថេរតាមលក្ខខណ្ឌ CTEs នៅខាងក្នុង - ហើយដកទាំងអស់នេះ "នៅក្នុងគំនិតរបស់យើង" ។
• ចំណុចទីពីរ៖ ពេលវេលាដែលត្រូវបានចង្អុលបង្ហាញនៅលើថ្នាំងគឺ ពេលវេលាប្រតិបត្តិថ្នាំងតែមួយ. ប្រសិនបើថ្នាំងនេះត្រូវបានប្រតិបត្តិជាលទ្ធផលនៃឧទាហរណ៍ រង្វិលជុំតាមរយៈកំណត់ត្រាតារាងច្រើនដង នោះចំនួនរង្វិលជុំ-វដ្តនៃថ្នាំងនេះ-កើនឡើងនៅក្នុងផែនការ។ ប៉ុន្តែ​ពេលវេលា​ប្រតិបត្តិ​បរមាណូ​ខ្លួនឯង​នៅតែ​ដដែល​ក្នុង​លក្ខខណ្ឌ​នៃ​ផែនការ។ នោះគឺដើម្បីយល់ពីរយៈពេលដែលថ្នាំងនេះត្រូវបានអនុវត្តសរុប អ្នកត្រូវគុណរបស់មួយដោយមួយទៀត - ម្តងទៀត "នៅក្នុងក្បាលរបស់អ្នក" ។

ក្នុង​ស្ថានភាព​បែប​នេះ សូម​យល់​ថា "តើ​អ្នក​ណា​ជា​តំណ​ខ្សោយ​បំផុត?" ស្ទើរតែមិនអាចទៅរួចទេ។ ដូច្នេះសូម្បីតែអ្នកអភិវឌ្ឍន៍ខ្លួនឯងក៏សរសេរនៅក្នុង "សៀវភៅណែនាំ" នោះ។ “ការយល់ដឹងអំពីផែនការ គឺជាសិល្បៈដែលត្រូវតែរៀន បទពិសោធន៍…”.

ប៉ុន្តែយើងមានអ្នកអភិវឌ្ឍន៍ 1000 នាក់ ហើយអ្នកមិនអាចបញ្ជូនបទពិសោធន៍នេះទៅកាន់ពួកគេម្នាក់ៗបានទេ។ ខ្ញុំ អ្នក គាត់​ដឹង ប៉ុន្តែ​អ្នក​នៅ​ទីនោះ​លែង​ដឹង​ហើយ។ ប្រហែលជាគាត់នឹងរៀន ឬក៏អត់ ប៉ុន្តែគាត់ត្រូវធ្វើការឥឡូវនេះ ហើយតើគាត់នឹងទទួលបទពិសោធន៍នេះនៅឯណា?

ការមើលឃើញផែនការ

ដូច្នេះហើយ ទើបយើងដឹងថា ដើម្បីដោះស្រាយបញ្ហាទាំងនេះ យើងត្រូវការ ការមើលឃើញដ៏ល្អនៃផែនការ. [អត្ថបទ]

ដំបូងយើងបានទៅ "តាមរយៈទីផ្សារ" - សូមរកមើលនៅលើអ៊ីនធឺណិតដើម្បីមើលថាតើមាន។

ប៉ុន្តែវាបានប្រែក្លាយថាមានដំណោះស្រាយ "បន្តផ្ទាល់" តិចតួចបំផុតដែលមានការអភិវឌ្ឍន៍ច្រើន ឬតិចជាងនេះ - តាមន័យត្រង់ មានតែមួយប៉ុណ្ណោះ៖ ពន្យល់.depesz.com ដោយ Hubert Lubaczewski ។ នៅពេលអ្នកបញ្ចូលវាល "មតិព័ត៌មាន" អត្ថបទតំណាងនៃផែនការ វាបង្ហាញអ្នកនូវតារាងជាមួយនឹងទិន្នន័យដែលបានញែក៖

• ពេលវេលាដំណើរការផ្ទាល់ខ្លួនរបស់ node
• ពេលវេលាសរុបសម្រាប់មែកធាងរងទាំងមូល
• ចំនួនកំណត់ត្រាដែលត្រូវបានទាញយកដែលត្រូវបានរំពឹងទុកតាមស្ថិតិ
• តួរបស់ថ្នាំងខ្លួនឯង

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

ប៉ុន្តែក៏មានបញ្ហាតូចតាចផងដែរ។

ទីមួយ បរិមាណដ៏ច្រើននៃ "ចម្លង-បិទភ្ជាប់" ។ អ្នក​យក​ឈើ​មួយ​ដុំ​មក​បិទ​នៅ​ទី​នោះ ហើយ​ម្តង​ហើយ​ម្តង​ទៀត​។

ទីពីរ, មិនមានការវិភាគលើចំនួនទិន្នន័យដែលបានអានទេ។ - សតិបណ្ដោះអាសន្នដូចគ្នាដែលទិន្នផល EXPLAIN (ANALYZE, BUFFERS)យើងមិនឃើញវានៅទីនេះទេ។ គាត់គ្រាន់តែមិនដឹងពីរបៀបបំបែកពួកវា យល់ និងធ្វើការជាមួយពួកគេ។ នៅពេលអ្នកអានទិន្នន័យច្រើន ហើយដឹងថាអ្នកប្រហែលជាកំពុងបែងចែកថាស និងឃ្លាំងសម្ងាត់មិនត្រឹមត្រូវ ព័ត៌មាននេះមានសារៈសំខាន់ណាស់។

ចំណុចអវិជ្ជមានទីបីគឺការអភិវឌ្ឍន៍ខ្សោយនៃគម្រោងនេះ។ ការប្តេជ្ញាចិត្តគឺតូចណាស់ វាជាការល្អប្រសិនបើរៀងរាល់ប្រាំមួយខែម្តង ហើយលេខកូដស្ថិតនៅក្នុង Perl ។

ប៉ុន្តែនេះគឺជា "អត្ថបទចម្រៀង" ទាំងអស់ យើងអាចរស់នៅជាមួយវា ប៉ុន្តែមានរឿងមួយដែលធ្វើឱ្យយើងងាកចេញពីសេវាកម្មនេះយ៉ាងខ្លាំង។ ទាំងនេះគឺជាកំហុសក្នុងការវិភាគនៃ Common Table Expression (CTE) និងថ្នាំងថាមវន្តផ្សេងៗដូចជា InitPlan/SubPlan ជាដើម។

ប្រសិនបើអ្នកជឿថារូបភាពនេះ នោះពេលវេលាប្រតិបត្តិសរុបនៃថ្នាំងនីមួយៗគឺធំជាងពេលវេលាប្រតិបត្តិសរុបនៃសំណើទាំងមូល។ វាសាមញ្ញ - ពេលវេលានៃការបង្កើត CTE នេះមិនត្រូវបានដកចេញពីថ្នាំង CTE Scan ទេ។. ដូច្នេះ យើង​លែង​ដឹង​ចម្លើយ​ត្រឹមត្រូវ​ចំពោះ​រយៈពេល​ដែល​ការ​ស្កែន CTE ខ្លួន​វា​បាន​ចំណាយ​ពេល​យូរ​ទៀត​ហើយ។

ពេល​នោះ​យើង​បាន​ដឹង​ថា​ដល់​ពេល​ត្រូវ​សរសេរ​ខ្លួន​ឯង​ហើយ ហ៊ឺ! អ្នកអភិវឌ្ឍន៍គ្រប់រូបនិយាយថា៖ "ឥឡូវនេះយើងនឹងសរសេរដោយខ្លួនឯង វានឹងងាយស្រួលណាស់!"

យើងបានយកជង់ធម្មតាសម្រាប់សេវាកម្មគេហទំព័រ៖ ស្នូលផ្អែកលើ Node.js + Express បានប្រើ Bootstrap និង D3.js សម្រាប់ដ្យាក្រាមដ៏ស្រស់ស្អាត។ ហើយការរំពឹងទុករបស់យើងមានភាពយុត្តិធម៌ពេញលេញ - យើងបានទទួលគំរូដំបូងក្នុងរយៈពេល 2 សប្តាហ៍៖

• កម្មវិធីញែកផែនការផ្ទាល់ខ្លួន
  នោះ​គឺ​ឥឡូវ​នេះ​យើង​អាច​ញែក​ផែនការ​ណា​មួយ​ពី​គម្រោង​ដែល​បង្កើត​ដោយ PostgreSQL ។
• ការវិភាគត្រឹមត្រូវនៃថ្នាំងថាមវន្ត - CTE Scan, InitPlan, SubPlan
• ការវិភាគនៃការបែងចែកសតិបណ្ដោះអាសន្ន - កន្លែងដែលទំព័រទិន្នន័យត្រូវបានអានពីអង្គចងចាំ, កន្លែងពីឃ្លាំងសម្ងាត់មូលដ្ឋាន, ពីថាស
• ទទួលបានភាពច្បាស់លាស់
  ដូច្នេះដើម្បីកុំ "ជីក" ទាំងអស់នេះនៅក្នុងកំណត់ហេតុប៉ុន្តែដើម្បីមើល "តំណភ្ជាប់ខ្សោយបំផុត" ភ្លាមៗនៅក្នុងរូបភាព។

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

នេះគឺជាតំណាងអក្សរកាត់ដែលយើងហៅ គំរូផែនការ.

តើមានអ្វីទៀតដែលងាយស្រួល? វានឹងមានភាពងាយស្រួលក្នុងការមើលថាតើចំណែកនៃពេលវេលាសរុបរបស់យើងត្រូវបានបែងចែកទៅថ្នាំងណា - ហើយគ្រាន់តែ "បិទវា" ទៅចំហៀង។ គំនូសតាងចំណិត.

យើងចង្អុលទៅថ្នាំងហើយមើល - វាប្រែថា Seq Scan បានចំណាយពេលតិចជាងមួយភាគបួននៃពេលវេលាសរុប ហើយ 3/4 ដែលនៅសល់ត្រូវបានថតដោយ CTE Scan ។ រន្ធត់! នេះគឺជាកំណត់ចំណាំតូចមួយអំពី "អត្រាភ្លើង" នៃ CTE Scan ប្រសិនបើអ្នកប្រើពួកវាយ៉ាងសកម្មនៅក្នុងសំណួររបស់អ្នក។ ពួកវាមិនលឿនទេ - ពួកវាអន់ជាងសូម្បីតែការស្កេនតារាងធម្មតា។ [អត្ថបទ] [អត្ថបទ]

ប៉ុន្តែជាធម្មតា ដ្យាក្រាមបែបនេះគឺគួរឱ្យចាប់អារម្មណ៍ ស្មុគស្មាញជាង នៅពេលដែលយើងចង្អុលទៅផ្នែកមួយភ្លាមៗ ហើយឃើញឧទាហរណ៍ថា ច្រើនជាងពាក់កណ្តាលនៃពេលវេលាមួយចំនួន Seq Scan "ញ៉ាំ" ។ លើសពីនេះទៅទៀត មានប្រភេទ Filter មួយចំនួននៅខាងក្នុង កំណត់ត្រាជាច្រើនត្រូវបានគេបោះចោលយោងទៅតាមវា... អ្នកអាចបោះរូបភាពនេះទៅកាន់អ្នកអភិវឌ្ឍន៍ដោយផ្ទាល់ ហើយនិយាយថា “Vasya អ្វីគ្រប់យ៉ាងគឺអាក្រក់សម្រាប់អ្នក! ស្រមៃមើល - មានអ្វីមួយខុស!”

ជាធម្មតាមាន "តុងរួច" មួយចំនួនពាក់ព័ន្ធ។

រឿងដំបូងដែលយើងជួបប្រទះគឺបញ្ហាបង្គត់។ ពេលវេលានៃថ្នាំងនីមួយៗនៅក្នុងផែនការត្រូវបានចង្អុលបង្ហាញជាមួយនឹងភាពត្រឹមត្រូវនៃ 1 μs។ ហើយនៅពេលដែលចំនួននៃវដ្តថ្នាំងលើសពីឧទាហរណ៍ 1000 - បន្ទាប់ពីការប្រតិបត្តិ PostgreSQL បានបែងចែក "នៅក្នុងភាពត្រឹមត្រូវ" បន្ទាប់មកនៅពេលគណនាត្រឡប់មកវិញយើងទទួលបានពេលវេលាសរុប "កន្លែងណាមួយរវាង 0.95ms និង 1.05ms" ។ នៅពេលដែលការរាប់ទៅមីក្រូវិនាទី វាមិនអីទេ ប៉ុន្តែនៅពេលដែលវាអស់ [milli] វិនាទីរួចហើយ អ្នកត្រូវតែយកព័ត៌មាននេះទៅក្នុងគណនីនៅពេល "ស្រាយ" ធនធានទៅថ្នាំងនៃ "អ្នកដែលប្រើប្រាស់ប៉ុន្មាន" នៃផែនការ។

ចំណុចទីពីរដែលស្មុគស្មាញជាងនេះគឺការចែកចាយធនធាន (បណ្តុំទាំងនោះ) ក្នុងចំណោមថ្នាំងថាមវន្ត។ វាធ្វើឱ្យយើងចំណាយលើ 2 សប្តាហ៍ដំបូងនៃគំរូ បូកនឹង 4 សប្តាហ៍ទៀត។

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

យើងក្រឡេកមើលផែនការហើយយល់ - វាចម្លែក យើងមាន 3 buffers (ទំព័រទិន្នន័យ) "ប្រើប្រាស់" នៅក្នុង Seq Scan, 1 ទៀតនៅក្នុង CTE Scan និង 2 ទៀតនៅក្នុង CTE Scan ទីពីរ។ នោះគឺប្រសិនបើយើងសង្ខេបអ្វីៗទាំងអស់ឡើងយើងនឹងទទួលបាន 6 ប៉ុន្តែពីកុំព្យូទ័របន្ទះយើងអានត្រឹមតែ 3 ប៉ុណ្ណោះ! CTE Scan មិនអានអ្វីពីកន្លែងណាទេ ប៉ុន្តែដំណើរការដោយផ្ទាល់ជាមួយអង្គចងចាំដំណើរការ។ នោះគឺមានអ្វីមួយខុសនៅទីនេះ!

តាមពិតទៅ វាប្រែថា នេះគឺជាទំព័រទាំង 3 នៃទិន្នន័យដែលត្រូវបានស្នើសុំពី Seq Scan ទីមួយបានស្នើសុំការស្កេន CTE លើកទី 1 ហើយបន្ទាប់មកលេខ 1 និង 2 ទៀតត្រូវបានអានឱ្យគាត់ ពោលគឺសរុបទាំងអស់ 2 ទំព័រត្រូវបានអានទិន្នន័យមិនមែន 3 ។

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

យើងដកដង្ហើមចេញមួយរយៈ។ ពួក​គេ​បាន​និយាយ​ថា “ឥឡូវ​នេះ នីអូ អ្នក​ស្គាល់​កុងហ្វូ​ហើយ! ឥឡូវនេះបទពិសោធន៍របស់យើងគឺត្រឹមត្រូវនៅលើអេក្រង់របស់អ្នក។ ឥឡូវ​អ្នក​អាច​ប្រើ​វា​បាន»។ [អត្ថបទ]

ការបង្រួបបង្រួមកំណត់ហេតុ

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

ជាទូទៅ មានម៉ូឌុលស្ដង់ដារដែលអាចប្រមូលស្ថិតិ ទោះយ៉ាងណាក៏ដោយ វាក៏ត្រូវការធ្វើឱ្យសកម្មក្នុងការកំណត់ផងដែរ - នេះ ម៉ូឌុល pg_stat_statements. ប៉ុន្តែគាត់មិនសមនឹងយើងទេ។

ទីមួយ វាកំណត់ទៅសំណួរដូចគ្នាដោយប្រើគ្រោងការណ៍ផ្សេងគ្នានៅក្នុងមូលដ្ឋានទិន្នន័យដូចគ្នា។ QueryIds ផ្សេងគ្នា. នោះគឺប្រសិនបើអ្នកធ្វើដំបូង SET search_path = '01'; SELECT * FROM user LIMIT 1;ហើយបន្ទាប់មក SET search_path = '02'; និងសំណើដូចគ្នា បន្ទាប់មកស្ថិតិនៃម៉ូឌុលនេះនឹងមានកំណត់ត្រាផ្សេងគ្នា ហើយខ្ញុំនឹងមិនអាចប្រមូលស្ថិតិទូទៅជាពិសេសនៅក្នុងបរិបទនៃទម្រង់សំណើនេះ ដោយមិនគិតពីគ្រោងការណ៍។

ចំណុចទីពីរដែលរារាំងយើងពីការប្រើប្រាស់វាគឺ កង្វះផែនការ. ពោល​គឺ​អត់​មាន​គម្រោង​ទេ គឺ​មាន​តែ​សំណើ​ហ្នឹង​ឯង។ យើង​ឃើញ​ថា​មាន​អ្វី​ដែល​ថយ​ចុះ ប៉ុន្តែ​យើង​មិន​យល់​ពី​មូលហេតុ​ទេ។ ហើយនៅទីនេះយើងត្រលប់ទៅបញ្ហានៃសំណុំទិន្នន័យដែលផ្លាស់ប្តូរយ៉ាងឆាប់រហ័ស។

ហើយពេលចុងក្រោយ - កង្វះ "ការពិត". នោះគឺអ្នកមិនអាចដោះស្រាយករណីជាក់លាក់នៃការប្រតិបត្តិសំណួរបានទេ - មិនមានទេ មានតែស្ថិតិសរុបប៉ុណ្ណោះ។ ថ្វីបើអាចធ្វើការជាមួយនេះក៏ដោយ វាពិតជាលំបាកខ្លាំងណាស់។

ដូច្នេះហើយ ពួកយើងបានសម្រេចចិត្តប្រយុទ្ធនឹងការចម្លងបិទភ្ជាប់ ហើយចាប់ផ្តើមសរសេរ អ្នកប្រមូល.

អ្នកប្រមូលភ្ជាប់តាមរយៈ SSH បង្កើតការតភ្ជាប់សុវត្ថិភាពទៅម៉ាស៊ីនមេជាមួយមូលដ្ឋានទិន្នន័យដោយប្រើវិញ្ញាបនបត្រ និង tail -F "តោង" ទៅវានៅក្នុងឯកសារកំណត់ហេតុ។ ដូច្នេះនៅក្នុងវគ្គនេះ។ យើងទទួលបាន "កញ្ចក់" ពេញលេញនៃឯកសារកំណត់ហេតុទាំងមូលដែលម៉ាស៊ីនមេបង្កើត។ ការផ្ទុកនៅលើម៉ាស៊ីនមេខ្លួនឯងគឺតិចតួចបំផុត ដោយសារយើងមិនញែកអ្វីនៅទីនោះ យើងគ្រាន់តែឆ្លុះមើលចរាចរណ៍ប៉ុណ្ណោះ។

ចាប់តាំងពីយើងបានចាប់ផ្តើមសរសេរចំណុចប្រទាក់នៅក្នុង Node.js រួចហើយ យើងបានបន្តសរសេរអ្នកប្រមូលនៅក្នុងវា។ ហើយបច្ចេកវិទ្យានេះបានរាប់ជាសុចរិតដោយខ្លួនឯង ព្រោះវាងាយស្រួលប្រើ JavaScript ដើម្បីធ្វើការជាមួយទិន្នន័យអត្ថបទដែលមានទម្រង់ខ្សោយ ដែលជាកំណត់ហេតុ។ ហើយហេដ្ឋារចនាសម្ព័ន្ធ Node.js ខ្លួនវាជាវេទិកា backend អនុញ្ញាតឱ្យអ្នកធ្វើការយ៉ាងងាយស្រួល និងងាយស្រួលជាមួយការភ្ជាប់បណ្តាញ ហើយជាការពិតជាមួយនឹងស្ទ្រីមទិន្នន័យណាមួយ។

ដូច្នោះហើយ យើង "លាតត្រដាង" ការតភ្ជាប់ពីរ: ទីមួយ "ស្តាប់" កំណត់ហេតុដោយខ្លួនឯង ហើយយកវាទៅខ្លួនយើង និងទីពីរដើម្បីសួរមូលដ្ឋានជាទៀងទាត់។ "ប៉ុន្តែកំណត់ហេតុបង្ហាញថាសញ្ញាដែលមាន oid 123 ត្រូវបានរារាំង" ប៉ុន្តែនេះមិនមានន័យអ្វីសម្រាប់អ្នកអភិវឌ្ឍន៍ទេ ហើយវាជាការល្អក្នុងការសួរមូលដ្ឋានទិន្នន័យថា "តើ OID = 123 ជាអ្វី?" ដូច្នេះ​ហើយ យើង​សួរ​ជា​ទៀងទាត់​នូវ​អ្វី​ដែល​យើង​មិន​ទាន់​ដឹង​អំពី​ខ្លួន​យើង។

“មានរឿងតែមួយគត់ដែលអ្នកមិនបានគិត គឺមានឃ្មុំមួយប្រភេទដូចដំរី!..” យើងបានចាប់ផ្តើមបង្កើតប្រព័ន្ធនេះ នៅពេលដែលយើងចង់ត្រួតពិនិត្យម៉ាស៊ីនមេចំនួន 10។ សារៈសំខាន់បំផុតនៅក្នុងការយល់ដឹងរបស់យើង ដែលបញ្ហាមួយចំនួនបានកើតឡើងដែលពិបាកដោះស្រាយ។ ប៉ុន្តែក្នុងកំឡុងត្រីមាសទី XNUMX យើងទទួលបានមួយរយសម្រាប់ការត្រួតពិនិត្យ - ដោយសារតែប្រព័ន្ធដំណើរការមនុស្សគ្រប់គ្នាចង់បានវាគ្រប់គ្នាមានផាសុកភាព។

ទាំងអស់នេះត្រូវការបន្ថែម លំហូរទិន្នន័យមានទំហំធំ និងសកម្ម។ តាមពិតទៅ អ្វីដែលយើងត្រួតពិនិត្យ អ្វីដែលយើងអាចដោះស្រាយបាន គឺជាអ្វីដែលយើងប្រើប្រាស់។ យើងក៏ប្រើ PostgreSQL ជាកន្លែងផ្ទុកទិន្នន័យផងដែរ។ ហើយគ្មានអ្វីលឿនជាងក្នុងការ "ចាក់" ទិន្នន័យទៅក្នុងវាជាងប្រតិបត្តិករនោះទេ។ COPY នៅឡើយ។

ប៉ុន្តែគ្រាន់តែ "ចាក់" ទិន្នន័យមិនមែនជាបច្ចេកវិទ្យារបស់យើងទេ។ ដោយសារតែប្រសិនបើអ្នកមានសំណើប្រហែល 50k ក្នុងមួយវិនាទីនៅលើម៉ាស៊ីនមេមួយរយ នោះវានឹងបង្កើតកំណត់ហេតុ 100-150GB ក្នុងមួយថ្ងៃ។ ដូច្នេះយើងត្រូវ "កាត់" មូលដ្ឋានដោយប្រុងប្រយ័ត្ន។

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

ទីពីរយើងបានរៀន (ត្រូវបានបង្ខំ) លឿនណាស់ក្នុងការសរសេរដោយប្រើ COPY. នោះគឺមិនមែនគ្រាន់តែទេ។ COPYដោយសារតែគាត់លឿនជាង INSERTនិងសូម្បីតែលឿនជាងមុន។

ចំណុចទីបី - ខ្ញុំត្រូវតែ បោះបង់គន្លឹះរៀងៗខ្លួន និងសោបរទេស. នោះ​គឺ​យើង​មិន​មាន​សុចរិត​ភាព​យោង​ទាល់​តែ​សោះ។ ដោយសារតែប្រសិនបើអ្នកមានតារាងដែលមាន FKs មួយគូ ហើយអ្នកនិយាយនៅក្នុងរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យថា "នេះគឺជាកំណត់ហេតុដែលត្រូវបានយោងដោយ FK ឧទាហរណ៍ទៅក្រុមនៃកំណត់ត្រា" បន្ទាប់មកនៅពេលអ្នកបញ្ចូលវា PostgreSQL គ្មានសល់អ្វីក្រៅពីរបៀបយកវា ហើយធ្វើវាដោយស្មោះត្រង់ SELECT 1 FROM master_fk1_table WHERE ... ជាមួយនឹងឧបករណ៍កំណត់អត្តសញ្ញាណដែលអ្នកកំពុងព្យាយាមបញ្ចូល - គ្រាន់តែពិនិត្យមើលថាកំណត់ត្រានេះមានវត្តមាននៅទីនោះ ដែលអ្នកមិន "បំបែក" សោបរទេសនេះជាមួយនឹងការបញ្ចូលរបស់អ្នក។

ជំនួសឱ្យការកត់ត្រាមួយទៅកាន់តារាងគោលដៅ និងសន្ទស្សន៍របស់វា យើងទទួលបានអត្ថប្រយោជន៍បន្ថែមនៃការអានពីតារាងទាំងអស់ដែលវាសំដៅលើ។ ប៉ុន្តែយើងមិនត្រូវការវាទាល់តែសោះ - ភារកិច្ចរបស់យើងគឺកត់ត្រាឱ្យបានច្រើនតាមដែលអាចធ្វើទៅបាន និងលឿនតាមដែលអាចធ្វើទៅបានជាមួយនឹងបន្ទុកតិចបំផុត។ ដូច្នេះ FK - ចុះ!

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

ឥឡូវស្រមៃថាអ្នកមានតារាងដែលអ្នកគ្រាន់តែរាប់ចំនួនសំណើដែលបានឆ្លងកាត់ម៉ាស៊ីនជាក់លាក់មួយ៖ +1, +1, +1, ..., +1. ហើយជាគោលការណ៍អ្នកមិនត្រូវការវាទេ - វាអាចទៅរួចទាំងអស់។ ផលបូកនៅក្នុងការចងចាំនៅលើអ្នកប្រមូល ហើយផ្ញើទៅមូលដ្ឋានទិន្នន័យក្នុងពេលតែមួយ +10.

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

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

វាគ្រាន់តែជាការល្អឥតខ្ចោះសម្រាប់យើងក្នុងការប្រើ MD5 ពីអត្ថបទ - សំណើ ផែនការ គំរូ... យើងគណនាវានៅផ្នែកអ្នកប្រមូល ហើយ "ចាក់" លេខសម្គាល់ដែលត្រៀមរួចជាស្រេចទៅក្នុងមូលដ្ឋានទិន្នន័យ។ រយៈពេលនៃ MD5 និងការបែងចែកប្រចាំថ្ងៃអនុញ្ញាតឱ្យយើងមិនព្រួយបារម្ភអំពីការប៉ះទង្គិចដែលអាចកើតមាន។

ប៉ុន្តែ​ដើម្បី​ថត​រឿង​ទាំង​អស់​នេះ​បាន​លឿន យើង​ត្រូវ​កែប្រែ​នីតិវិធី​ថត​ដោយ​ខ្លួន​ឯង។

តើអ្នកសរសេរទិន្នន័យដោយរបៀបណា? យើង​មាន​សំណុំ​ទិន្នន័យ​មួយ​ចំនួន យើង​បំបែក​វា​ជា​តារាង​ជា​ច្រើន ហើយ​បន្ទាប់​មក​ចម្លង​វា - ទីមួយ​ទៅ​ទី​មួយ បន្ទាប់​មក​ទីពីរ​ទៅ​ទីបី... វា​មិន​ស្រួល​ទេ ព្រោះ​យើង​ហាក់​ដូច​ជា​កំពុង​សរសេរ​ទិន្នន័យ​មួយ​ក្នុង​បី​ជំហាន។ ជាបន្តបន្ទាប់។ មិនសប្បាយចិត្ត។ តើវាអាចធ្វើបានលឿនជាងនេះទេ? អាច!

ដើម្បីធ្វើដូចនេះវាគ្រប់គ្រាន់ហើយក្នុងការបំបែកលំហូរទាំងនេះស្របគ្នា។ វាប្រែថាយើងមានកំហុសសំណើគំរូការទប់ស្កាត់ ... ការហោះហើរនៅក្នុងខ្សែស្រឡាយដាច់ដោយឡែក - ហើយយើងសរសេរវាទាំងអស់ស្របគ្នា។ គ្រប់គ្រាន់សម្រាប់រឿងនេះ រក្សាឆានែល COPY បើកជានិច្ចសម្រាប់តារាងគោលដៅនីមួយៗ.

នោះគឺនៅឯអ្នកប្រមូល វាតែងតែមានចរន្តដែលខ្ញុំអាចសរសេរទិន្នន័យដែលខ្ញុំត្រូវការ។ ប៉ុន្តែដើម្បីឱ្យមូលដ្ឋានទិន្នន័យមើលឃើញទិន្នន័យនេះហើយនរណាម្នាក់មិនជាប់គាំងរង់ចាំទិន្នន័យនេះនឹងត្រូវបានសរសេរ, ការចម្លងត្រូវតែត្រូវបានរំខាននៅចន្លោះពេលជាក់លាក់. សម្រាប់យើង រយៈពេលដែលមានប្រសិទ្ធភាពបំផុតគឺប្រហែល 100ms - យើងបិទវា ហើយបើកវាម្តងទៀតភ្លាមៗទៅកាន់តារាងដដែល។ ហើយប្រសិនបើយើងមិនមានលំហូរគ្រប់គ្រាន់ក្នុងកំឡុងពេលកំពូលខ្លះទេ នោះយើងនឹងធ្វើការប្រមូលផ្តុំរហូតដល់ដែនកំណត់ជាក់លាក់មួយ។

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

ដើម្បី​កម្ចាត់​ភាព​មិន​ប្រក្រតី​បែប​នេះ អ្នក​មិន​ត្រូវ​រួម​បញ្ចូល​អ្វី​ទាំងអស់ កុំបណ្តែតបណ្តោយ. ហើយប្រសិនបើការបណ្ដោះអាសន្នទៅថាសកើតឡើង (ជាសំណាងល្អ Stream API នៅក្នុង Node.js អនុញ្ញាតឱ្យអ្នកស្វែងរក) - ពន្យារពេលការតភ្ជាប់នេះ។ នៅពេលអ្នកទទួលបានព្រឹត្តិការណ៍ដែលវាឥតគិតថ្លៃម្តងទៀត សូមសរសេរទៅវាពីជួរដែលប្រមូលផ្តុំ។ ហើយខណៈពេលដែលវារវល់ សូមយកមួយទំនេរបន្ទាប់ចេញពីអាង ហើយសរសេរទៅវា។

មុនពេលណែនាំវិធីសាស្រ្តនេះចំពោះការកត់ត្រាទិន្នន័យ យើងមានប្រមាណ 4K write ops ហើយតាមវិធីនេះ យើងបានកាត់បន្ថយការផ្ទុក 4 ដង។ ឥឡូវនេះពួកគេបានរីកចម្រើន 6 ដងទៀតដោយសារតែមូលដ្ឋានទិន្នន័យដែលបានត្រួតពិនិត្យថ្មី - រហូតដល់ 100MB/s ។ ហើយឥឡូវនេះយើងរក្សាទុកកំណត់ហេតុសម្រាប់រយៈពេល 3 ខែចុងក្រោយក្នុងបរិមាណប្រហែល 10-15TB ដោយសង្ឃឹមថាក្នុងរយៈពេលត្រឹមតែ XNUMX ខែអ្នកអភិវឌ្ឍន៍ណាមួយនឹងអាចដោះស្រាយបញ្ហាណាមួយ។

យើងយល់ពីបញ្ហា

ប៉ុន្តែការប្រមូលទិន្នន័យទាំងអស់នេះគឺល្អ មានប្រយោជន៍ ពាក់ព័ន្ធ ប៉ុន្តែមិនគ្រប់គ្រាន់ទេ - ចាំបាច់ត្រូវយល់។ ដោយសារតែទាំងនេះគឺជាផែនការផ្សេងគ្នារាប់លានក្នុងមួយថ្ងៃ។

ប៉ុន្តែ​មនុស្ស​រាប់លាន​នាក់​គឺ​មិនអាច​គ្រប់គ្រង​បាន​ទេ ដំបូង​យើង​ត្រូវតែ​ធ្វើ “​តូច​ជាង​នេះ​”​។ ហើយជាដំបូង អ្នកត្រូវសម្រេចចិត្តពីរបៀបដែលអ្នកនឹងរៀបចំរឿង "តូចជាង" នេះ។

យើងបានកំណត់ចំណុចសំខាន់ចំនួនបី៖

• នរណា បានផ្ញើសំណើនេះ។
  នោះគឺពីកម្មវិធីអ្វីដែលវាបាន "មកដល់"៖ ចំណុចប្រទាក់គេហទំព័រ កម្មវិធីខាងក្រោយ ប្រព័ន្ធទូទាត់ ឬអ្វីផ្សេងទៀត។
• ដែលជាកន្លែងដែល វា​បាន​កើតឡើង
  នៅលើ server ជាក់លាក់មួយណា? ដោយសារតែប្រសិនបើអ្នកមានម៉ាស៊ីនមេជាច្រើននៅក្រោមកម្មវិធីមួយ ហើយភ្លាមៗនោះមួយ "ឆ្កួត" (ដោយសារតែ "ថាសរលួយ" "អង្គចងចាំលេចធ្លាយ" បញ្ហាមួយចំនួនផ្សេងទៀត) នោះអ្នកត្រូវដោះស្រាយជាពិសេសលើម៉ាស៊ីនមេ។
• របៀប បញ្ហាបានបង្ហាញខ្លួនវាតាមមធ្យោបាយមួយឬផ្សេងទៀត។

ដើម្បីយល់ពី "អ្នកណា" ផ្ញើសំណើមកយើង យើងប្រើឧបករណ៍ស្តង់ដារ - កំណត់អថេរសម័យមួយ៖ SET application_name = '{bl-host}:{bl-method}'; - យើងផ្ញើឈ្មោះរបស់ម៉ាស៊ីនតក្កវិជ្ជាអាជីវកម្មដែលសំណើនឹងមកដល់ និងឈ្មោះនៃវិធីសាស្ត្រ ឬកម្មវិធីដែលផ្តួចផ្តើមវា។

បន្ទាប់ពីយើងបានឆ្លងកាត់ "ម្ចាស់" នៃសំណើនោះ វាត្រូវតែចេញទៅកាន់កំណត់ហេតុ - សម្រាប់ការនេះ យើងកំណត់រចនាសម្ព័ន្ធអថេរ log_line_prefix = ' %m [%p:%v] [%d] %r %a'. សម្រាប់អ្នកដែលចាប់អារម្មណ៍ប្រហែលជា រកមើលនៅក្នុងសៀវភៅណែនាំតើវាមានន័យយ៉ាងណា។ វាប្រែថាយើងឃើញនៅក្នុងកំណត់ហេតុ៖

• время
• ដំណើរការ និងការកំណត់អត្តសញ្ញាណប្រតិបត្តិការ
• ឈ្មោះមូលដ្ឋានទិន្នន័យ
• IP របស់អ្នកដែលបានផ្ញើសំណើនេះ។
• និងឈ្មោះវិធីសាស្រ្ត

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

ដូច្នេះនេះគឺជាការកាត់ "ម៉ាស៊ីនមេមួយ - មួយថ្ងៃ" វាប្រែទៅជាគ្រប់គ្រាន់សម្រាប់យើងសម្រាប់ការវិភាគណាមួយ។

ផ្នែកវិភាគដំបូងគឺដូចគ្នា។ "គំរូ" - ទម្រង់សង្ខេបនៃការបង្ហាញផែនការ ជម្រះរាល់សូចនាករលេខ។ ការកាត់ទីពីរគឺជាកម្មវិធី ឬវិធីសាស្រ្ត ហើយការកាត់ទីបីគឺជាថ្នាំងផែនការជាក់លាក់ដែលបណ្តាលឱ្យយើងមានបញ្ហា។

នៅ​ពេល​ដែល​យើង​ផ្លាស់ទី​ពី​ឧទាហរណ៍​ជាក់លាក់​ទៅ​គំរូ យើង​ទទួល​បាន​អត្ថប្រយោជន៍​ពីរ​ក្នុង​ពេល​តែ​មួយ៖

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

វិធីសាស្ត្រដែលនៅសេសសល់គឺផ្អែកលើសូចនាករដែលយើងស្រង់ចេញពីផែនការ៖ តើគំរូបែបនេះកើតឡើងប៉ុន្មានដង សរុប និងមធ្យមម៉ោងប៉ុន្មាន ទិន្នន័យត្រូវបានអានពីថាស និងចំនួនប៉ុន្មានពីអង្គចងចាំ...

ពីព្រោះ ជាឧទាហរណ៍ អ្នកមកទំព័រវិភាគសម្រាប់ម៉ាស៊ីន មើល - អ្វីមួយកំពុងចាប់ផ្តើមអានច្រើនពេកនៅលើថាស។ ថាសនៅលើម៉ាស៊ីនមេមិនអាចគ្រប់គ្រងវាបានទេ - តើអ្នកណាអានពីវា?

ហើយ​អ្នក​អាច​តម្រៀប​តាម​ជួរ​ឈរ​ណា​មួយ ហើយ​សម្រេច​ចិត្ត​ថា​តើ​អ្នក​នឹង​ដោះ​ស្រាយ​អ្វី​ឥឡូវ​នេះ - បន្ទុក​នៅ​លើ processor ឬ disk ឬ​ចំនួន​សំណើ​សរុប... យើង​បាន​តម្រៀប​វា ក្រឡេក​មើល "កំពូល" ដែល​បាន​ជួសជុល​វា ហើយ បានដាក់ចេញកំណែថ្មីនៃកម្មវិធី។
[វីដេអូបង្រៀន]

ហើយភ្លាមៗអ្នកអាចឃើញកម្មវិធីផ្សេងគ្នាដែលភ្ជាប់មកជាមួយគំរូដូចគ្នាពីសំណើដូចជា SELECT * FROM users WHERE login = 'Vasya'. Frontend, backend, processing... ហើយអ្នកឆ្ងល់ថាហេតុអ្វីបានជាដំណើរការនឹងអានអ្នកប្រើប្រាស់ ប្រសិនបើគាត់មិនទាក់ទងជាមួយគាត់។

វិធីផ្ទុយគឺត្រូវមើលភ្លាមៗពីកម្មវិធីថាតើវាធ្វើអ្វី។ ឧទាហរណ៍ ផ្នែកខាងមុខគឺនេះ នេះ នេះ ហើយនេះម្តងក្នុងមួយម៉ោង (បន្ទាត់ពេលវេលាជួយ)។ ហើយសំណួរកើតឡើងភ្លាមៗ៖ វាហាក់ដូចជាមិនមែនជាការងាររបស់ Frontend ដើម្បីធ្វើអ្វីមួយម្តងក្នុងមួយម៉ោង...

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

អ្នកមិនមានលិបិក្រមសមរម្យនៅលើចានទេ អ្នកធ្វើសំណើទៅវា វាហោះកាត់សន្ទស្សន៍ ធ្លាក់ចូលទៅក្នុង Seq Scan... អ្នកបានត្រងចេញរាល់កំណត់ត្រាទាំងអស់ លើកលែងតែមួយ។ ហេតុអ្វីបានជាអ្នកត្រូវការកំណត់ត្រាដែលបានត្រង 100 លានក្នុងមួយថ្ងៃ? តើវាមិនប្រសើរជាងក្នុងការបញ្ចូលសន្ទស្សន៍ទេ?

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

មនុស្សគ្រប់គ្នាដែលសរសេរសំណួរប្រហែលជាបានជួបប្រទះគំរូនេះ៖ "ផ្តល់ឱ្យខ្ញុំនូវការបញ្ជាទិញចុងក្រោយសម្រាប់ Vasya ដែលជាកាលបរិច្ឆេទរបស់វា។ " ហើយប្រសិនបើអ្នកមិនមានលិបិក្រមតាមកាលបរិច្ឆេទ ឬមិនមានកាលបរិច្ឆេទនៅក្នុងលិបិក្រមដែលអ្នកបានប្រើទេនោះ បោះជំហានលើ "តុងរួច" ដូចគ្នា។

ប៉ុន្តែយើងដឹងថានេះគឺជា "តុងរួច" ដូច្នេះហេតុអ្វីមិនប្រាប់អ្នកអភិវឌ្ឍន៍ភ្លាមៗអំពីអ្វីដែលគាត់គួរធ្វើ។ ដូច្នេះហើយ នៅពេលបើកផែនការឥឡូវនេះ អ្នកអភិវឌ្ឍន៍របស់យើងឃើញរូបភាពដ៏ស្រស់ស្អាតជាមួយនឹងគន្លឹះភ្លាមៗ ដែលពួកគេប្រាប់គាត់ភ្លាមៗថា “អ្នកមានបញ្ហានៅទីនេះ និងទីនោះ ប៉ុន្តែពួកគេត្រូវបានដោះស្រាយតាមវិធីនេះហើយ”។

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

ប្រភព: www.habr.com