Postgres៖ ហើមពោះ pg_repack និងពន្យាពេល

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

អត្ថបទនឹងមានទ្រឹស្ដីតូចមួយអំពីរបៀបដែលហើមពោះកើតឡើង របៀបដែលអ្នកអាចទប់ទល់នឹងវា អំពីឧបសគ្គដែលបានពន្យារពេល និងបញ្ហាដែលពួកគេនាំទៅដល់ការប្រើប្រាស់ផ្នែកបន្ថែម pg_repack ។

អត្ថបទនេះត្រូវបានសរសេរដោយផ្អែកលើ សុន្ទរកថារបស់ខ្ញុំ នៅ PgConf.Russia 2020។

ហេតុអ្វីបានជាហើមពោះកើតឡើង?

Postgres គឺផ្អែកលើគំរូពហុកំណែ (MVCC) ខ្លឹមសាររបស់វាគឺថាជួរនីមួយៗក្នុងតារាងអាចមានកំណែជាច្រើន ខណៈពេលដែលប្រតិបត្តិការមើលមិនឃើញលើសពីកំណែមួយក្នុងចំណោមកំណែទាំងនេះ ប៉ុន្តែមិនចាំបាច់ដូចគ្នានោះទេ។ នេះអនុញ្ញាតឱ្យប្រតិបត្តិការជាច្រើនដំណើរការក្នុងពេលដំណាលគ្នា ហើយស្ទើរតែគ្មានផលប៉ះពាល់ដល់គ្នាទៅវិញទៅមក។

ជាក់ស្តែង កំណែទាំងអស់នេះត្រូវរក្សាទុក។ Postgres ដំណើរការជាមួយទំព័រអង្គចងចាំដោយទំព័រមួយ ហើយទំព័រមួយគឺជាចំនួនទិន្នន័យអប្បបរមាដែលអាចអានបានពីថាស ឬសរសេរ។ សូមក្រឡេកមើលឧទាហរណ៍តូចមួយដើម្បីយល់ពីរបៀបដែលវាកើតឡើង។

ចូរនិយាយថាយើងមានតារាងដែលយើងបានបន្ថែមកំណត់ត្រាជាច្រើន។ ទិន្នន័យថ្មីបានបង្ហាញខ្លួននៅក្នុងទំព័រដំបូងនៃឯកសារដែលតារាងត្រូវបានរក្សាទុក។ ទាំងនេះគឺជាកំណែបន្តផ្ទាល់នៃជួរដែលមានសម្រាប់ប្រតិបត្តិការផ្សេងទៀតបន្ទាប់ពីការប្តេជ្ញាចិត្តមួយ (សម្រាប់ភាពសាមញ្ញ យើងនឹងសន្មត់ថាកម្រិតឯកោគឺ Read Committed)។

បន្ទាប់​មក យើង​បាន​ធ្វើ​បច្ចុប្បន្នភាព​ធាតុ​មួយ​ដោយ​សម្គាល់​កំណែ​ចាស់​ថា​មិន​ពាក់ព័ន្ធ​ទៀត​ទេ។

មួយជំហានម្តងៗ ការធ្វើបច្ចុប្បន្នភាព និងការលុបកំណែជួរ យើងបានបញ្ចប់ដោយទំព័រដែលប្រហែលពាក់កណ្តាលនៃទិន្នន័យគឺ "សំរាម" ។ ទិន្នន័យនេះមិនអាចមើលឃើញចំពោះប្រតិបត្តិការណាមួយឡើយ។

Postgres មានយន្តការមួយ។ វ៉ាកយូមដែលសម្អាតកំណែដែលលែងប្រើ ហើយធ្វើឱ្យមានកន្លែងសម្រាប់ទិន្នន័យថ្មី។ ប៉ុន្តែប្រសិនបើវាមិនត្រូវបានកំណត់រចនាសម្ព័ន្ធខ្លាំងគ្រប់គ្រាន់ ឬរវល់ធ្វើការនៅក្នុងតារាងផ្សេងទៀតនោះ "ទិន្នន័យសំរាម" នៅតែមាន ហើយយើងត្រូវប្រើទំព័របន្ថែមសម្រាប់ទិន្នន័យថ្មី។

ដូច្នេះក្នុងឧទាហរណ៍របស់យើង ក្នុងពេលណាមួយ តារាងនឹងមានបួនទំព័រ ប៉ុន្តែមានតែពាក់កណ្តាលប៉ុណ្ណោះដែលនឹងមានទិន្នន័យផ្ទាល់។ ជាលទ្ធផលនៅពេលចូលប្រើតារាងយើងនឹងអានទិន្នន័យច្រើនជាងការចាំបាច់។

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

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

អ្វីគ្រប់យ៉ាងដែលបានពិពណ៌នាខាងលើគឺជាយន្តការនៃការកើតឡើងនៃការហើមពោះនៅក្នុងតារាង។ នៅក្នុងលិបិក្រម វាកើតឡើងតាមរបៀបដូចគ្នា។

តើខ្ញុំហើមពោះទេ?

មានវិធីជាច្រើនដើម្បីកំណត់ថាតើអ្នកមានហើមពោះដែរឬទេ។ គំនិតទីមួយគឺត្រូវប្រើស្ថិតិ Postgres ខាងក្នុងដែលមានព័ត៌មានប្រហាក់ប្រហែលអំពីចំនួនជួរដេកក្នុងតារាង ចំនួនជួរដេក "បន្តផ្ទាល់" ជាដើម។ អ្នកអាចរកឃើញការប្រែប្រួលជាច្រើននៃស្គ្រីបដែលត្រៀមរួចជាស្រេចនៅលើអ៊ីនធឺណិត។ យើងបានយកជាមូលដ្ឋាន ស្គ្រីប ពី PostgreSQL Experts ដែលអាចវាយតម្លៃតារាងហើមពោះ រួមជាមួយនឹងសន្ទស្សន៍ toast និង bloat btree ។ នៅក្នុងបទពិសោធន៍របស់យើងកំហុសរបស់វាគឺ 10-20% ។

វិធីមួយទៀតគឺប្រើផ្នែកបន្ថែម pgstattupleដែលអនុញ្ញាតឱ្យអ្នកមើលខាងក្នុងទំព័រ និងទទួលបានទាំងតម្លៃប៉ាន់ស្មាន និងតម្លៃពិតប្រាកដ។ ប៉ុន្តែនៅក្នុងករណីទីពីរអ្នកនឹងត្រូវស្កេនតារាងទាំងមូល។

យើងពិចារណាតម្លៃប៉ោងតូចមួយរហូតដល់ 20% អាចទទួលយកបាន។ វាអាចត្រូវបានចាត់ទុកថាជា analogue នៃ fillfactor សម្រាប់ តុ и សន្ទស្សន៍. នៅ 50% និងខ្ពស់ជាងនេះ បញ្ហាដំណើរការអាចចាប់ផ្តើម។

វិធីដើម្បីប្រយុទ្ធប្រឆាំងនឹងការហើមពោះ

Postgres មានវិធីជាច្រើនដើម្បីដោះស្រាយការហើមពោះចេញពីប្រអប់ ប៉ុន្តែវាមិនតែងតែសាកសមសម្រាប់មនុស្សគ្រប់គ្នានោះទេ។

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

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

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

អ្វីដែលត្រូវធ្វើក្នុងស្ថានភាពដែលអ្នកបានដំឡើង AUTOVACUUM ប៉ុន្តែការហើមពោះនៅតែបន្តកើនឡើង។

ក្រុមការងារ Vacuum ពេញ បង្កើតឡើងវិញនូវមាតិកានៃតារាង និងលិបិក្រម ហើយទុកតែទិន្នន័យដែលពាក់ព័ន្ធនៅក្នុងពួកវា។ ដើម្បីលុបបំបាត់ការហើមពោះ វាដំណើរការយ៉ាងល្អឥតខ្ចោះ ប៉ុន្តែក្នុងអំឡុងពេលប្រតិបត្តិរបស់វា សោផ្តាច់មុខនៅលើតុត្រូវបានចាប់យក (AccessExclusiveLock) ដែលនឹងមិនអនុញ្ញាតឱ្យប្រតិបត្តិសំណួរនៅលើតារាងនេះសូម្បីតែជ្រើសរើស។ ប្រសិនបើអ្នកអាចមានលទ្ធភាពបញ្ឈប់សេវាកម្មរបស់អ្នក ឬផ្នែករបស់វាសម្រាប់ពេលខ្លះ (ពីរាប់សិបនាទីទៅច្រើនម៉ោងអាស្រ័យលើទំហំនៃមូលដ្ឋានទិន្នន័យ និងផ្នែករឹងរបស់អ្នក) នោះជម្រើសនេះគឺល្អបំផុត។ ជាអកុសល យើងមិនមានពេលវេលាដើម្បីដំណើរការ VACUUM FULL ក្នុងអំឡុងពេលថែទាំដែលបានកំណត់នោះទេ ដូច្នេះវិធីសាស្ត្រនេះមិនសាកសមសម្រាប់យើងទេ។

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

ក្រុមការងារ REINDEX ស្រដៀងទៅនឹងពីរមុន ប៉ុន្តែបង្កើតលិបិក្រមជាក់លាក់ ឬសន្ទស្សន៍ទាំងអស់នៃតារាងឡើងវិញ។ ការចាក់សោគឺខ្សោយជាងបន្តិច៖ ShareLock នៅលើតុ (ការពារការកែប្រែ ប៉ុន្តែអនុញ្ញាតឱ្យជ្រើសរើស) និង AccessExclusiveLock នៅលើលិបិក្រមដែលកំពុងត្រូវបានបង្កើតឡើងវិញ (រារាំងសំណួរដោយប្រើលិបិក្រមនេះ)។ ទោះយ៉ាងណាក៏ដោយនៅក្នុងកំណែទី 12 នៃ Postgres ប៉ារ៉ាម៉ែត្រមួយបានលេចឡើង ស្របគ្នា។ដែលអនុញ្ញាតឱ្យអ្នកបង្កើតលិបិក្រមឡើងវិញដោយមិនទប់ស្កាត់ការបន្ថែម ការកែប្រែ ឬលុបកំណត់ត្រាក្នុងពេលដំណាលគ្នា។

នៅក្នុងកំណែមុនរបស់ Postgres អ្នកអាចសម្រេចបានលទ្ធផលស្រដៀងនឹង REINDEX ក្នុងពេលដំណាលគ្នាដោយប្រើ បង្កើតសន្ទស្សន៍ស្របគ្នា។. វាអនុញ្ញាតឱ្យអ្នកបង្កើតលិបិក្រមដោយមិនចាំបាច់ចាក់សោយ៉ាងតឹងរឹង (ShareUpdateExclusiveLock ដែលមិនជ្រៀតជ្រែកជាមួយសំណួរស្របគ្នា) បន្ទាប់មកជំនួសសន្ទស្សន៍ចាស់ជាមួយថ្មីមួយ និងលុបលិបិក្រមចាស់។ នេះអនុញ្ញាតឱ្យអ្នកលុបបំបាត់ការហើមពោះសន្ទស្សន៍ដោយមិនជ្រៀតជ្រែកជាមួយកម្មវិធីរបស់អ្នក។ វាមានសារៈសំខាន់ណាស់ក្នុងការពិចារណាថានៅពេលបង្កើតលិបិក្រមឡើងវិញវានឹងមានបន្ទុកបន្ថែមលើប្រព័ន្ធរងរបស់ឌីស។

ដូច្នេះប្រសិនបើសម្រាប់សន្ទស្សន៍មានវិធីដើម្បីបំបាត់ការហើមពោះ "ភ្លាមៗ" នោះមិនមានតារាងទេ។ នេះជាកន្លែងដែលផ្នែកបន្ថែមខាងក្រៅផ្សេងៗចូលមកលេង៖ pg_repack (អតីត pg_reorg), pgcompact, pgcompacttable ហើយ​ផ្សេងទៀត។ នៅក្នុងអត្ថបទនេះខ្ញុំនឹងមិនប្រៀបធៀបពួកគេទេហើយនឹងនិយាយតែអំពី pg_repack ដែលបន្ទាប់ពីការកែប្រែខ្លះយើងប្រើខ្លួនយើង។

របៀបដែល pg_repack ដំណើរការ

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

បន្ទាប់មក pg_repack ផ្ទេរទិន្នន័យពីតារាងចាស់ទៅតារាងថ្មី ច្រោះដោយស្វ័យប្រវត្តិនូវជួរដេកដែលមិនពាក់ព័ន្ធទាំងអស់ ហើយបន្ទាប់មកបង្កើតលិបិក្រមសម្រាប់តារាងថ្មី។ កំឡុងពេលអនុវត្តប្រតិបត្តិការទាំងអស់នេះ ការផ្លាស់ប្តូរកកកុញនៅក្នុងតារាងកំណត់ហេតុ។

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

អ្វីគ្រប់យ៉ាងមើលទៅអស្ចារ្យនៅក្នុងទ្រឹស្តី ប៉ុន្តែតើមានអ្វីកើតឡើងនៅក្នុងការអនុវត្ត? យើងបានសាកល្បង pg_repack ដោយមិនផ្ទុក និងកំពុងផ្ទុក ហើយបានពិនិត្យប្រតិបត្តិការរបស់វា ក្នុងករណីឈប់មិនគ្រប់ខែ (និយាយម្យ៉ាងទៀត ដោយប្រើ Ctrl+C)។ ការធ្វើតេស្តទាំងអស់គឺវិជ្ជមាន។

យើងបានទៅហាងលក់អាហារ - ហើយបន្ទាប់មកអ្វីគ្រប់យ៉ាងមិនដូចដែលយើងរំពឹងទុក។

នំផេនខេកដំបូងដាក់លក់

នៅលើចង្កោមទីមួយ យើងបានទទួលកំហុសមួយអំពីការរំលោភលើកម្រិតតែមួយគត់៖

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ដែនកំណត់នេះមានឈ្មោះបង្កើតដោយស្វ័យប្រវត្តិ index_16508 - វាត្រូវបានបង្កើតឡើងដោយ pg_repack ។ ដោយផ្អែកលើលក្ខណៈដែលបានរួមបញ្ចូលនៅក្នុងសមាសភាពរបស់វា យើងបានកំណត់កម្រិត "របស់យើង" ដែលត្រូវនឹងវា។ បញ្ហាបានប្រែក្លាយថា នេះមិនមែនជាការកំណត់ធម្មតាទាំងស្រុងនោះទេ ប៉ុន្តែជាការពន្យាពេល (ការពន្យាពេលកំណត់), i.e. ការផ្ទៀងផ្ទាត់របស់វាត្រូវបានអនុវត្តយឺតជាងពាក្យបញ្ជា sql ដែលនាំទៅរកផលវិបាកដែលមិននឹកស្មានដល់។

ឧបសគ្គពន្យាពេល៖ ហេតុអ្វីបានជាពួកគេត្រូវការ និងរបៀបដែលពួកគេធ្វើការ

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

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique
);

ឧបមាថាយើងត្រូវប្តូរឡានទីមួយ និងទីពីរ។ ដំណោះ​ស្រាយ​ត្រង់​គឺ​ត្រូវ​ធ្វើ​បច្ចុប្បន្នភាព​តម្លៃ​ទី​មួយ​ទៅ​តម្លៃ​ទីពីរ ហើយ​តម្លៃ​ទីពីរ​ទៅ​លេខ​មួយ៖

begin;
  update cars set ord = 2 where name = 'audi';
  update cars set ord = 1 where name = 'bmw';
commit;

ប៉ុន្តែនៅពេលដែលយើងដំណើរការកូដនេះ យើងរំពឹងថានឹងមានការរំលោភលើកម្រិតមួយ ពីព្រោះលំដាប់នៃតម្លៃនៅក្នុងតារាងគឺមានតែមួយគត់៖

[23305] ERROR: duplicate key value violates unique constraint “uk_cars”
Detail: Key (ord)=(2) already exists.

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

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

ជម្រើសទី 3៖ កំណត់ការពន្យាពេល ដូច្នេះវាត្រូវបានពិនិត្យតែនៅពេលធ្វើកិច្ចសន្យា៖

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique deferrable initially deferred
);

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

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

ជាទូទៅ អាស្រ័យលើប្រភេទនៃឧបសគ្គ Postgres មានបីកម្រិតនៃ granularity សម្រាប់ត្រួតពិនិត្យពួកវា៖ ជួរដេក ប្រតិបត្តិការ និងកម្រិតកន្សោម។

ប្រភព: អ្នកសុំទាន

ពិនិត្យ និងមិនមែន NULL តែងតែត្រូវបានធីកនៅកម្រិតជួរដេក សម្រាប់ការរឹតបន្តឹងផ្សេងទៀត ដូចដែលអាចមើលឃើញពីតារាង មានជម្រើសផ្សេងគ្នា។ អ្នកអាចអានបន្ថែម នៅទីនេះ.

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

ការកែលម្អ pg_repack

យើង​បាន​រ៉ាប់រង​នូវ​ឧបសគ្គ​ដែល​ត្រូវ​ពន្យារពេល ប៉ុន្តែ​តើ​វា​ទាក់ទង​នឹង​បញ្ហា​របស់​យើង​ដោយ​របៀបណា? ចូរយើងចងចាំនូវកំហុសដែលយើងបានទទួលពីមុន៖

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

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

ដូចដែលវាប្រែថាឫសគល់នៃបញ្ហាស្ថិតនៅក្នុងជំហានមុនរបស់ pg_repack ដែលបង្កើតតែលិបិក្រម ប៉ុន្តែមិនមែនជាឧបសគ្គទេ៖ តារាងចាស់មានឧបសគ្គតែមួយគត់ ហើយថ្មីបានបង្កើតលិបិក្រមតែមួយគត់ជំនួសវិញ។

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

ដូច្នេះខ្លឹមសារនៃបញ្ហាស្ថិតនៅក្នុង "ការពន្យាពេល" នៃការត្រួតពិនិត្យ៖ នៅក្នុងតារាងដើមវាកើតឡើងនៅពេលធ្វើការ ហើយនៅក្នុងតារាងថ្មីនៅពេលបញ្ជា sql ត្រូវបានប្រតិបត្តិ។ នេះមានន័យថា យើងត្រូវធ្វើឱ្យប្រាកដថា ការត្រួតពិនិត្យត្រូវបានអនុវត្តដូចគ្នានៅក្នុងករណីទាំងពីរ៖ តែងតែពន្យារពេល ឬភ្លាមៗភ្លាមៗ។

ដូច្នេះតើយើងមានគំនិតអ្វីខ្លះ?

បង្កើតលិបិក្រមស្រដៀងនឹងការពន្យាពេល

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

ដើម្បីធានាថាការត្រួតពិនិត្យគឺតែងតែស្ថិតក្នុងរបៀបមិនពន្យារ យើងបានបង្កើតលិបិក្រមថ្មីស្រដៀងនឹងដែនកំណត់ដែលបានពន្យារពេលដើម៖

CREATE UNIQUE INDEX CONCURRENTLY uk_tablename__immediate ON tablename (id, index);
-- run pg_repack
DROP INDEX CONCURRENTLY uk_tablename__immediate;

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

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

គំនិតមិនដំណើរការទេ។ នៅចំណុចនោះ យើងបានឃើញដំណោះស្រាយពីរផ្សេងទៀត៖ សរសេរកូដកម្មវិធីរបស់យើងឡើងវិញ ដើម្បីចែកចាយជាមួយការពន្យាពេល ឬ "បង្រៀន" pg_repack ដើម្បីធ្វើការជាមួយពួកគេ។ យើងជ្រើសរើសទីពីរ។

ជំនួស​លិបិក្រម​ក្នុង​តារាង​ថ្មី​ជាមួយ​នឹង​ការ​ពន្យារ​ពេល​ពី​តារាង​ដើម

គោលបំណងនៃការកែប្រែគឺជាក់ស្តែង - ប្រសិនបើតារាងដើមមានឧបសគ្គពន្យារ នោះសម្រាប់តារាងថ្មី អ្នកត្រូវបង្កើតឧបសគ្គបែបនេះ មិនមែនលិបិក្រមទេ។

ដើម្បីសាកល្បងការផ្លាស់ប្តូររបស់យើង យើងបានសរសេរការធ្វើតេស្តសាមញ្ញមួយ៖

• តារាងដែលមានកំហិតពន្យាពេល និងកំណត់ត្រាមួយ;
• បញ្ចូលទិន្នន័យនៅក្នុងរង្វិលជុំដែលប៉ះទង្គិចជាមួយកំណត់ត្រាដែលមានស្រាប់;
• ធ្វើបច្ចុប្បន្នភាព - ទិន្នន័យលែងមានជម្លោះទៀតហើយ។
• ធ្វើការផ្លាស់ប្តូរ។

create table test_table
(
  id serial,
  val int,
  constraint uk_test_table__val unique (val) deferrable initially deferred 
);

INSERT INTO test_table (val) VALUES (0);
FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (0) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    COMMIT;
  END;
END LOOP;

កំណែដើមរបស់ pg_repack តែងតែគាំងនៅលើការបញ្ចូលដំបូង កំណែដែលបានកែប្រែដំណើរការដោយគ្មានកំហុស។ អស្ចារ្យ។

យើងទៅផលិតកម្ម ហើយម្តងទៀតទទួលបានកំហុសនៅដំណាក់កាលដូចគ្នានៃការចម្លងទិន្នន័យពីតារាងកំណត់ហេតុទៅថ្មីមួយ៖

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ស្ថានភាពបុរាណ៖ អ្វីៗដំណើរការក្នុងបរិយាកាសសាកល្បង ប៉ុន្តែមិនមែននៅក្នុងផលិតកម្មទេ?!

APPLY_COUNT និងប្រសព្វនៃបាច់ពីរ

យើងបានចាប់ផ្តើមវិភាគកូដតាមព្យញ្ជនៈតាមបន្ទាត់ ហើយបានរកឃើញចំណុចសំខាន់មួយ៖ ទិន្នន័យត្រូវបានផ្ទេរពីតារាងកំណត់ហេតុទៅថ្មីមួយជាបាច់ ថេរ APPLY_COUNT បង្ហាញពីទំហំនៃបណ្តុំ៖

for (;;)
{
num = apply_log(connection, table, APPLY_COUNT);

if (num > MIN_TUPLES_BEFORE_SWITCH)
     continue;  /* there might be still some tuples, repeat. */
...
}

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

APPLY_COUNT គឺស្មើនឹង 1000 កំណត់ត្រា ដែលពន្យល់ពីមូលហេតុដែលការធ្វើតេស្តរបស់យើងទទួលបានជោគជ័យ - ពួកគេមិនគ្របដណ្តប់ករណី "ប្រសព្វជាបាច់" ទេ។ យើងបានប្រើពាក្យបញ្ជាពីរ - បញ្ចូល និងធ្វើបច្ចុប្បន្នភាព ដូច្នេះប្រតិបត្តិការចំនួន 500 នៃពាក្យបញ្ជាពីរតែងតែត្រូវបានដាក់ក្នុងបាច់មួយ ហើយយើងមិនជួបប្រទះបញ្ហាអ្វីនោះទេ។ បន្ទាប់ពីបន្ថែមការអាប់ដេតទីពីរ ការកែសម្រួលរបស់យើងបានឈប់ដំណើរការ៖

FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (1) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    UPDATE test_table set val = i where id = v_id; -- one more update
    COMMIT;
  END;
END LOOP;

ដូច្នេះ កិច្ចការបន្ទាប់គឺត្រូវប្រាកដថាទិន្នន័យពីតារាងដើមដែលត្រូវបានផ្លាស់ប្តូរក្នុងប្រតិបត្តិការមួយ បញ្ចប់ក្នុងតារាងថ្មីផងដែរនៅក្នុងប្រតិបត្តិការមួយ។

ការបដិសេធពីការប្រមូលផ្តុំ

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

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

ដូច្នេះ​ហើយ​បាន​ជា​យើង​សម្រេច​ចិត្ត​ចាប់​ផ្ដើម​ជាមួយ​ជម្រើស​ដំបូង​ព្រោះ​វា​សាមញ្ញ​ជាង។ ជាដំបូងវាចាំបាច់ដើម្បីយល់ថាតើប្រតិបត្តិការដ៏យូរនឹងក្លាយជាបញ្ហាពិតប្រាកដ។ ចាប់តាំងពីការផ្ទេរទិន្នន័យសំខាន់ពីតារាងចាស់ទៅថ្មីមួយក៏កើតឡើងក្នុងប្រតិបត្តិការដ៏វែងមួយ សំណួរបានប្រែទៅជា "តើយើងនឹងបង្កើនប្រតិបត្តិការនេះប៉ុន្មាន?" រយៈពេលនៃប្រតិបត្តិការដំបូងគឺអាស្រ័យជាចម្បងលើទំហំនៃតារាង។ ថិរវេលានៃការផ្លាស់ប្តូរថ្មីគឺអាស្រ័យលើចំនួនការផ្លាស់ប្តូរដែលកកកុញនៅក្នុងតារាងកំឡុងពេលផ្ទេរទិន្នន័យ ពោលគឺឧ។ នៅលើអាំងតង់ស៊ីតេនៃបន្ទុក។ ការដំណើរការ pg_repack បានកើតឡើងក្នុងអំឡុងពេលនៃការផ្ទុកសេវាកម្មតិចតួចបំផុត ហើយបរិមាណនៃការផ្លាស់ប្តូរគឺតូចមិនសមាមាត្រធៀបនឹងទំហំដើមនៃតារាង។ យើងបានសម្រេចចិត្តថាយើងអាចធ្វេសប្រហែសពេលវេលានៃប្រតិបត្តិការថ្មី (សម្រាប់ការប្រៀបធៀបជាមធ្យមវាគឺ 1 ម៉ោង 2-3 នាទី) ។

ការពិសោធន៍មានភាពវិជ្ជមាន។ បើកដំណើរការផលិតកម្មផងដែរ។ ដើម្បីអោយកាន់តែច្បាស់ នេះជារូបភាពដែលមានទំហំនៃ databases បន្ទាប់ពីដំណើរការ៖

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

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

ការរកឃើញ

អ្វីដែលយើងអាចណែនាំដោយផ្អែកលើបទពិសោធន៍ផ្ទាល់របស់យើង៖

1. តាមដានការហើមពោះរបស់អ្នក។ ដោយផ្អែកលើទិន្នន័យត្រួតពិនិត្យ អ្នកអាចយល់ពីរបៀបដែល autovacuum ត្រូវបានកំណត់រចនាសម្ព័ន្ធបានល្អ។
2. កែតម្រូវ AUTOVACUUM ដើម្បីរក្សាភាពហើមពោះនៅកម្រិតដែលអាចទទួលយកបាន។
3. ប្រសិនបើការហើមពោះនៅតែកើនឡើង ហើយអ្នកមិនអាចយកឈ្នះវាដោយប្រើឧបករណ៍ក្រៅប្រអប់ កុំខ្លាចក្នុងការប្រើប្រាស់ផ្នែកបន្ថែមខាងក្រៅ។ រឿងចំបងគឺត្រូវសាកល្បងអ្វីៗគ្រប់យ៉ាងឱ្យបានល្អ។
4. កុំខ្លាចក្នុងការកែប្រែដំណោះស្រាយខាងក្រៅដើម្បីបំពេញតម្រូវការរបស់អ្នក - ពេលខ្លះវាអាចមានប្រសិទ្ធភាពជាង និងងាយស្រួលជាងការផ្លាស់ប្តូរលេខកូដផ្ទាល់ខ្លួនរបស់អ្នក។

ប្រភព: www.habr.com