ធ្វើឱ្យប្រសើរឡើងសម្រាប់អ្នកខ្ជិល៖ របៀបដែល PostgreSQL 12 ធ្វើអោយប្រសើរឡើងនូវដំណើរការ

PostgreSQL ៨.៤.៦កំណែចុងក្រោយបំផុតនៃ "មូលដ្ឋានទិន្នន័យទំនាក់ទំនងប្រភពបើកចំហល្អបំផុតរបស់ពិភពលោក" នឹងចេញក្នុងរយៈពេលពីរបីសប្តាហ៍ទៀត (ប្រសិនបើអ្វីៗដំណើរការទៅតាមផែនការ)។ វាធ្វើតាមកាលវិភាគធម្មតានៃការចេញផ្សាយកំណែថ្មីជាមួយនឹងមុខងារថ្មីៗជាច្រើនដងក្នុងមួយឆ្នាំ ហើយនិយាយដោយត្រង់ទៅ វាពិតជាគួរអោយចាប់អារម្មណ៍ណាស់។ នោះហើយជាមូលហេតុដែលខ្ញុំបានក្លាយជាសមាជិកសកម្មនៃសហគមន៍ PostgreSQL ។

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

ប៉ុន្តែ PostgreSQL 12 មិនឈប់នៅទីនោះទេ៖ ជាមួយនឹងមុខងារថ្មី និងការកែលម្អ កម្មវិធីនឹងដំណើរការកាន់តែប្រសើរឡើង។ ហើយអ្វីទាំងអស់ដែលអ្នកត្រូវធ្វើគឺធ្វើឱ្យប្រសើរឡើង!

(ប្រហែល​ជា​បង្កើត​លិបិក្រម​ឡើង​វិញ ប៉ុន្តែ​នៅ​ក្នុង​ការ​ចេញ​ផ្សាយ​នេះ វា​មិន​គួរ​ឲ្យ​ខ្លាច​ដូច​ដែល​យើង​ធ្លាប់​ប្រើ​នោះ​ទេ។)

វានឹងប្រសើរណាស់ក្នុងការដំឡើង PostgreSQL ហើយរីករាយនឹងការកែលម្អសំខាន់ៗភ្លាមៗដោយមិនមានការរំខានដែលមិនចាំបាច់។ កាលពីប៉ុន្មានឆ្នាំមុន ខ្ញុំបានពិនិត្យមើលការអាប់ដេតពី PostgreSQL 9.4 ទៅ PostgreSQL 10 ហើយបានឃើញពីរបៀបដែលកម្មវិធីដំណើរការដោយអរគុណចំពោះភាពស្របគ្នានៃសំណួរដែលបានកែលម្អនៅក្នុង PostgreSQL 10។ ហើយសំខាន់បំផុតគឺស្ទើរតែគ្មានអ្វីត្រូវបានទាមទារពីខ្ញុំទេ (គ្រាន់តែកំណត់ប៉ារ៉ាម៉ែត្រកំណត់រចនាសម្ព័ន្ធ max_parallel_workers).

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

ដូច្នេះតើការធ្វើឱ្យប្រសើរឡើងសាមញ្ញទៅ PostgreSQL 12 ធ្វើឱ្យអ្នកសប្បាយចិត្តយ៉ាងដូចម្តេច? ខ្ញុំនឹងប្រាប់អ្នកឥឡូវនេះ។

ការកែលម្អលិបិក្រមសំខាន់ៗ

បើគ្មានការធ្វើលិបិក្រមទេ មូលដ្ឋានទិន្នន័យនឹងមិនទៅឆ្ងាយទេ។ តើអ្នកអាចស្វែងរកព័ត៌មានបានលឿនដោយរបៀបណា? ប្រព័ន្ធលិបិក្រមមូលដ្ឋានរបស់ PostgreSQL ត្រូវបានគេហៅថា ខ-មែកធាង. ប្រភេទនៃសន្ទស្សន៍នេះត្រូវបានធ្វើឱ្យប្រសើរសម្រាប់ប្រព័ន្ធផ្ទុកទិន្នន័យ។

យើងគ្រាន់តែប្រើប្រតិបត្តិករ CREATE INDEX ON some_table (some_column)ហើយ PostgreSQL ធ្វើការងារជាច្រើនដើម្បីរក្សាសន្ទស្សន៍ទាន់សម័យ ខណៈពេលដែលយើងបញ្ចូល ធ្វើបច្ចុប្បន្នភាព និងលុបតម្លៃឥតឈប់ឈរ។ អ្វីៗដំណើរការដោយខ្លួនវាផ្ទាល់ ដូចជាវេទមន្ត។

ប៉ុន្តែសន្ទស្សន៍ PostgreSQL មានបញ្ហាមួយ - ពួកគេ។ ត្រូវបានបំប៉ោង និងយកទំហំថាសបន្ថែម និងកាត់បន្ថយការអនុវត្តនៃការទាញយកទិន្នន័យ និងការធ្វើបច្ចុប្បន្នភាព។ ដោយ "bloat" ខ្ញុំមានន័យថាការរក្សារចនាសម្ព័ន្ធលិបិក្រមមិនមានប្រសិទ្ធភាព។ នេះអាច - ឬប្រហែលជាមិន - ទាក់ទងនឹង tuples សំរាមដែលវាយកចេញ វ៉ាកយូម (សូមអរគុណលោក Peter Gaghan សម្រាប់ព័ត៌មាន)Peter Geoghegan)) សន្ទស្សន៍ហើមពោះគឺគួរឱ្យកត់សម្គាល់ជាពិសេសនៅក្នុងបន្ទុកការងារដែលសន្ទស្សន៍កំពុងផ្លាស់ប្តូរយ៉ាងសកម្ម។

PostgreSQL 12 ធ្វើអោយប្រសើរឡើងយ៉ាងខ្លាំងនូវដំណើរការនៃសន្ទស្សន៍ B-tree ហើយការពិសោធន៍ជាមួយនឹងស្តង់ដារដូចជា TPC-C បានបង្ហាញថាជាមធ្យម 40% ទំហំទំនេរត្រូវបានប្រើប្រាស់ឥឡូវនេះ។ ឥឡូវនេះយើងចំណាយពេលតិចជាងមិនត្រឹមតែលើការរក្សាសន្ទស្សន៍ B-tree (នោះគឺនៅលើប្រតិបត្តិការសរសេរ) ប៉ុន្តែក៏ទៅលើការទាញយកទិន្នន័យផងដែរ ពីព្រោះសន្ទស្សន៍គឺតូចជាងច្រើន។

កម្មវិធីដែលធ្វើបច្ចុប្បន្នភាពតារាងរបស់ពួកគេយ៉ាងសកម្ម - ជាធម្មតាកម្មវិធី OLTP (ដំណើរការប្រតិបត្តិការតាមពេលវេលាជាក់ស្តែង) - នឹងប្រើថាស និងដំណើរការសំណើកាន់តែមានប្រសិទ្ធភាព។ ទំហំថាសកាន់តែច្រើន ទំហំផ្ទុកកាន់តែច្រើន មូលដ្ឋានទិន្នន័យត្រូវកើនឡើងដោយមិនធ្វើបច្ចុប្បន្នភាពហេដ្ឋារចនាសម្ព័ន្ធ។

យុទ្ធសាស្រ្តធ្វើឱ្យប្រសើរឡើងមួយចំនួនតម្រូវឱ្យបង្កើតសន្ទស្សន៍ B-tree ឡើងវិញ ដើម្បីទាញយកអត្ថប្រយោជន៍ពីអត្ថប្រយោជន៍ទាំងនេះ (ឧ. pg_upgrade នឹងមិនបង្កើតលិបិក្រមឡើងវិញដោយស្វ័យប្រវត្តិទេ)។ នៅក្នុងកំណែមុនរបស់ PostgreSQL ការបង្កើតលិបិក្រមធំនៅលើតារាងឡើងវិញបានបណ្តាលឱ្យមានពេលវេលារងចាំយ៉ាងសំខាន់ ដោយសារតែការផ្លាស់ប្តូរមិនអាចត្រូវបានធ្វើឡើងក្នុងពេលនេះ។ ប៉ុន្តែ PostgreSQL 12 មានលក្ខណៈពិសេសល្អមួយទៀត៖ ឥឡូវនេះអ្នកអាចបង្កើតលិបិក្រមឡើងវិញស្របជាមួយនឹងពាក្យបញ្ជា REINDEX ស្របគ្នា។ដើម្បីជៀសវាងការឈប់សម្រាកទាំងស្រុង។

មានការកែលម្អផ្សេងទៀតចំពោះហេដ្ឋារចនាសម្ព័ន្ធលិបិក្រមនៅក្នុង PostgreSQL 12 ។ រឿងមួយទៀតដែលជាកន្លែងដែលមានវេទមន្តខ្លះ - កំណត់ហេតុសរសេរជាមុន, aka WAL (កំណត់ហេតុសរសេរមុន)។ កំណត់ហេតុសរសេរមុនកត់ត្រារាល់ប្រតិបត្តិការនៅក្នុង PostgreSQL ក្នុងករណីបរាជ័យ និងការចម្លង។ កម្មវិធីប្រើវាសម្រាប់ការរក្សាទុក និង ការងើបឡើងវិញតាមពេលវេលា. ជា​ការ​ពិត​ណាស់ កំណត់ហេតុ​សរសេរ​មុន​ត្រូវ​បាន​សរសេរ​ទៅ​ថាស ដែល​អាច​ប៉ះពាល់​ដល់​ការ​ដំណើរការ។

PostgreSQL 12 បានកាត់បន្ថយចំនួនលើសនៃកំណត់ត្រា WAL ដែលត្រូវបានបង្កើតឡើងដោយសន្ទស្សន៍ GiST, GIN និង SP-GiST កំឡុងពេលបង្កើតលិបិក្រម។ នេះផ្តល់នូវអត្ថប្រយោជន៍ជាក់ស្តែងជាច្រើន៖ កំណត់ត្រា WAL ប្រើប្រាស់ទំហំថាសតិច ហើយទិន្នន័យត្រូវបានចាក់ឡើងវិញលឿនជាងមុន ដូចជាអំឡុងពេលសង្គ្រោះគ្រោះមហន្តរាយ ឬការសង្គ្រោះទាន់ពេលវេលា។ ប្រសិនបើអ្នកប្រើលិបិក្រមបែបនេះនៅក្នុងកម្មវិធីរបស់អ្នក (ឧទាហរណ៍កម្មវិធីភូមិសាស្ត្រដែលមានមូលដ្ឋានលើ PostGIS ប្រើសន្ទស្សន៍ GiST ច្រើន) នេះគឺជាលក្ខណៈពិសេសមួយទៀតដែលនឹងធ្វើអោយបទពិសោធន៍កាន់តែប្រសើរឡើងដោយមិនបាច់ប្រឹងប្រែងណាមួយឡើយ។

ការបែងចែក - ធំជាងនេះកាន់តែប្រសើរឡើងលឿនជាងមុន

PostgreSQL 10 ត្រូវបានណែនាំ ការបែងចែកប្រកាស. នៅក្នុង PostgreSQL 11 វាកាន់តែងាយស្រួលប្រើ។ នៅក្នុង PostgreSQL 12 អ្នកអាចផ្លាស់ប្តូរមាត្រដ្ឋាននៃផ្នែក។

នៅក្នុង PostgreSQL 12 ដំណើរការនៃប្រព័ន្ធចែកភាគថាសបានកាន់តែប្រសើរឡើងជាពិសេសប្រសិនបើមានភាគថាសរាប់ពាន់នៅក្នុងតារាង។ ឧទាហរណ៍ ប្រសិនបើសំណួរប៉ះពាល់តែភាគថាសពីរបីនៅក្នុងតារាងដែលមានពួកវារាប់ពាន់ វានឹងដំណើរការលឿនជាងមុន។ ការអនុវត្តមិនគ្រាន់តែប្រសើរឡើងសម្រាប់ប្រភេទនៃសំណួរទាំងនេះទេ។ អ្នកក៏នឹងកត់សម្គាល់ផងដែរថាតើប្រតិបត្តិការ INSERT លឿនប៉ុណ្ណានៅលើតារាងដែលមានភាគថាសច្រើន។

ការកត់ត្រាទិន្នន័យដោយប្រើ ច្បាប់ចម្លង - ដោយវិធីនេះគឺជាវិធីដ៏អស្ចារ្យ ការទាញយកទិន្នន័យភាគច្រើន ហើយនេះគឺជាឧទាហរណ៍មួយ។ ទទួល JSON - តារាងបែងចែកនៅក្នុង PostgreSQL 12 ក៏កាន់តែមានប្រសិទ្ធភាពផងដែរ។ ជាមួយនឹងការចម្លងអ្វីគ្រប់យ៉ាងគឺលឿនរួចទៅហើយ ប៉ុន្តែនៅក្នុង PostgreSQL 12 វាពិតជាហោះហើរ។

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

ខណៈពេលដែលនេះមិនមែនជាការធ្វើឱ្យប្រសើរ "ធ្វើឱ្យប្រសើរឡើង និងរីករាយ" PostgreSQL 12 អនុញ្ញាតឱ្យអ្នកបង្កើតកូនសោបរទេសដែលយោងតារាងដែលបានបែងចែក ធ្វើឱ្យការបែងចែកមានភាពរីករាយក្នុងការធ្វើការជាមួយ។

ជាមួយនឹងសំណួរ កាន់តែប្រសើរឡើង

នៅពេល បំណះមួយត្រូវបានអនុវត្តសម្រាប់កន្សោមតារាងរួមដែលភ្ជាប់មកជាមួយ (aka CTE, aka WITH queries) ខ្ញុំមិនអាចរង់ចាំក្នុងការសរសេរអត្ថបទអំពី តើអ្នកបង្កើតកម្មវិធីរីករាយប៉ុណ្ណាជាមួយ PostgreSQL. នេះគឺជាលក្ខណៈពិសេសមួយក្នុងចំណោមលក្ខណៈពិសេសទាំងនោះដែលនឹងបង្កើនល្បឿនកម្មវិធី។ លុះត្រាតែអ្នកប្រើ CTE ។

ជារឿយៗខ្ញុំយល់ថាអ្នកថ្មីថ្មោង SQL ចូលចិត្តប្រើ CTEs ប្រសិនបើអ្នកសរសេរវាតាមរបៀបជាក់លាក់ វាពិតជាមានអារម្មណ៍ថាអ្នកកំពុងសរសេរកម្មវិធីចាំបាច់។ ដោយផ្ទាល់ ខ្ញុំចូលចិត្តសរសេរសំណួរទាំងនេះឡើងវិញ ដើម្បីស្វែងរកជុំវិញ ដោយគ្មាន CTE និងបង្កើនផលិតភាព។ ឥឡូវនេះអ្វីៗគឺខុសគ្នា។

PostgreSQL 12 អនុញ្ញាតឱ្យអ្នកបញ្ចូលប្រភេទជាក់លាក់នៃ CTE ដោយគ្មានផលប៉ះពាល់ (SELECT) ដែលត្រូវបានប្រើតែម្តងគត់នៅជិតចុងបញ្ចប់នៃសំណើ។ ប្រសិនបើខ្ញុំតាមដានសំណួរ CTE ដែលខ្ញុំបានសរសេរឡើងវិញ ភាគច្រើននៃពួកគេនឹងត្រូវធ្លាក់ចូលទៅក្នុងប្រភេទនេះ។ វាជួយអ្នកអភិវឌ្ឍន៍សរសេរកូដច្បាស់លាស់ ដែលឥឡូវនេះក៏ដំណើរការបានលឿនផងដែរ។

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

Just-in-Time (JIT) - ឥឡូវនេះលំនាំដើម

នៅលើប្រព័ន្ធ PostgreSQL 12 ជាមួយនឹងការគាំទ្រ LLVM ការចងក្រង JIT ត្រូវបានបើកតាមលំនាំដើម។ ដំបូងអ្នកទទួលបានការគាំទ្រ ជិត សម្រាប់ប្រតិបត្តិការខាងក្នុងមួយចំនួន ហើយទីពីរ សំណួរដែលមានកន្សោម (ឧទាហរណ៍សាមញ្ញបំផុតគឺ x + y) នៅក្នុងបញ្ជីជ្រើសរើស (ដែលអ្នកមានបន្ទាប់ពី SELECT) សរុប កន្សោមជាមួយឃ្លា WHERE និងផ្សេងទៀតអាចប្រើ JIT ដើម្បីកែលម្អដំណើរការ។

ដោយសារ JIT ត្រូវបានបើកតាមលំនាំដើមនៅក្នុង PostgreSQL 12 ការអនុវត្តនឹងប្រសើរឡើងដោយខ្លួនឯង ប៉ុន្តែខ្ញុំសូមណែនាំឱ្យសាកល្បងកម្មវិធីនៅក្នុង PostgreSQL 11 ដែលបានណែនាំ JIT ដើម្បីវាស់ស្ទង់ដំណើរការសំណួរ និងមើលថាតើអ្នកត្រូវការលៃតម្រូវអ្វី។

ចុះមុខងារថ្មីដែលនៅសល់ក្នុង PostgreSQL 12 វិញ?

PostgreSQL 12 មានលក្ខណៈពិសេសថ្មីៗជាច្រើន ចាប់ពីសមត្ថភាពក្នុងការពិនិត្យមើលទិន្នន័យ JSON ដោយប្រើកន្សោមផ្លូវ SQL/JSON ស្តង់ដាររហូតដល់ការផ្ទៀងផ្ទាត់ពហុកត្តាជាមួយនឹងប៉ារ៉ាម៉ែត្រ clientcert=verify-fullបានបង្កើតជួរឈរ និងច្រើនទៀត។ គ្រប់គ្រាន់សម្រាប់ការប្រកាសដាច់ដោយឡែក។

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

ប្រភព: www.habr.com