PostgreSQL Antipatterns៖ ផ្លាស់ប្តូរទិន្នន័យដោយឆ្លងកាត់គន្លឹះ

មិនយូរមិនឆាប់ មនុស្សជាច្រើនត្រូវប្រឈមមុខនឹងតម្រូវការដើម្បីកែតម្រូវអ្វីមួយនៅក្នុងកំណត់ត្រាតារាង។ ខ្ញុំ​មាន​រួចហើយ ប្រាប់ខ្ញុំពីរបៀបធ្វើវាឱ្យកាន់តែប្រសើរនិងរបៀប - វាជាការប្រសើរជាងកុំធ្វើវា។ ថ្ងៃនេះខ្ញុំនឹងនិយាយអំពីទិដ្ឋភាពទីពីរនៃការធ្វើបច្ចុប្បន្នភាពដ៏ធំ - អំពីកេះ.

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

តោះបិទគន្លឹះ!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
  UPDATE ...; -- тут долго-долго
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

តាមពិតនោះហើយជាអ្វីទាំងអស់ - អ្វីគ្រប់យ៉ាងត្រូវបានព្យួររួចហើយ.

ពីព្រោះ ALTER TABLE កំណត់ ចូលប្រើផ្តាច់មុខ- សោរដែលគ្មាននរណាម្នាក់កំពុងដំណើរការស្របគ្នា សូម្បីតែមួយសាមញ្ញក៏ដោយ។ SELECTនឹងមិនអាចអានអ្វីពីតារាងបានទេ។ នោះគឺរហូតដល់ប្រតិបត្តិការនេះត្រូវបានបញ្ចប់ អ្នកគ្រប់គ្នាដែលចង់ "គ្រាន់តែអាន" នឹងរង់ចាំ។ ហើយយើងចងចាំរឿងនោះ។ UPDATE យើងមានរយៈពេលយូរ ...

តោះ​បិទ​វា​ឲ្យ​លឿន​សិន​ចាំ​បើក!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
COMMIT;

UPDATE ...;

BEGIN;
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

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

• ALTER TABLE ខ្លួនវាកំពុងរង់ចាំប្រតិបត្តិការផ្សេងទៀតទាំងអស់នៅលើតុ រួមទាំងប្រតិបត្តិការដ៏យូរផងដែរ។ SELECT
• ខណៈពេលដែលគន្លឹះត្រូវបានបិទ, ការផ្លាស់ប្តូរណាមួយនឹង "ហោះហើរដោយ" នៅក្នុងតុ មិនមែនរបស់យើងទេ។ ហើយវានឹងមិនចូលទៅក្នុងគ្រឿងទេ ទោះបីជាវាគួរក៏ដោយ។ បញ្ហា!

ការគ្រប់គ្រងអថេរសម័យ

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

session_replication_role

អាន ហត្ថកម្ម:

យន្តការកេះក៏រងផលប៉ះពាល់ដោយអថេរកំណត់រចនាសម្ព័ន្ធផងដែរ។ session_replication_role. នៅពេលបើកដំណើរការដោយគ្មានការណែនាំបន្ថែម (លំនាំដើម) កេះនឹងចាប់ផ្តើមនៅពេលដែលតួនាទីចម្លងគឺ "ប្រភពដើម" (លំនាំដើម) ឬ "មូលដ្ឋាន" ។ កេះត្រូវបានបើកដោយការណែនាំ ENABLE REPLICA, នឹងធ្វើការតែប្រសិនបើ របៀបសម័យបច្ចុប្បន្ន - "ចម្លង" និងបើកដំណើរការដោយបញ្ជាក់ ENABLE ALWAYSនឹងត្រូវបានកេះដោយមិនគិតពីរបៀបចម្លងបច្ចុប្បន្ន។

ខ្ញុំចង់បញ្ជាក់ជាពិសេសថាការកំណត់មិនអនុវត្តចំពោះមនុស្សគ្រប់គ្នាក្នុងពេលតែមួយដូចជា ALTER TABLEប៉ុន្តែសម្រាប់តែការតភ្ជាប់ពិសេសដាច់ដោយឡែករបស់យើង។ សរុបមក ដូច្នេះគ្មានការកេះកម្មវិធីណាមួយត្រូវបានកេះទេ៖

SET session_replication_role = replica; -- выключили триггеры
UPDATE ...;
SET session_replication_role = DEFAULT; -- вернули в исходное состояние

ស្ថានភាពនៅខាងក្នុងកេះ

ប៉ុន្តែជម្រើសខាងលើដំណើរការសម្រាប់កេះទាំងអស់ក្នុងពេលតែមួយ (ឬអ្នកត្រូវ "ផ្លាស់ប្តូរ" ជាមុននូវគន្លឹះដែលអ្នកមិនចង់បិទ) ។ ហើយប្រសិនបើយើងត្រូវការ "បិទ" គន្លឹះជាក់លាក់មួយ។?

នេះនឹងជួយយើង អថេរសម័យ "អ្នកប្រើប្រាស់":

ឈ្មោះប៉ារ៉ាម៉ែត្រផ្នែកបន្ថែមត្រូវបានសរសេរដូចខាងក្រោម៖ ឈ្មោះផ្នែកបន្ថែម ចំណុច ហើយបន្ទាប់មកឈ្មោះប៉ារ៉ាម៉ែត្រខ្លួនវា ស្រដៀងទៅនឹងឈ្មោះវត្ថុដែលមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់ពេញលេញនៅក្នុង SQL ។ ឧទាហរណ៍៖ plpgsql.variable_conflict។
ដោយសារជម្រើសដែលមិនមែនជាប្រព័ន្ធអាចត្រូវបានកំណត់ក្នុងដំណើរការដែលមិនផ្ទុកម៉ូឌុលផ្នែកបន្ថែមដែលត្រូវគ្នា PostgreSQL ទទួលយក តម្លៃសម្រាប់ឈ្មោះណាមួយដែលមានសមាសភាគពីរ.

ដំបូង​យើង​កែប្រែ​គន្លឹះ​អ្វី​មួយ​ដូច​នេះ៖

BEGIN
    -- процессу конвертации можно делать все
    IF current_setting('mycfg.my_table_convert_process') = 'TRUE' THEN
        IF TG_OP IN ('INSERT', 'UPDATE') THEN
            RETURN NEW;
        ELSE
            RETURN OLD;
        END IF;
    END IF;
...

ដោយវិធីនេះ នេះអាចត្រូវបានធ្វើ "បន្តផ្ទាល់" ដោយមិនមានការទប់ស្កាត់ CREATE OR REPLACE សម្រាប់មុខងារកេះ។ ហើយបន្ទាប់មកនៅក្នុងការតភ្ជាប់ពិសេស យើងរៀបចំអថេរ "របស់យើង"៖

SET mycfg.my_table_convert_process = 'TRUE';
UPDATE ...;
SET mycfg.my_table_convert_process = ''; -- вернули в исходное состояние

តើអ្នកដឹងពីវិធីផ្សេងទៀតទេ? ចែករំលែកនៅក្នុងមតិយោបល់។

ប្រភព: www.habr.com