សូមគោរព DELETE ។ Nikolay Samokhvalov (Postgres.ai)

នៅពេលអនាគតដ៏ឆ្ងាយ ការដកទិន្នន័យដែលមិនចាំបាច់ចេញដោយស្វ័យប្រវត្តិនឹងក្លាយជាកិច្ចការសំខាន់មួយនៃ DBMS [1] ។ ក្នុងពេលជាមួយគ្នានេះ យើងខ្លួនឯងត្រូវយកចិត្តទុកដាក់ក្នុងការលុប ឬផ្លាស់ទីទិន្នន័យដែលមិនចាំបាច់ទៅកាន់ប្រព័ន្ធផ្ទុកទិន្នន័យដែលមានតម្លៃថោក។ ឧបមាថាអ្នកសម្រេចចិត្តលុបជួរពីរបីលាន។ កិច្ចការដ៏សាមញ្ញមួយ ជាពិសេសប្រសិនបើលក្ខខណ្ឌត្រូវបានគេស្គាល់ ហើយមានសន្ទស្សន៍សមរម្យ។ "លុបចេញពីតារាងទី 1 កន្លែងណា col1 = : តម្លៃ" - តើអ្វីដែលអាចសាមញ្ញជាងនេះមែនទេ?

វីដេអូ:

• ខ្ញុំបាននៅក្នុងគណៈកម្មាធិការកម្មវិធី Highload តាំងពីឆ្នាំដំបូង ពោលគឺតាំងពីឆ្នាំ 2007។

• ហើយខ្ញុំបាននៅជាមួយ Postgres តាំងពីឆ្នាំ 2005 ។ បានប្រើវានៅក្នុងគម្រោងជាច្រើន។

• ក្រុមជាមួយ RuPostges ផងដែរចាប់តាំងពីឆ្នាំ 2007 ។

• យើងបានកើនឡើងដល់ 2100+ អ្នកចូលរួមនៅ Meetup ។ វាស្ថិតនៅលំដាប់ទី XNUMX នៅលើពិភពលោកបន្ទាប់ពីទីក្រុងញូវយ៉ក ដែលវ៉ាដាច់សាន់ហ្វ្រាន់ស៊ីស្កូអស់រយៈពេលជាយូរ។

• ខ្ញុំបានរស់នៅក្នុងរដ្ឋកាលីហ្វ័រញ៉ាអស់រយៈពេលជាច្រើនឆ្នាំ។ ខ្ញុំដោះស្រាយកាន់តែច្រើនជាមួយក្រុមហ៊ុនអាមេរិក រួមទាំងក្រុមហ៊ុនធំៗផងដែរ។ ពួកគេគឺជាអ្នកប្រើប្រាស់សកម្មរបស់ Postgres ។ ហើយមានរឿងគួរឱ្យចាប់អារម្មណ៍គ្រប់ប្រភេទ។

https://postgres.ai/ គឺជាក្រុមហ៊ុនរបស់ខ្ញុំ។ យើងស្ថិតនៅក្នុងអាជីវកម្មនៃកិច្ចការស្វ័យប្រវត្តិកម្មដែលលុបបំបាត់ការយឺតយ៉ាវនៃការអភិវឌ្ឍន៍។

ប្រសិនបើអ្នកកំពុងធ្វើអ្វីមួយ នោះជួនកាលមានប្រភេទដោតមួយចំនួននៅជុំវិញ Postgres។ ឧបមាថាអ្នកត្រូវរង់ចាំអ្នកគ្រប់គ្រងដើម្បីរៀបចំកន្លែងធ្វើតេស្តសម្រាប់អ្នក ឬអ្នកត្រូវរង់ចាំ DBA ឆ្លើយតបមកអ្នក។ ហើយយើងរកឃើញភាពជាប់គាំងបែបនេះនៅក្នុងដំណើរការអភិវឌ្ឍ ការធ្វើតេស្ត និងការគ្រប់គ្រង ហើយព្យាយាមលុបបំបាត់ពួកវាដោយមានជំនួយពីស្វ័យប្រវត្តិកម្ម និងវិធីសាស្រ្តថ្មីៗ។

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

ថ្មីៗនេះខ្ញុំនៅ VLDB ក្នុងទីក្រុង Los Angeles ។ នេះ​ជា​សន្និសីទ​ធំ​បំផុត​លើ​មូលដ្ឋាន​ទិន្នន័យ។ ហើយមានរបាយការណ៍មួយថានៅពេលអនាគត DBMS នឹងមិនត្រឹមតែរក្សាទុកប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងលុបទិន្នន័យដោយស្វ័យប្រវត្តិទៀតផង។ នេះជាប្រធានបទថ្មី។

មានទិន្នន័យកាន់តែច្រើននៅក្នុងពិភពនៃ zettabytes - នោះជា 1 petabytes ។ ហើយឥឡូវនេះវាត្រូវបានគេប៉ាន់ប្រមាណថាយើងមានទិន្នន័យច្រើនជាង 000 zettabytes នៃទិន្នន័យដែលបានរក្សាទុកនៅក្នុងពិភពលោក។ ហើយមានពួកគេកាន់តែច្រើនឡើង ៗ ។

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

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

អ្នកដែលអាចរាប់លុយចង់បានរបស់ពីរ។ គេ​ចង់​ឲ្យ​យើង​លុប ដូច្នេះ​តាម​បច្ចេកទេស​យើង​គួរ​តែ​អាច​ធ្វើ​បាន។

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

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

ជាទូទៅ ភារកិច្ចគឺធ្វើស្វ័យប្រវត្តិកម្មការលុបវត្ថុជាក់លាក់ បន្ទាត់ជាក់លាក់ក្នុងតារាងមួយចំនួន។

ហើយ​យើង​មាន​សំណើ​បែប​នេះ ដែល​យើង​នឹង​និយាយ​នៅ​ថ្ងៃ​នេះ ពោល​គឺ​ការ​យក​សំរាម​ចេញ។

យើងបានសុំឱ្យអ្នកអភិវឌ្ឍន៍ដែលមានបទពិសោធន៍ម្នាក់ធ្វើវា។ គាត់បានយកសំណើនេះពិនិត្យវាដោយខ្លួនឯង - អ្វីៗដំណើរការ។ សាកល្បងនៅលើឆាក - អ្វីគ្រប់យ៉ាងគឺល្អ។ បានដាក់ចេញ - អ្វីៗដំណើរការ។ មួយថ្ងៃយើងដំណើរការវា - អ្វីៗគឺល្អ។

មូលដ្ឋានទិន្នន័យរីកចម្រើននិងរីកចម្រើន។ ការ DELETE ប្រចាំថ្ងៃចាប់ផ្តើមដំណើរការយឺតជាងបន្តិច។

បន្ទាប់មកយើងយល់ថាឥឡូវនេះយើងមានក្រុមហ៊ុនទីផ្សារ ហើយចរាចរណ៍នឹងមានទំហំធំជាងមុនជាច្រើនដង ដូច្នេះហើយយើងសម្រេចចិត្តផ្អាកជាបណ្តោះអាសន្ននូវអ្វីដែលមិនចាំបាច់។ ហើយភ្លេចត្រឡប់មកវិញ។

ពីរបីខែក្រោយមកពួកគេបានចងចាំ។ ហើយ​អ្នក​អភិវឌ្ឍន៍​នោះ​បាន​ឈប់ ឬ​រវល់​ជាមួយ​អ្វី​ផ្សេង​ទៀត ដោយ​ណែនាំ​អ្នក​ផ្សេង​ឱ្យ​ប្រគល់​វា​មក​វិញ។

គាត់បានពិនិត្យលើ dev នៅលើឆាក - អ្វីៗគឺល្អហើយ។ តាមធម្មជាតិ អ្នកនៅតែត្រូវសម្អាតអ្វីដែលបានប្រមូលផ្តុំ។ គាត់បានពិនិត្យអ្វីៗគ្រប់យ៉ាងដំណើរការ។

តើមានអ្វីកើតឡើងបន្ទាប់? បន្ទាប់មក អ្វីៗក៏ធ្លាក់សម្រាប់យើង។ វាធ្លាក់ចុះដូច្នេះនៅចំណុចខ្លះអ្វីគ្រប់យ៉ាងធ្លាក់ចុះ។ គ្រប់​គ្នា​មាន​ការ​តក់ស្លុត គ្មាន​នរណា​យល់​ថា​មាន​អ្វី​កើត​ឡើង​ឡើយ។ ហើយបន្ទាប់មកវាប្រែថាបញ្ហាគឺនៅក្នុង DELETE នេះ។

មាន​អ្វីមួយ​មិន​ប្រក្រតី? នេះគឺជាបញ្ជីនៃអ្វីដែលអាចខុស។ តើមួយណាសំខាន់ជាងគេ?

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

• ប្រហែលជាពួកគេបានពិនិត្យអ្វីមួយខុសហើយ។

• ប្រហែលជាផ្នែករឹងហួសសម័យហើយ អ្នកត្រូវដំឡើងកំណែមូលដ្ឋាននេះ។

• ឬមានអ្វីខុសជាមួយមូលដ្ឋានទិន្នន័យខ្លួនឯង ហើយយើងត្រូវផ្លាស់ទីពី Postgres ទៅ MySQL ។

• ឬប្រហែលជាមានអ្វីខុសជាមួយប្រតិបត្តិការ។

• ប្រហែលជាមានកំហុសមួយចំនួននៅក្នុងការរៀបចំការងារ ហើយអ្នកត្រូវការបណ្តេញនរណាម្នាក់ ហើយជួលមនុស្សល្អបំផុត?

មិនមានការត្រួតពិនិត្យ DBA ទេ។ ប្រសិនបើមាន DBA គាត់នឹងឃើញបន្ទាត់រាប់លានទាំងនេះ ហើយសូម្បីតែគ្មានការពិសោធន៍ណាមួយនឹងនិយាយថា៖ "ពួកគេមិនធ្វើដូច្នោះទេ"។ ឧបមាថាប្រសិនបើកូដនេះស្ថិតនៅក្នុង GitLab, GitHub ហើយនឹងមានដំណើរការពិនិត្យកូដ ហើយវាមិនដូច្នោះទេ ប្រសិនបើគ្មានការយល់ព្រមពី DBA ប្រតិបត្តិការនេះនឹងកើតឡើងនៅលើផលិតផលនោះ ច្បាស់ណាស់ DBA នឹងនិយាយថា “វាមិនអាចធ្វើបានទេ។ ”

ហើយគាត់នឹងនិយាយថាអ្នកនឹងមានបញ្ហាជាមួយឌីស IO ហើយដំណើរការទាំងអស់នឹងឆ្កួត វាអាចមានការចាក់សោរ ហើយអ្នកនឹងបិទ autovacuum ក្នុងរយៈពេលប៉ុន្មាននាទី ដូច្នេះវាមិនល្អទេ។

http://bit.ly/nancy-hl2018-2

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

យើង​យល់​ថា​ការ​ធ្វើ​តេស្ត​របស់​យើង​ខ្សោយ ពោល​គឺ​ដំណើរការ​ដែល​ត្រូវ​បាន​បង្កើត​ឡើង​មិន​មាន​បញ្ហា​ទេ។ ការពិសោធន៍ DB គ្រប់គ្រាន់មិនត្រូវបានអនុវត្តទេ។

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

ប្រហែលជាឧបករណ៍របស់យើងមិនល្អ? ប្រសិនបើអ្នកមើល នោះភាពយឺតយ៉ាវបានលោតឡើង។ យើងឃើញថាការប្រើប្រាស់គឺ 100% ។ ជាការពិតណាស់ប្រសិនបើទាំងនេះគឺជាដ្រាយ NVMe ទំនើបនោះវាប្រហែលជាងាយស្រួលជាងសម្រាប់យើង។ ហើយប្រហែលជាយើងនឹងមិនចុះចេញពីវាទេ។

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

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

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

ការកំណត់នៅក្នុង Postgres មានភាពយឺតយ៉ាវ។ ពួកវាត្រូវបានរចនាឡើងសម្រាប់ទំហំទិន្នន័យ និងប្រតិបត្តិការដែលមានអាយុ 10-15 ឆ្នាំ។ ហើយប៉ុស្តិ៍ត្រួតពិនិត្យគឺមិនមានករណីលើកលែងនោះទេ។

នេះគឺជាព័ត៌មានពីរបាយការណ៍ពិនិត្យសុខភាព Postgres របស់យើង ពោលគឺការពិនិត្យសុខភាពដោយស្វ័យប្រវត្តិ។ ហើយនេះគឺជាមូលដ្ឋានទិន្នន័យមួយចំនួននៃ terabytes ជាច្រើន។ ហើយ​វា​អាច​ត្រូវ​បាន​គេ​មើល​ឃើញ​យ៉ាង​ច្បាស់​ថា​ការ​បង្ខំ​ឱ្យ​មាន​ប៉ុស្តិ៍​ត្រួតពិនិត្យ​ស្ទើរតែ 90% នៃ​ករណី។

តើ​វា​មានន័យ​យ៉ាង​ដូចម្តេច? មានការកំណត់ពីរនៅទីនោះ។ ប៉ុស្តិ៍ត្រួតពិនិត្យអាចមកដោយអស់ពេល ជាឧទាហរណ៍ នៅ 10 នាទី។ ឬវាអាចមកនៅពេលដែលទិន្នន័យជាច្រើនត្រូវបានបំពេញ។

ហើយតាមលំនាំដើម max_wal_saze ត្រូវបានកំណត់ទៅ 1 ជីហ្គាបៃ។ តាមការពិត នេះពិតជាកើតឡើងនៅក្នុង Postgres បន្ទាប់ពី 300-400 មេកាបៃ។ អ្នកបានផ្លាស់ប្តូរទិន្នន័យយ៉ាងច្រើន ហើយចំណុចត្រួតពិនិត្យរបស់អ្នកកើតឡើង។

ហើយប្រសិនបើគ្មាននរណាម្នាក់លៃតម្រូវវាទេហើយសេវាកម្មកើនឡើងហើយក្រុមហ៊ុនរកប្រាក់បានច្រើនវាមានប្រតិបត្តិការច្រើនបន្ទាប់មកប៉ុស្តិ៍ត្រួតពិនិត្យមកម្តងក្នុងមួយនាទីជួនកាលរៀងរាល់ 30 វិនាទីហើយជួនកាលសូម្បីតែត្រួតលើគ្នា។ នេះគឺអាក្រក់ណាស់។

ហើយ​យើង​ត្រូវ​ធ្វើ​ឱ្យ​ប្រាកដ​ថា​វា​មក​តិច​តួច។ នោះគឺយើងអាចបង្កើនទំហំ max_wal_size ។ ហើយវានឹងមកតិចជាញឹកញាប់។

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

ដូច្នោះហើយ យើងកំពុងធ្វើការពិសោធន៍ពីរស៊េរីលើមូលដ្ឋានទិន្នន័យ។

ស៊េរីទីមួយ - យើងផ្លាស់ប្តូរទំហំ max_wal_size ។ ហើយយើងកំពុងធ្វើប្រតិបត្តិការដ៏ធំមួយ។ ដំបូងយើងធ្វើវានៅលើការកំណត់លំនាំដើមនៃ 1 ជីហ្គាបៃ។ ហើយយើងធ្វើការលុបដ៏ធំនៃបន្ទាត់រាប់លាន។

អ្នក​អាច​ឃើញ​ថា​វា​លំបាក​ប៉ុណ្ណា​សម្រាប់​យើង។ យើងឃើញថាឌីស IO គឺអាក្រក់ណាស់។ យើងក្រឡេកមើលថាតើ WAL ប៉ុន្មានដែលយើងបានបង្កើត ព្រោះវាមានសារៈសំខាន់ខ្លាំងណាស់។ ចាំមើលថាតើប៉ុស្តិ៍ត្រួតពិនិត្យបានកើតឡើងប៉ុន្មានដង។ ហើយយើងឃើញថាវាមិនល្អទេ។

បន្ទាប់យើងបង្កើនទំហំ max_wal_size ។ យើងធ្វើម្តងទៀត។ យើងកើនឡើង យើងធ្វើម្តងទៀត។ ហើយច្រើនដង។ ជាគោលការណ៍ 10 ពិន្ទុគឺល្អដែល 1, 2, 4, 8 ជីហ្គាបៃ។ ហើយយើងពិនិត្យមើលឥរិយាបថនៃប្រព័ន្ធជាក់លាក់មួយ។ វាច្បាស់ណាស់ថានៅទីនេះឧបករណ៍គួរតែដូចនៅលើផលិតផល។ អ្នកត្រូវតែមានថាសដូចគ្នា បរិមាណអង្គចងចាំដូចគ្នា និងការកំណត់ Postgres ដូចគ្នា។

ហើយតាមរបៀបនេះ យើងនឹងផ្លាស់ប្តូរប្រព័ន្ធរបស់យើង ហើយយើងដឹងពីរបៀបដែល DBMS នឹងមានឥរិយាបទក្នុងករណីមានការ DELETE ដ៏អាក្រក់ របៀបដែលវានឹងត្រួតពិនិត្យ។

ប៉ុស្តិ៍ត្រួតពិនិត្យជាភាសារុស្សីគឺជាប៉ុស្តិ៍ត្រួតពិនិត្យ។

ឧទាហរណ៍៖ លុបជួរជាច្រើនលានតាមលិបិក្រម ជួរដេកត្រូវបាន "ខ្ចាត់ខ្ចាយ" នៅទូទាំងទំព័រ។

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

ប្រសិនបើប្រតិបត្តិការបែបនេះត្រូវបានអនុញ្ញាតក្នុងការផលិត នោះយើងនឹងគ្រាន់តែដេកចុះ ព្រោះវាច្បាស់ណាស់ថា DELETE សម្លាប់យើងនៅក្នុងធ្នើ។

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

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

ហេតុអ្វីអញ្ចឹង។

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

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

ហើយ​យើង​នឹង​បង្ខំ​ប៉ុស្តិ៍​ត្រួតពិនិត្យ​ដើម្បី​រក្សាទុក​វា​ច្រើន​ដង។ តើ​មាន​ប្រតិបត្តិការ​ដដែលៗ​សម្រាប់​គាត់​ដោយ​របៀប​ណា?

ប៉ុន្តែនោះមិនមែនទាំងអស់នោះទេ។ ទំព័រមាន 8 គីឡូបៃនៅក្នុង Postgres និង 4 គីឡូបៃនៅក្នុងលីនុច។ ហើយមានការកំណត់ពេញ_page_writes។ វាត្រូវបានបើកតាមលំនាំដើម។ ហើយនេះជាការត្រឹមត្រូវព្រោះប្រសិនបើយើងបិទវានោះមានគ្រោះថ្នាក់ដែលគ្រាន់តែពាក់កណ្តាលនៃទំព័រនឹងត្រូវបានរក្សាទុកប្រសិនបើវាគាំង។

ឥរិយាបថនៃការសរសេរទៅកាន់ WAL នៃកំណត់ហេតុបញ្ជូនបន្ត គឺនៅពេលដែលយើងមានចំណុចត្រួតពិនិត្យ ហើយយើងផ្លាស់ប្តូរទំព័រជាលើកដំបូង ទំព័រទាំងមូល ពោលគឺ ទាំង 8 គីឡូបៃ ចូលទៅក្នុងកំណត់ហេតុខាងមុខ ទោះបីជាយើងគ្រាន់តែផ្លាស់ប្តូរទំព័រក៏ដោយ។ បន្ទាត់ដែលមានទម្ងន់ 100 បៃ។ ហើយយើងត្រូវសរសេរទំព័រទាំងមូល។

នៅក្នុងការផ្លាស់ប្តូរជាបន្តបន្ទាប់នឹងមានតែ tuple ជាក់លាក់មួយប៉ុន្តែជាលើកដំបូងដែលយើងសរសេរអ្វីគ្រប់យ៉ាង។

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

ហើយ​តាម​នោះ យើង​មាន​ការ​មិន​បរិច្ចាក​ពីរ។

ប្រសិនបើយើងបង្កើនទំហំ max_wal_size វាប្រែថាយើងធ្វើឱ្យវាកាន់តែងាយស្រួលសម្រាប់ទាំង checkpoint និង wal writer ។ ហើយនោះពិតជាអស្ចារ្យណាស់។

ចូរយើងដាក់ក្នុង terabyte ហើយរស់នៅជាមួយវា។ តើមានអ្វីអាក្រក់អំពីវា? នេះ​ជា​រឿង​អាក្រក់​ព្រោះ​បើ​បរាជ័យ​យើង​នឹង​ឡើង​រាប់​ម៉ោង​ព្រោះ​ប៉ុស្តិ៍​ត្រួត​ពិនិត្យ​យូរ​មក​ហើយ​មាន​ការ​ប្រែប្រួល​ច្រើន​ហើយ។ ហើយយើងត្រូវធ្វើ REDO ទាំងអស់នេះ។ ដូច្នេះហើយ យើងធ្វើពិសោធន៍ស៊េរីទីពីរ។

យើង​ធ្វើ​ប្រតិបត្តិការ​មួយ​ហើយ​មើល​ឃើញ​ថា​តើ​ពេល​ណា​ប៉ុស្តិ៍​ត្រួត​ពិនិត្យ​ជិត​នឹង​បញ្ចប់ យើង​បាន​សម្លាប់ -9 Postgres ដោយ​ចេតនា។

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

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

យើងវាស់ស្ថានភាពបែបនេះសម្រាប់ទំហំ max_wal_size ផ្សេងៗគ្នា ហើយយល់ថាប្រសិនបើទំហំ max_wal_size គឺ 64 ជីហ្គាបៃ នោះក្នុងករណីដែលអាក្រក់បំផុតពីរដងយើងនឹងកើនឡើង 10 នាទី។ ហើយ​យើង​គិត​ថា​វា​ស័ក្តិសម​ឬ​អត់។ នេះគឺជាសំណួរអាជីវកម្ម។ យើង​ត្រូវ​បង្ហាញ​រូបភាព​នេះ​ដល់​អ្នក​ដែល​ទទួល​ខុស​ត្រូវ​លើ​ការ​សម្រេច​ចិត្ត​អាជីវកម្ម ហើយ​សួរ​ថា “តើ​យើង​អាច​ដេក​បាន​យូរ​ប៉ុណ្ណា​ក្នុង​ករណី​មាន​បញ្ហា? តើយើងអាចដេកក្នុងស្ថានភាពអាក្រក់បំផុតរយៈពេល 3-5 នាទីបានទេ? ហើយអ្នកធ្វើការសម្រេចចិត្ត។

ហើយនេះគឺជាចំណុចគួរឱ្យចាប់អារម្មណ៍មួយ។ យើងមានរបាយការណ៍ពីរបីអំពី Patroni នៅក្នុងសន្និសីទ។ ហើយប្រហែលជាអ្នកកំពុងប្រើវា។ នេះគឺជាការបរាជ័យដោយស្វ័យប្រវត្តិសម្រាប់ Postgres ។ GitLab និង Data Egret បាននិយាយអំពីរឿងនេះ។

ហើយប្រសិនបើអ្នកមាន autofailover ដែលមកក្នុងរយៈពេល 30 វិនាទី នោះប្រហែលជាយើងអាចដេកបាន 10 នាទី? ដោយសារតែយើងនឹងប្តូរទៅការចម្លងដោយចំណុចនេះហើយអ្វីៗនឹងល្អ។ នេះ​ជា​ចំណុច​រសើប។ ខ្ញុំ​មិន​ដឹង​ចម្លើយ​ច្បាស់​លាស់​ទេ។ ខ្ញុំ​គ្រាន់​តែ​មាន​អារម្មណ៍​ថា​ប្រធាន​បទ​នេះ​មិន​ត្រឹម​តែ​ជុំវិញ​ការ​សង្គ្រោះ​ការ​គាំង​ទេ។

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

ខ្ញុំនៅតែមិនទៅឆ្ងាយទេ ទោះបីជាយើងមាន autofailover ក៏ដោយ។ តាមក្បួនតម្លៃដូចជា 64, 100 ជីហ្គាបៃគឺជាតម្លៃដ៏ល្អ។ ពេលខ្លះវាមានតម្លៃសូម្បីតែជ្រើសរើសតិច។ ជាទូទៅនេះគឺជាវិទ្យាសាស្ត្រដ៏កម្រមួយ។

ដើម្បីធ្វើម្តងទៀតឧទាហរណ៍ max_wal_size =1, 8 អ្នកត្រូវធ្វើប្រតិបត្តិការម៉ាស់ម្តងទៀតច្រើនដង។ អ្នកបានបង្កើតវា។ ហើយនៅលើមូលដ្ឋានដូចគ្នាអ្នកចង់ធ្វើវាម្តងទៀត ប៉ុន្តែអ្នកបានលុបអ្វីៗគ្រប់យ៉ាងរួចហើយ។ អ្វី​ដែល​ត្រូវធ្វើ?

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

ប៉ុន្តែ​នៅ​ក្នុង​ករណី​នេះ យើង​មាន​សំណាង។ ប្រសិនបើដូចដែលវានិយាយនៅទីនេះ "BEGIN, DELETE, ROLLBACK" នោះយើងអាច DELETE ម្តងទៀត។ នោះគឺប្រសិនបើយើងលុបចោលវាដោយខ្លួនឯងនោះយើងអាចធ្វើវាឡើងវិញបាន។ ហើយដោយរាងកាយរបស់អ្នក ទិន្នន័យនឹងស្ថិតនៅកន្លែងតែមួយ។ អ្នក​ក៏​មិន​បាន​ហើម​ពោះ​ដែរ។ អ្នកអាចធ្វើម្តងទៀតលើការ DELETE បែបនេះ។

ការលុបជាមួយ ROLLBACK នេះគឺល្អសម្រាប់ការលៃតម្រូវប៉ុស្តិ៍ត្រួតពិនិត្យ ទោះបីជាអ្នកមិនមានបន្ទប់ពិសោធន៍មូលដ្ឋានទិន្នន័យដែលបានដាក់ឱ្យត្រឹមត្រូវក៏ដោយ។

យើងធ្វើចានដែលមានជួរឈរមួយ "i" ។ Postgres មានជួរឈរឧបករណ៍ប្រើប្រាស់។ ពួកវាមើលមិនឃើញ លុះត្រាតែមានការស្នើសុំជាពិសេស។ ទាំងនេះគឺ៖ ctid, xmid, xmax ។

Ctid គឺជាអាសយដ្ឋានរូបវន្ត។ ទំព័រសូន្យដែលជា tuple ដំបូងនៅក្នុងទំព័រ។

វាអាចត្រូវបានគេមើលឃើញថាបន្ទាប់ពី ROOLBACK tuple នៅតែនៅកន្លែងដដែល។ នោះគឺយើងអាចព្យាយាមម្តងទៀតវានឹងមានឥរិយាបទដូចគ្នា។ នេះគឺជារឿងសំខាន់។

Xmax គឺជាពេលវេលានៃការស្លាប់របស់ tuple ។ វាត្រូវបានបោះត្រា ប៉ុន្តែ Postgres ដឹងថាប្រតិបត្តិការត្រូវបានបង្វិលមកវិញ ដូច្នេះវាមិនមានបញ្ហាថាតើវាជា 0 ឬវាជាប្រតិបត្តិការវិលត្រឡប់មកវិញនោះទេ។ នេះបង្ហាញថាវាអាចទៅរួចក្នុងការធ្វើម្តងទៀតលើ DELETE និងពិនិត្យមើលប្រតិបត្តិការភាគច្រើននៃឥរិយាបទរបស់ប្រព័ន្ធ។ អ្នកអាចបង្កើតមន្ទីរពិសោធន៍មូលដ្ឋានទិន្នន័យសម្រាប់អ្នកក្រីក្រ។

នេះនិយាយអំពីអ្នកសរសេរកម្មវិធី។ អំពី DBA ផងដែរ ពួកគេតែងតែស្តីបន្ទោសអ្នកសរសេរកម្មវិធីសម្រាប់រឿងនេះ៖ "ហេតុអ្វីបានជាអ្នកធ្វើប្រតិបត្តិការដ៏វែង និងពិបាកបែបនេះ?" នេះគឺជាប្រធានបទកាត់កែងខុសគ្នាទាំងស្រុង។ ធ្លាប់មានការគ្រប់គ្រង ហើយឥឡូវនេះនឹងមានការអភិវឌ្ឍន៍។

ជាក់ស្តែង យើង​មិន​បាន​បំបែក​ជា​ដុំៗ​ទេ។ វាច្បាស់ណាស់។ វាមិនអាចទៅរួចទេក្នុងការបំបែក DELETE បែបនេះសម្រាប់បណ្តុំរាប់លានបន្ទាត់ទៅជាផ្នែក។ វានឹងត្រូវបានធ្វើសម្រាប់រយៈពេល 20 នាទីហើយអ្វីៗនឹងដេកលក់។ ប៉ុន្តែជាអកុសល សូម្បីតែអ្នកអភិវឌ្ឍន៍ដែលមានបទពិសោធន៍ក៏ធ្វើខុស សូម្បីតែនៅក្នុងក្រុមហ៊ុនធំៗក៏ដោយ។

ហេតុអ្វីបានជាវាសំខាន់ក្នុងការបំបែក?

• បើ​យើង​ឃើញ​ថា​ថាស​រឹង​ហើយ​នោះ ចូរ​បន្ថយ​ល្បឿន​ចុះ។ ហើយប្រសិនបើយើងខូច នោះយើងអាចបន្ថែមការផ្អាក យើងអាចបន្ថយល្បឿនបិទបើកបាន។

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

https://postgres.ai/products/joe/

នេះគួរឱ្យចាប់អារម្មណ៍។ ជារឿយៗខ្ញុំឃើញអ្នកអភិវឌ្ឍន៍សួរថា "តើខ្ញុំគួរជ្រើសរើសទំហំកញ្ចប់អ្វី?"។

វាច្បាស់ណាស់ថាទំហំកញ្ចប់ធំជាង ប្រតិបត្តិការតូចជាងនេះ ឧ. ការចំណាយបន្ថែមពីប្រតិបត្តិការ។ ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះពេលវេលាកើនឡើងសម្រាប់ប្រតិបត្តិការនេះ។

ខ្ញុំមានច្បាប់សាមញ្ញបំផុត៖ យកច្រើនតាមដែលអ្នកអាចធ្វើបាន ប៉ុន្តែកុំលើសពីការប្រតិបត្តិក្នុងមួយវិនាទី។

ហេតុអ្វីមួយវិនាទី? ការពន្យល់គឺសាមញ្ញណាស់ ហើយអាចយល់បានសម្រាប់មនុស្សគ្រប់គ្នា សូម្បីតែមនុស្សមិនបច្ចេកទេសក៏ដោយ។ យើងឃើញប្រតិកម្ម។ ចូរយើងយក 50 មីលីវិនាទី។ ប្រសិនបើមានអ្វីមួយបានផ្លាស់ប្តូរនោះភ្នែករបស់យើងនឹងមានប្រតិកម្ម។ បើតិច ពិបាកជាង។ ប្រសិនបើអ្វីមួយឆ្លើយតបបន្ទាប់ពី 100 មិល្លីវិនាទី ឧទាហរណ៍ អ្នកបានចុចកណ្ដុរ ហើយវាឆ្លើយតបអ្នកបន្ទាប់ពី 100 មីលីវិនាទី អ្នកមានអារម្មណ៍ថាមានការពន្យារពេលបន្តិចហើយ។ មួយវិនាទីត្រូវបានគេដឹងថាជាហ្វ្រាំង។

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

យើងជ្រើសរើសទំហំកញ្ចប់។ ក្នុងករណីនីមួយៗយើងអាចធ្វើវាខុសគ្នា។ អាចត្រូវបានដោយស្វ័យប្រវត្តិ។ ហើយយើងជឿជាក់លើប្រសិទ្ធភាពនៃដំណើរការនៃកញ្ចប់មួយ។ នោះគឺយើងលុបកញ្ចប់មួយ ឬ UPDATE ។

និយាយអីញ្ចឹង អ្វីគ្រប់យ៉ាងដែលខ្ញុំកំពុងនិយាយគឺមិនមែនត្រឹមតែ DELETE ប៉ុណ្ណោះទេ។ ដូចដែលអ្នកបានទាយ ទាំងនេះគឺជាប្រតិបត្តិការភាគច្រើនលើទិន្នន័យ។

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

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

ហើយ​យើង​នៅ​តែ​ត្រូវ​រៀបចំ​អ្វី​មួយ​ដើម្បី​ឱ្យ​វា​អាច​ឱ្យ​យើង​ធ្វើ​តាម​នេះ​បាន​ត្រឹមត្រូវ​ក្នុង​ការ​ផលិត។ ឧទាហរណ៍ យើងអាចសរសេរពេលវេលានៅក្នុងកំណត់ហេតុ យើងអាចសរសេរថាយើងនៅទីណាឥឡូវនេះ ហើយអ្នកណាដែលយើងបានលុបឥឡូវនេះ។ ហើយនេះនឹងអនុញ្ញាតឱ្យយើងយល់ពីអ្វីដែលកំពុងកើតឡើងនៅពេលក្រោយ។ ហើយ​ក្នុង​ករណី​មាន​អ្វី​ខុស​ប្រក្រតី ចូរ​ស្វែង​រក​បញ្ហា​ឲ្យ​បាន​លឿន។

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

https://docs.gitlab.com/ee/development/background_migrations.html

តើ​អ្វី​ទៅ​ជា​យុទ្ធ​សា​ស្រ្ត​ចែក​រំលែក? ខ្ញុំឃើញយុទ្ធសាស្ត្របែងចែក 3 ផ្សេងគ្នាដែលអ្នកអភិវឌ្ឍន៍នៅលើកញ្ចប់កំពុងប្រើ។

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

យុទ្ធសាស្ត្រទីពីរ គឺជាវិធីសាស្រ្តដែលមានតុល្យភាព។ វាត្រូវបានប្រើនៅក្នុង Gitlab ។ ពួកគេបានយកនិងស្កេនតុ។ យើងបានរកឃើញព្រំដែននៃកញ្ចប់ ID ដូច្នេះកញ្ចប់នីមួយៗមានកំណត់ត្រា 10 យ៉ាងពិតប្រាកដ។ ហើយដាក់វានៅក្នុងជួរមួយ។ ហើយបន្ទាប់មកយើងដំណើរការ។ អ្នក​អាច​ធ្វើ​វា​បាន​ជា​ច្រើន​ខ្សែ។

នៅក្នុងយុទ្ធសាស្ត្រដំបូងផងដែរ ដោយវិធីនេះ អ្នកអាចធ្វើវាបាននៅក្នុងខ្សែស្រលាយជាច្រើន។ វាមិនពិបាកទេ។

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

ជាទូទៅ ការស្កេនតែសន្ទស្សន៍គឺលឿនជាងការស្កេនសន្ទស្សន៍។

ហើយយើងរកឃើញលេខសម្គាល់របស់យើងយ៉ាងឆាប់រហ័សដែលយើងចង់លុប។ BATCH_SIZE យើងជ្រើសរើសជាមុន។ ហើយ​យើង​មិន​ត្រឹម​តែ​ទទួល​ពួក​គេ​ប៉ុណ្ណោះ​ទេ យើង​ទទួល​ពួក​វា​តាម​វិធី​ពិសេស​មួយ​ហើយ​វាយ​ពួក​គេ​ភ្លាម។ ប៉ុន្តែ​យើង​កំពុង​ចាក់សោ ដូច្នេះ​បើ​គេ​ចាក់​សោ​រួច​ហើយ យើង​មិន​ចាក់សោ​ទេ ប៉ុន្តែ​បន្ត​ទៅ​មុខ ហើយ​យក​អ្នក​បន្ទាប់។ នេះគឺសម្រាប់ការអាប់ដេតរំលងការចាក់សោ។ លក្ខណៈពិសេសដ៏អស្ចារ្យនៃ Postgres នេះអនុញ្ញាតឱ្យយើងធ្វើការនៅក្នុងខ្សែស្រឡាយជាច្រើនប្រសិនបើយើងចង់បាន។ វាអាចទៅរួចក្នុងស្ទ្រីមមួយ។ ហើយនៅទីនេះមាន CTE - នេះគឺជាសំណើមួយ។ ហើយ​យើង​មាន​ការ​លុប​ពិត​ប្រាកដ​នឹង​កើត​ឡើង​នៅ​ជាន់​ទី​ពីរ​នៃ CTE នេះ - returning *. អ្នកអាចត្រឡប់លេខសម្គាល់បាន ប៉ុន្តែវាប្រសើរជាង *ប្រសិនបើអ្នកមិនមានទិន្នន័យច្រើននៅលើបន្ទាត់នីមួយៗ។

ហេតុអ្វីបានជាយើងត្រូវការវា? នេះជាអ្វីដែលយើងត្រូវរាយការណ៍ឡើងវិញ។ ឥឡូវ​នេះ យើង​បាន​លុប​បន្ទាត់​ជា​ច្រើន​ហើយ។ ហើយយើងមានព្រំដែនដោយ ID ឬដោយ created_at ដូចនេះ។ អ្នកអាចធ្វើអប្បបរមា, អតិបរមា។ អ្វីផ្សេងទៀតអាចធ្វើបាន។ អ្នកអាចផ្ទុកច្រើននៅទីនេះ។ ហើយវាងាយស្រួលណាស់សម្រាប់ការត្រួតពិនិត្យ។

មានកំណត់ចំណាំមួយទៀតអំពីសន្ទស្សន៍។ ប្រសិនបើយើងសម្រេចចិត្តថាយើងត្រូវការលិបិក្រមពិសេសសម្រាប់កិច្ចការនេះ នោះយើងត្រូវធ្វើឱ្យប្រាកដថាវាមិនធ្វើឱ្យខូចការអាប់ដេត heap តែ tuples ទេ។ នោះគឺ Postgres មានស្ថិតិបែបនេះ។ នេះអាចត្រូវបានគេមើលឃើញនៅក្នុង pg_stat_user_tables សម្រាប់តារាងរបស់អ្នក។ អ្នកអាចមើលថាតើការអាប់ដេតក្តៅកំពុងត្រូវបានប្រើប្រាស់ឬអត់។

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

ប៉ុន្តែនេះគឺជាយុទ្ធសាស្ត្រដ៏ប្រសើរបំផុត របៀបបំបែកជាបាច់ ហើយបាញ់ជាបាច់ៗ ដោយស្នើសុំមួយ លុបបន្តិច។ល។

ប្រតិបត្តិការយូរ https://gitlab.com/snippets/1890447

ស្ទះស្វ័យប្រវត្តិ - https://gitlab.com/snippets/1889668

បញ្ហារារាំង - https://gitlab.com/snippets/1890428

កំហុសលេខ ៥ គឺជាកំហុសដ៏ធំមួយ។ Nikolai មកពី Okmeter និយាយអំពីការត្រួតពិនិត្យ Postgres ។ ការត្រួតពិនិត្យ Postgres ដ៏ល្អ ជាអកុសលមិនមានទេ។ ខ្លះនៅជិត ខ្លះនៅឆ្ងាយ។ Okmeter គឺជិតល្មមនឹងភាពល្អឥតខ្ចោះ ប៉ុន្តែមានច្រើនបាត់ ហើយត្រូវការបន្ថែម។ អ្នកត្រូវតែត្រៀមខ្លួនសម្រាប់រឿងនេះ។

ឧទាហរណ៍ tuples ស្លាប់ត្រូវបានត្រួតពិនិត្យល្អបំផុត។ ប្រសិនបើអ្នកមានរបស់របរងាប់ជាច្រើននៅក្នុងតុ នោះមានអ្វីមួយខុសហើយ។ វាជាការប្រសើរក្នុងប្រតិកម្មឥឡូវនេះ បើមិនដូច្នេះទេ អាចនឹងមានការរិចរិល ហើយយើងអាចដេកចុះ។ វា​កើតឡើង។

ប្រសិនបើមាន IO ធំនោះវាច្បាស់ណាស់ថានេះមិនល្អទេ។

ប្រតិបត្តិការយូរផងដែរ។ ប្រតិបត្តិការវែងមិនគួរត្រូវបានអនុញ្ញាតនៅលើ OLTP ទេ។ ហើយនេះគឺជាតំណភ្ជាប់ទៅកាន់ផ្នែកខ្លីៗដែលអនុញ្ញាតឱ្យអ្នកយកព័ត៌មានខ្លីៗនេះ ហើយធ្វើការតាមដានប្រតិបត្តិការរយៈពេលវែងមួយចំនួនរួចហើយ។

ហេតុអ្វីបានជាប្រតិបត្តិការរយៈពេលវែងមិនល្អ? ដោយសារតែសោទាំងអស់នឹងត្រូវបានដោះលែងតែនៅចុងបញ្ចប់ប៉ុណ្ណោះ។ ហើយ​យើង​វាយ​អ្នក​រាល់​គ្នា។ លើសពីនេះ យើងទប់ស្កាត់ autovacuum សម្រាប់តារាងទាំងអស់។ វាមិនល្អទាល់តែសោះ។ ទោះបីជាអ្នកបានបើកការរង់ចាំក្តៅនៅលើការចម្លងក៏ដោយ វានៅតែអាក្រក់។ ជាទូទៅ គ្មានកន្លែងណាប្រសើរជាងដើម្បីជៀសវាងប្រតិបត្តិការយូរនោះទេ។

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

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

ពេលខ្លះកំហុសទាំងអស់នេះកើតឡើងជារួម។

តាមគំនិតរបស់ខ្ញុំ កំហុសចម្បងនៅទីនេះគឺការរៀបចំ។ វាគឺជាការរៀបចំ, ដោយសារតែបច្ចេកទេសមិនទាញ។ នេះគឺជាលេខ 2 - ពួកគេបានពិនិត្យនៅកន្លែងខុស។

យើង​ពិនិត្យ​នៅ​កន្លែង​ខុស ព្រោះ​យើង​មិន​មាន​ក្លូន​ផលិត​ដែល​ងាយ​ស្រួល​ពិនិត្យ។ អ្នកអភិវឌ្ឍន៍ប្រហែលជាមិនមានសិទ្ធិចូលដំណើរការផលិតកម្មទាល់តែសោះ។

ហើយយើងមិនបានពិនិត្យនៅទីនោះទេ។ បើ​យើង​បាន​ពិនិត្យ​នៅ​ទីនោះ យើង​នឹង​ឃើញ​វា​ដោយ​ខ្លួន​ឯង។ អ្នកអភិវឌ្ឍន៍បានឃើញវាទាំងអស់ ទោះបីជាមិនមាន DBA ប្រសិនបើគាត់បានពិនិត្យវានៅក្នុងបរិយាកាសល្អ ដែលមានចំនួនទិន្នន័យដូចគ្នា និងទីតាំងដូចគ្នាបេះបិទ។ គាត់នឹងបានឃើញការរិចរិលទាំងអស់នេះ ហើយគាត់នឹងខ្មាស់អៀន។

បន្ថែមទៀតអំពី autovacuum ។ បន្ទាប់​ពី​យើង​បាន​ធ្វើ​ការ​បោស​សម្អាត​ជា​ច្រើន​លាន​ខ្សែ​ហើយ យើង​នៅ​តែ​ត្រូវ​ធ្វើ REPACK ។ នេះមានសារៈសំខាន់ជាពិសេសសម្រាប់សន្ទស្សន៍។ ពួកគេនឹងមានអារម្មណ៍មិនល្អបន្ទាប់ពីយើងសម្អាតអ្វីៗនៅទីនោះ។

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

អ្វីដែលយើងធ្វើគឺជាប្រភពបើកចំហ។ វាត្រូវបានបង្ហោះនៅលើ GitLab ។ ហើយ​យើង​បង្កើត​វា​ដើម្បី​ឱ្យ​មនុស្ស​អាច​ពិនិត្យ​មើល​បាន ទោះ​បី​គ្មាន DBA ក៏ដោយ។ យើងកំពុងធ្វើមន្ទីរពិសោធន៍មូលដ្ឋានទិន្នន័យ ពោលគឺយើងហៅសមាសភាគមូលដ្ឋានដែល Joe កំពុងធ្វើការ។ ហើយអ្នកអាចចាប់យកច្បាប់ចម្លងនៃផលិតកម្ម។ ឥឡូវនេះមានការអនុវត្តរបស់ Joe សម្រាប់ភាពយឺតយ៉ាវ អ្នកអាចនិយាយនៅទីនោះថា “ពន្យល់សំណួរបែបនេះ” ហើយទទួលបានលទ្ធផលភ្លាមៗសម្រាប់ការចម្លងមូលដ្ឋានទិន្នន័យរបស់អ្នក។ អ្នកថែមទាំងអាចលុបនៅទីនោះ ហើយគ្មាននរណាម្នាក់នឹងកត់សម្គាល់វាទេ។

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

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

ឧទាហរណ៍៖ មូលដ្ឋានទិន្នន័យ 5 terabyte ទទួលបានច្បាប់ចម្លងក្នុងរយៈពេលតិចជាង 30 វិនាទី។ ហើយវាមិនអាស្រ័យលើទំហំនោះទេ ពោលគឺវាមិនមានបញ្ហាប៉ុន្មាន terabytes នោះទេ។

ថ្ងៃនេះអ្នកអាចទៅ postgres.ai ហើយជីកចូលទៅក្នុងឧបករណ៍របស់យើង។ អ្នកអាចចុះឈ្មោះដើម្បីមើលអ្វីដែលនៅទីនោះ។ អ្នកអាចដំឡើង bot នេះ។ វាឥតគិតថ្លៃ។ សរសេរ។

សំណួរ

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

នេះ​គឺ​ជា​វិធី​សាស្រ្ដ​ដ៏​ល្អ​មួយ និង​ជា​កិច្ចការ​ដ៏​ល្អ​បំផុត។ វាស្រដៀងទៅនឹងអ្វីដែល pg_repack ធ្វើ វាស្រដៀងនឹងអ្វីដែលអ្នកត្រូវធ្វើនៅពេលអ្នកបង្កើតលេខសម្គាល់ 4 បៃ។ ក្របខណ្ឌជាច្រើនបានធ្វើរឿងនេះកាលពីប៉ុន្មានឆ្នាំមុន ហើយគ្រាន់តែចានបានធំឡើង ហើយពួកគេត្រូវការបំប្លែងទៅជា 8 បៃ។

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

ប្រសិនបើអ្នកក្រឡេកមើល pg_repack នៅលើ GitHub នោះនៅពេលដែលមានភារកិច្ចបំប្លែងលេខសម្គាល់ពី int 4 ទៅ int 8 នោះមានគំនិតមួយដើម្បីប្រើ pg_repack ដោយខ្លួនឯង។ នេះ​ក៏​អាច​ទៅ​រួច​ដែរ ប៉ុន្តែ​វា​ជា​ការ​លួច​ចូល​បន្តិច ប៉ុន្តែ​វា​នឹង​ដំណើរការ​សម្រាប់​វា​ផង​ដែរ។ អ្នកអាចជ្រៀតជ្រែកក្នុងគន្លឹះដែល pg_repack ប្រើ ហើយនិយាយនៅទីនោះ៖ "យើងមិនត្រូវការទិន្នន័យនេះទេ" ពោលគឺ យើងផ្ទេរតែអ្វីដែលយើងត្រូវការប៉ុណ្ណោះ។ ហើយបន្ទាប់មកគាត់គ្រាន់តែប្តូរ ហើយនោះជាវា។

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

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

ខ្ញុំទើបតែមកពីពិភព MySQL បន្តិច ទើបខ្ញុំមកស្តាប់។ ហើយយើងប្រើវិធីសាស្រ្តនេះ។

ប៉ុន្តែ​បើ​យើង​មាន ៩០% ប៉ុណ្ណោះ។ ប្រសិនបើយើងមាន 90% នោះវាមិនល្អណាស់ក្នុងការប្រើវាទេ។

អរគុណសម្រាប់របាយការណ៍! ប្រសិនបើមិនមានធនធានដើម្បីធ្វើច្បាប់ចម្លងពេញលេញនៃផលិតផល តើមានក្បួនដោះស្រាយ ឬរូបមន្តសម្រាប់គណនាបន្ទុក ឬទំហំទេ?

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

អរគុណសម្រាប់របាយការណ៍! អ្នកចាប់ផ្តើមដំបូងអំពីការពិតដែលថាមាន Postgres ត្រជាក់ដែលមានដែនកំណត់បែបនេះប៉ុន្តែវាកំពុងអភិវឌ្ឍ។ ហើយនេះគឺជាឈើច្រត់ទាំងអស់ដោយនិងធំ។ នេះមិនមែនជាការប៉ះទង្គិចជាមួយនឹងការអភិវឌ្ឍន៍របស់ Postgres ខ្លួនឯងទេ ដែល DELETE deferent នឹងលេចឡើង ឬអ្វីផ្សេងទៀតដែលគួរតែរក្សានៅកម្រិតទាប ដែលយើងកំពុងព្យាយាមលាបពណ៌ជាមួយនឹងមធ្យោបាយចម្លែកៗរបស់យើងនៅទីនេះ?

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

រួចរាល់ជាមួយសន្ទស្សន៍។

ខ្ញុំអាចសន្មត់ថាការលៃតម្រូវប៉ុស្តិ៍ត្រួតពិនិត្យដូចគ្នាអាចត្រូវបានដោយស្វ័យប្រវត្តិ។ ថ្ងៃណាមួយវាប្រហែលជា។ ប៉ុន្តែ​បន្ទាប់​មក​ខ្ញុំ​ពិត​ជា​មិន​យល់​សំណួរ​។

សំណួរសួរថា តើមានវ៉ិចទ័រនៃការអភិវឌ្ឍន៍ដែលទៅទីនេះ និងទីនោះ ហើយនៅទីនេះរបស់អ្នកស្របគ្នាដែរឬទេ? ទាំងនោះ។ តើ​គេ​មិន​ទាន់​គិត​ពី​វា​ទេ?

ខ្ញុំបាននិយាយអំពីគោលការណ៍ដែលអាចប្រើបានឥឡូវនេះ។ មាន bot មួយទៀត លោកស្រី Nancyជាមួយនេះ អ្នកអាចធ្វើការលៃតម្រូវប៉ុស្តិ៍ត្រួតពិនិត្យដោយស្វ័យប្រវត្តិ។ តើថ្ងៃណាមួយវានឹងនៅ Postgres ទេ? ខ្ញុំ​មិន​ដឹង​ទេ វា​មិន​ទាន់​បាន​ពិភាក្សា​នៅ​ឡើយ​ទេ។ យើងនៅឆ្ងាយពីនោះ។ ប៉ុន្តែមានអ្នកវិទ្យាសាស្ត្រដែលបង្កើតប្រព័ន្ធថ្មី។ ហើយពួកគេបានរុញយើងចូលទៅក្នុងសន្ទស្សន៍ស្វ័យប្រវត្តិ។ មានការអភិវឌ្ឍន៍។ ឧទាហរណ៍អ្នកអាចមើលការលៃតម្រូវដោយស្វ័យប្រវត្តិ។ វាជ្រើសរើសប៉ារ៉ាម៉ែត្រដោយស្វ័យប្រវត្តិ។ ប៉ុន្តែគាត់នឹងមិនធ្វើការកែតម្រូវប៉ុស្តិ៍ត្រួតពិនិត្យសម្រាប់អ្នកនៅឡើយទេ។ នោះ​គឺ​វា​នឹង​យក​ឡើង​សម្រាប់​ការ​អនុវត្ត, សតិបណ្ដោះ​អាសន្ន​សែល, ល.

ហើយសម្រាប់ការលៃតម្រូវប៉ុស្តិ៍ត្រួតពិនិត្យ អ្នកអាចធ្វើដូចនេះបាន៖ ប្រសិនបើអ្នកមានចង្កោមមួយពាន់ និងផ្នែករឹងផ្សេងគ្នា ម៉ាស៊ីននិម្មិតផ្សេងគ្នានៅក្នុងពពក អ្នកអាចប្រើ bot របស់យើង លោកស្រី Nancy ធ្វើស្វ័យប្រវត្តិកម្ម។ ហើយ max_wal_size នឹងត្រូវបានជ្រើសរើសដោយយោងទៅតាមការកំណត់គោលដៅរបស់អ្នកដោយស្វ័យប្រវត្តិ។ ប៉ុន្តែរហូតមកដល់ពេលនេះ នេះមិនទាន់បានបិទនៅក្នុងស្នូលនៅឡើយទេ ជាអកុសល។

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

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

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

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

នៅពេលដែលយើងកំពុងធ្វើការរើសសំរាមរួចហើយ ហើយយើងមានឧទាហរណ៍ ទង់ដែលបានលុប

នេះគឺជាអ្វីដែល autovacuum ធ្វើដោយស្វ័យប្រវត្តិនៅក្នុង Postgres ។

អូតើគាត់ធ្វើវាទេ?

Autovacuum គឺជាអ្នកប្រមូលសំរាម។

សូមអរគុណ!

អរគុណសម្រាប់របាយការណ៍! តើ​មាន​ជម្រើស​ក្នុង​ការ​រចនា​មូលដ្ឋាន​ទិន្នន័យ​ភ្លាមៗ​ជាមួយ​នឹង​ការ​បែងចែក​ក្នុង​របៀប​ដែល​សំរាម​ទាំងអស់​ប្រឡាក់​ពី​តុ​មេ​ពី​កន្លែង​មួយ​ទៅ​ចំហៀង​ដែរ​ឬ​ទេ?

ជាការពិតណាស់មាន។

តើ​វា​អាច​ការពារ​ខ្លួន​យើង​បាន​ទេ បើ​យើង​បាន​ចាក់សោ​តុ​ដែល​មិន​គួរ​ប្រើ?

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

ប្រភព: www.habr.com