របៀបរស់រានមានមូលដ្ឋានទិន្នន័យ SQL នៅសតវត្សរ៍ទី 21: ពពក Kubernetes និង PostgreSQL multimaster

ជំរាបសួរអ្នកស្រុក Khabrovsk ។ ថ្នាក់នៅក្នុងក្រុមទីមួយនៃវគ្គសិក្សាចាប់ផ្តើមថ្ងៃនេះ "PostgreSQL". ក្នុងន័យនេះ យើងចង់ប្រាប់អ្នកអំពីរបៀបដែលសិក្ខាសាលាបើកទូលាយលើវគ្គសិក្សានេះបានកើតឡើង។

В មេរៀនបើកបន្ទាប់ យើងបាននិយាយអំពីបញ្ហាប្រឈមដែលមូលដ្ឋានទិន្នន័យ SQL ជួបប្រទះនៅក្នុងយុគសម័យនៃពពក និង Kubernetes ។ ក្នុងពេលជាមួយគ្នានេះ យើងបានពិនិត្យមើលពីរបៀបដែលមូលដ្ឋានទិន្នន័យ SQL សម្របខ្លួន និងផ្លាស់ប្តូរនៅក្រោមឥទ្ធិពលនៃបញ្ហាប្រឈមទាំងនេះ។

webinar ត្រូវបានធ្វើឡើង Valery Bezrukovអ្នកគ្រប់គ្រងការចែកចាយការអនុវត្ត Google Cloud នៅប្រព័ន្ធ EPAM ។

ពេលដើមឈើតូច...

ជាដំបូង ចូរយើងចងចាំពីរបៀបដែលជម្រើសនៃ DBMS បានចាប់ផ្តើមនៅចុងសតវត្សចុងក្រោយនេះ។ ទោះជាយ៉ាងណាក៏ដោយនេះនឹងមិនពិបាកទេព្រោះជម្រើសនៃ DBMS នៅសម័យនោះបានចាប់ផ្តើមនិងបញ្ចប់ ក្រុមហ៊ុន Oracle.

នៅចុងទសវត្សរ៍ទី 90 និងដើមទសវត្សរ៍ឆ្នាំ 2 មិនមានជម្រើសអ្វីឡើយនៅពេលនិយាយអំពីមូលដ្ឋានទិន្នន័យដែលអាចធ្វើមាត្រដ្ឋានឧស្សាហកម្ម។ បាទ/ចាស មាន IBM DBXNUMX, Sybase និងមូលដ្ឋានទិន្នន័យមួយចំនួនផ្សេងទៀតដែលបានមក និងបានទៅ ប៉ុន្តែជាទូទៅ ពួកវាមិនសូវជាគួរឱ្យកត់សម្គាល់ទេប្រឆាំងនឹងផ្ទៃខាងក្រោយរបស់ Oracle ។ ដូច្នោះហើយ ជំនាញរបស់វិស្វករនៅសម័យនោះត្រូវបានចងភ្ជាប់ជាមួយនឹងជម្រើសតែមួយគត់ដែលមាន។

Oracle DBA ត្រូវតែអាច៖

• ដំឡើង Oracle Server ពីឧបករណ៍ចែកចាយ;
• កំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ Oracle៖

• init.ora;
• listener.ora;

- បង្កើត:

• ចន្លោះតុ;
• គ្រោងការណ៍;
• អ្នកប្រើប្រាស់;

- អនុវត្តការបម្រុងទុកនិងស្តារឡើងវិញ;
- អនុវត្តការត្រួតពិនិត្យ;
- ដោះស្រាយជាមួយសំណើល្អបំផុត។

ក្នុងពេលជាមួយគ្នានេះ មិនមានតម្រូវការពិសេសពី Oracle DBA ទេ៖

• អាចជ្រើសរើស DBMS ល្អបំផុត ឬបច្ចេកវិទ្យាផ្សេងទៀតសម្រាប់ការរក្សាទុក និងដំណើរការទិន្នន័យ។
• ផ្តល់នូវភាពអាចរកបានខ្ពស់ និងលទ្ធភាពធ្វើមាត្រដ្ឋានផ្ដេក (នេះមិនមែនតែងតែជាបញ្ហា DBA ទេ);
• ចំណេះដឹងល្អនៃមុខវិជ្ជា ហេដ្ឋារចនាសម្ព័ន្ធ ស្ថាបត្យកម្មកម្មវិធី OS;
• ផ្ទុក និងដកទិន្នន័យ ផ្ទេរទិន្នន័យរវាង DBMSs ផ្សេងៗគ្នា។

ជាទូទៅប្រសិនបើយើងនិយាយអំពីជម្រើសនៅសម័យនោះវាប្រហាក់ប្រហែលនឹងជម្រើសនៅក្នុងហាងសូវៀតនៅចុងទសវត្សរ៍ទី 80៖

ពេលវេលារបស់យើង។

តាំង​ពី​ពេល​នោះ​មក ដើមឈើ​បាន​រីក​ចម្រើន ពិភពលោក​បាន​ផ្លាស់​ប្តូរ ហើយ​វា​បាន​ក្លាយ​ជា​អ្វី​មួយ​ដូច​នេះ៖

ទីផ្សារ DBMS ក៏បានផ្លាស់ប្តូរផងដែរ ដូចដែលអាចមើលឃើញយ៉ាងច្បាស់ពីរបាយការណ៍ចុងក្រោយពី Gartner៖

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

1. អតិថិជនជាច្រើនកំពុងស្ថិតនៅលើផ្លូវទៅកាន់ការផ្លាស់ប្តូរកម្មវិធីទៅកាន់ពពក។
2. បច្ចេកវិទ្យាថ្មីលេចឡើងជាលើកដំបូងនៅក្នុងពពក ហើយវាមិនមែនជាការពិតដែលថាពួកគេនឹងផ្លាស់ទីទៅហេដ្ឋារចនាសម្ព័ន្ធដែលមិនមែនជាពពកនោះទេ។
3. គំរូកំណត់តម្លៃតាមដែលអ្នកទៅបានក្លាយជារឿងធម្មតា។ មនុស្សគ្រប់រូបចង់ចំណាយសម្រាប់តែអ្វីដែលពួកគេប្រើប្រាស់ប៉ុណ្ណោះ ហើយនេះមិនមែនជានិន្នាការនោះទេ ប៉ុន្តែគ្រាន់តែជាសេចក្តីថ្លែងការណ៍នៃការពិតប៉ុណ្ណោះ។

ចុះពេលនេះ?

ថ្ងៃនេះយើងទាំងអស់គ្នានៅលើពពក។ ហើយសំណួរដែលកើតឡើងសម្រាប់យើងគឺជាសំណួរនៃជម្រើស។ ហើយវាមានទំហំធំ បើទោះបីជាយើងនិយាយតែអំពីជម្រើសនៃបច្ចេកវិទ្យា DBMS ក្នុងទម្រង់ On-premises ក៏ដោយ។ យើងក៏មានសេវាកម្មគ្រប់គ្រង និង SaaS ផងដែរ។ ដូច្នេះជម្រើសកាន់តែពិបាកជារៀងរាល់ឆ្នាំ។

រួមជាមួយនឹងសំណួរនៃជម្រើសក៏មានផងដែរ។ កត្តាកំណត់:

• តម្លៃ. បច្ចេកវិទ្យាជាច្រើននៅតែចំណាយប្រាក់។
• ជំនាញ. ប្រសិនបើយើងកំពុងនិយាយអំពីកម្មវិធីឥតគិតថ្លៃ នោះសំណួរនៃជំនាញកើតឡើង ចាប់តាំងពីកម្មវិធីឥតគិតថ្លៃតម្រូវឱ្យមានសមត្ថភាពគ្រប់គ្រាន់ពីមនុស្សដែលដាក់ពង្រាយ និងដំណើរការវា។
• មុខងារ. មិនមែនគ្រប់សេវាកម្មទាំងអស់ដែលមាននៅក្នុងពពក និងត្រូវបានសាងសង់ទេ និយាយថាសូម្បីតែនៅលើ Postgres ដូចគ្នាក៏មានមុខងារដូចគ្នាទៅនឹង Postgres On-premises ដែរ។ នេះ​ជា​កត្តា​សំខាន់​ដែល​ត្រូវ​ដឹង​និង​យល់។ លើសពីនេះទៅទៀត កត្តានេះកាន់តែសំខាន់ជាងចំណេះដឹងអំពីសមត្ថភាពលាក់កំបាំងមួយចំនួននៃ DBMS តែមួយ។

អ្វីដែលត្រូវបានរំពឹងទុកឥឡូវនេះពី DA/DE:

• ការយល់ដឹងល្អនៃប្រធានបទនិងស្ថាបត្យកម្មកម្មវិធី;
• សមត្ថភាពក្នុងការជ្រើសរើសបច្ចេកវិជ្ជា DBMS ឱ្យបានត្រឹមត្រូវដោយគិតគូរពីកិច្ចការនៅនឹងដៃ។
• សមត្ថភាពក្នុងការជ្រើសរើសវិធីសាស្រ្តដ៏ល្អប្រសើរសម្រាប់ការអនុវត្តបច្ចេកវិទ្យាដែលបានជ្រើសរើសនៅក្នុងបរិបទនៃដែនកំណត់ដែលមានស្រាប់។
• សមត្ថភាពក្នុងការអនុវត្តការផ្ទេរទិន្នន័យនិងការធ្វើចំណាកស្រុក;
• សមត្ថភាពក្នុងការអនុវត្ត និងដំណើរការដំណោះស្រាយដែលបានជ្រើសរើស។

ឧទាហរណ៍ខាងក្រោម ផ្អែកលើ GCP បង្ហាញពីរបៀបដែលជម្រើសនៃបច្ចេកវិទ្យាមួយ ឬមួយផ្សេងទៀតសម្រាប់ធ្វើការជាមួយទិន្នន័យដំណើរការអាស្រ័យលើរចនាសម្ព័ន្ធរបស់វា៖

សូមចំណាំថា PostgreSQL មិនត្រូវបានរួមបញ្ចូលនៅក្នុងគ្រោងការណ៍នោះទេ ហើយនេះគឺដោយសារតែវាត្រូវបានលាក់នៅក្រោមវាក្យស័ព្ទ។ ពពក SQL. ហើយនៅពេលដែលយើងទៅដល់ Cloud SQL យើងត្រូវធ្វើការជ្រើសរើសម្តងទៀត៖

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

សរុប:

1. អ្នកកាន់តែទៅមុខ សំណួរនៃជម្រើសកាន់តែចុច។ ហើយបើទោះបីជាអ្នកមើលតែនៅ GCP, សេវាកម្មដែលបានគ្រប់គ្រង និង SaaS ក៏ដោយ នោះការលើកឡើងមួយចំនួនអំពី RDBMS លេចឡើងតែនៅជំហានទី 4 ប៉ុណ្ណោះ (ហើយមាន Spanner នៅក្បែរនោះ)។ លើសពីនេះ ជម្រើសនៃ PostgreSQL លេចឡើងក្នុងជំហានទី 5 ហើយនៅជាប់វាក៏មាន MySQL និង SQL Server ផងដែរ នោះគឺ មានអ្វីៗគ្រប់យ៉ាង ប៉ុន្តែអ្នកត្រូវជ្រើសរើស.
2. យើងមិនត្រូវភ្លេចអំពីការរឹតបន្តឹងប្រឆាំងនឹងផ្ទៃខាងក្រោយនៃការល្បួងនោះទេ។ ជាទូទៅមនុស្សគ្រប់គ្នាចង់បាន Spanner ប៉ុន្តែវាមានតម្លៃថ្លៃ។ ជាលទ្ធផល សំណើធម្មតាមើលទៅដូចនេះ៖ "សូមធ្វើឱ្យយើងក្លាយជា Spanner ប៉ុន្តែសម្រាប់តម្លៃនៃ Cloud SQL អ្នកគឺជាអ្នកជំនាញ!"

តើយើងគួរធ្វើអ្វី?

ដោយ​មិន​បាន​អះអាង​ថា​ជា​ការ​ពិត​បំផុត​នោះ​ទេ​សូម​និយាយ​ដូច​ខាង​ក្រោម​នេះ​:

យើងត្រូវផ្លាស់ប្តូរវិធីសាស្រ្តរបស់យើងក្នុងការរៀន៖

• មិនមានចំណុចណាមួយក្នុងការបង្រៀនពីរបៀបដែល DBAs ត្រូវបានបង្រៀនពីមុនមកនោះទេ។
• ចំណេះដឹងនៃផលិតផលមួយគឺមិនគ្រប់គ្រាន់ទៀតទេ;
• ប៉ុន្តែការដឹងរាប់សិបនាក់នៅកម្រិតមួយគឺមិនអាចទៅរួចទេ។

អ្នក​ត្រូវ​ដឹង​មិន​ត្រឹម​តែ​ប៉ុណ្ណោះ ហើយ​មិន​ដឹង​ថា​ផលិតផល​មាន​តម្លៃ​ប៉ុន្មាន​នោះ​ទេ ប៉ុន្តែ៖

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

អ្នកក៏ត្រូវមានលទ្ធភាពផ្ទេរទិន្នន័យ និងយល់ពីគោលការណ៍ជាមូលដ្ឋាននៃការរួមបញ្ចូលជាមួយ ETL ។

ករណីពិត

កាលពីពេលថ្មីៗនេះ វាចាំបាច់ក្នុងការបង្កើតផ្នែកខាងក្រោយសម្រាប់កម្មវិធីទូរស័ព្ទ។ នៅពេលដែលការងារបានចាប់ផ្តើមនៅលើវា ផ្នែកខាងក្រោយត្រូវបានបង្កើតរួចហើយ និងរួចរាល់សម្រាប់ការអនុវត្ត ហើយក្រុមអភិវឌ្ឍន៍បានចំណាយពេលប្រហែល 2 ឆ្នាំលើគម្រោងនេះ។ ភារកិច្ចខាងក្រោមត្រូវបានកំណត់៖

• បង្កើត CI/CD;
• ពិនិត្យមើលស្ថាបត្យកម្ម;
• ដាក់វាឱ្យដំណើរការទាំងអស់។

កម្មវិធីខ្លួនវាគឺជាសេវាមីក្រូ ហើយកូដ Python/Django ត្រូវបានបង្កើតឡើងពីដំបូង និងដោយផ្ទាល់នៅក្នុង GCP ។ ចំពោះទស្សនិកជនគោលដៅ វាត្រូវបានគេសន្មត់ថានឹងមានតំបន់ពីរគឺសហរដ្ឋអាមេរិក និងសហភាពអឺរ៉ុប ហើយចរាចរណ៍ត្រូវបានចែកចាយតាមរយៈឧបករណ៍តុល្យភាពបន្ទុកសកល។ បន្ទុកការងារ និងការគណនាទាំងអស់ដំណើរការនៅលើ Google Kubernetes Engine ។

ចំពោះទិន្នន័យមានរចនាសម្ព័ន្ធចំនួន ៣៖

• ឃ្លាំងផ្ទុកពពក;
• ឃ្លាំងទិន្នន័យ;
• Cloud SQL (PostgreSQL) ។

មនុស្សម្នាក់ប្រហែលជាឆ្ងល់ថាហេតុអ្វីបានជា Cloud SQL ត្រូវបានជ្រើសរើស? ដើម្បីប្រាប់ការពិត សំណួរបែបនេះបានបណ្តាលឱ្យមានការផ្អាកមួយចំនួនដែលឆ្គងក្នុងប៉ុន្មានឆ្នាំថ្មីៗនេះ - មានអារម្មណ៍ថាមនុស្សមានការខ្មាស់អៀនចំពោះមូលដ្ឋានទិន្នន័យទំនាក់ទំនង ប៉ុន្តែយ៉ាងណាក៏ដោយពួកគេនៅតែបន្តប្រើប្រាស់វាយ៉ាងសកម្ម ;-)។

ចំពោះករណីរបស់យើង Cloud SQL ត្រូវបានជ្រើសរើសសម្រាប់ហេតុផលដូចខាងក្រោម៖

1. ដូចដែលបានរៀបរាប់រួច កម្មវិធីនេះត្រូវបានបង្កើតឡើងដោយប្រើប្រាស់ Django ហើយវាមានគំរូសម្រាប់គូសផែនទីទិន្នន័យជាប់លាប់ពីមូលដ្ឋានទិន្នន័យ SQL ទៅ Python objects (Django ORM)។
2. ក្របខ័ណ្ឌខ្លួនវាគាំទ្របញ្ជីកំណត់ដោយយុត្តិធម៌នៃ DBMSs៖

• PostgreSQL;
• ម៉ារីយ៉ាឌីប៊ី;
• MySQL;
• oracles;
• SQLite ។

ដូច្នោះហើយ PostgreSQL ត្រូវបានជ្រើសរើសពីបញ្ជីនេះដោយវិចារណញាណ (ជាការប្រសើរណាស់ វាមិនមែនជា Oracle ដើម្បីជ្រើសរើសទេ)។

អ្វីដែលបាត់៖

• កម្មវិធីនេះត្រូវបានដាក់ពង្រាយតែនៅក្នុងតំបន់ចំនួន 2 ហើយទី 3 បានបង្ហាញខ្លួននៅក្នុងផែនការ (អាស៊ី);
• មូលដ្ឋានទិន្នន័យមានទីតាំងនៅតំបន់អាមេរិកខាងជើង (Iowa);
• នៅលើផ្នែកនៃអតិថិជនមានការព្រួយបារម្ភអំពីលទ្ធភាព ការពន្យាពេលចូលប្រើ ពីអឺរ៉ុប និងអាស៊ី និង ការរំខាន នៅក្នុងសេវាកម្ម ក្នុងករណី DBMS ឈប់ដំណើរការ។

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

ការលំបាកគឺថាអតិថិជនមិនចង់បោះបង់ដោយប្រើសេវាកម្មគ្រប់គ្រង និង Cloud SQL ។ ហើយសមត្ថភាពរបស់ Cloud SQL បច្ចុប្បន្នមានកម្រិត។ Cloud SQL គាំទ្រភាពអាចរកបានខ្ពស់ (HA) និង Read Replica (RR) ប៉ុន្តែ RR ដូចគ្នាត្រូវបានគាំទ្រតែនៅក្នុងតំបន់មួយប៉ុណ្ណោះ។ ដោយបានបង្កើតមូលដ្ឋានទិន្នន័យនៅក្នុងតំបន់អាមេរិក អ្នកមិនអាចបង្កើតការចម្លងការអាននៅក្នុងតំបន់អ៊ឺរ៉ុបដោយប្រើ Cloud SQL ទោះបីជា Postgres ខ្លួនវាមិនរារាំងអ្នកពីការធ្វើវាក៏ដោយ។ ការឆ្លើយឆ្លងជាមួយនិយោជិតរបស់ Google បានដឹកនាំកន្លែងណា ហើយបញ្ចប់ដោយការសន្យាក្នុងទម្រង់ "យើងដឹងពីបញ្ហា ហើយកំពុងធ្វើការលើវា ថ្ងៃណាមួយបញ្ហានឹងត្រូវបានដោះស្រាយ"។

ប្រសិនបើយើងរាយបញ្ជីសមត្ថភាពរបស់ Cloud SQL ដោយសង្ខេប វានឹងមើលទៅដូចនេះ៖

1. ភាពអាចរកបានខ្ពស់ (HA):

• នៅក្នុងតំបន់មួយ;
• តាមរយៈការចម្លងថាស;
• ម៉ាស៊ីន PostgreSQL មិនត្រូវបានប្រើទេ។
• ការគ្រប់គ្រងដោយស្វ័យប្រវត្តិនិងដោយដៃអាចធ្វើទៅបាន - បរាជ័យ / បរាជ័យ;
• នៅពេលប្តូរ DBMS មិនអាចប្រើបានច្រើននាទី។

2. អានចម្លង (RR)៖

• នៅក្នុងតំបន់មួយ;
• រង់ចាំក្តៅ;
• ការចម្លងស្ទ្រីម PostgreSQL ។

លើសពីនេះទៀតដូចទម្លាប់នៅពេលជ្រើសរើសបច្ចេកវិទ្យាអ្នកតែងតែប្រឈមមុខនឹងមួយចំនួន ការរឹតបន្តឹង:

• អតិថិជនមិនចង់បង្កើតអង្គភាព និងប្រើ IaaS ទេ លើកលែងតែតាមរយៈ GKE ។
• អតិថិជនមិនចង់ដាក់ពង្រាយសេវាខ្លួនឯង PostgreSQL/MySQL ទេ។
• ជាការប្រសើរណាស់, ជាទូទៅ, Google Spanner នឹងពិតជាសមរម្យប្រសិនបើវាមិនមែនសម្រាប់តម្លៃរបស់វា, ទោះជាយ៉ាងណា, Django ORM មិនអាចធ្វើការជាមួយវា, ប៉ុន្តែវាជារឿងល្អ។

ដោយពិចារណាលើស្ថានភាពនេះ អតិថិជនបានទទួលសំណួរបន្ទាប់៖ "តើ​អ្នក​អាច​ធ្វើ​អ្វី​ដែល​ស្រដៀង​គ្នា​នេះ​ដើម្បី​ឱ្យ​វា​ដូច​ជា Google Spanner ប៉ុន្តែ​ក៏​អាច​ធ្វើ​ការ​ជាមួយ Django ORM ដែរ?"

ជម្រើសដំណោះស្រាយលេខ 0

រឿងដំបូងដែលចូលមកក្នុងគំនិត៖

• ស្នាក់នៅក្នុង CloudSQL;
• វានឹងមិនមានការចម្លងពីគ្នារវាងតំបន់ក្នុងទម្រង់ណាមួយឡើយ។
• ព្យាយាមភ្ជាប់ការចម្លងទៅ Cloud SQL ដែលមានស្រាប់ដោយ PostgreSQL;
• បើកដំណើរការវត្ថុ PostgreSQL នៅកន្លែងណាមួយ និងដោយរបៀបណា ប៉ុន្តែយ៉ាងហោចណាស់កុំប៉ះមេ។

Alas វាបានប្រែក្លាយថាវាមិនអាចធ្វើបានទេព្រោះមិនមានការចូលប្រើម៉ាស៊ីន (វាគឺនៅក្នុងគម្រោងផ្សេងគ្នាទាំងស្រុង) - pg_hba និងដូច្នេះនៅលើហើយវាក៏មិនមានសិទ្ធិចូលប្រើក្រោម superuser ដែរ។

ជម្រើសដំណោះស្រាយលេខ 1

ក្រោយ​ពី​ការ​គិត​ពិចារណា​បន្ថែម​ទៀត និង​គិត​ពី​ស្ថានភាព​មុនៗ ដំណើរ​នៃ​ការ​គិត​បាន​ផ្លាស់​ប្ដូរ​ខ្លះ​ៗ៖

• យើងនៅតែព្យាយាមស្នាក់នៅក្នុង CloudSQL ប៉ុន្តែយើងកំពុងប្តូរទៅ MySQL ព្រោះ Cloud SQL ដោយ MySQL មានមេខាងក្រៅ ដែល៖

- គឺជាប្រូកស៊ីសម្រាប់ MySQL ខាងក្រៅ។
- មើលទៅដូចជាឧទាហរណ៍ MySQL ។
- បង្កើត​ឡើង​សម្រាប់​ការ​ផ្ទេរ​ទិន្នន័យ​ពី​ពពក​ផ្សេង​ទៀត​ឬ​នៅ​ក្នុង​បរិវេណ​។

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

តាមពិតនៅចំណុចនេះ វាច្បាស់ណាស់ថា Cloud SQL មិនសមរម្យទាល់តែសោះ។ ដូចដែលពួកគេនិយាយ យើងបានធ្វើអ្វីគ្រប់យ៉ាងដែលយើងអាចធ្វើបាន។

ជម្រើសដំណោះស្រាយលេខ 2

ដោយសារវាមិនអាចស្ថិតនៅក្នុងក្របខណ្ឌ Cloud SQL យើងព្យាយាមបង្កើតតម្រូវការសម្រាប់ដំណោះស្រាយសម្របសម្រួល។ តម្រូវការបានប្រែទៅជាដូចខាងក្រោម:

• ធ្វើការនៅក្នុង Kubernetes ការប្រើប្រាស់អតិបរមានៃធនធាន និងសមត្ថភាពរបស់ Kubernetes (DCS, ...) និង GCP (LB, ...);
• កង្វះ ballast ពី bunch នៃអ្វីដែលមិនចាំបាច់នៅក្នុងពពកដូចជា HA ប្រូកស៊ី;
• សមត្ថភាពក្នុងការដំណើរការ PostgreSQL ឬ MySQL នៅក្នុងតំបន់ HA សំខាន់; នៅក្នុងតំបន់ផ្សេងទៀត - HA ពី RR នៃតំបន់សំខាន់បូកនឹងច្បាប់ចម្លងរបស់វា (សម្រាប់ភាពជឿជាក់);
• multi master (ខ្ញុំ​មិន​ចង់​ទាក់ទង​គាត់​ទេ ប៉ុន្តែ​វា​មិន​សំខាន់​ខ្លាំង​ណាស់​)

.
ជាលទ្ធផលនៃការទាមទារទាំងនេះ ទំDBMS សមរម្យ និងជម្រើសចង:

• MySQL Galera;
• សត្វកន្លាតDB;
• ឧបករណ៍ PostgreSQL

:
- pgpool-II;
— Patroni ។

MySQL Galera

បច្ចេកវិទ្យា MySQL Galera ត្រូវបានបង្កើតឡើងដោយ Codership និងជាកម្មវិធីជំនួយសម្រាប់ InnoDB ។ លក្ខណៈពិសេស៖

• មេច្រើន;
• ការចម្លងតាមកាលកំណត់;
• ការអានពីថ្នាំងណាមួយ;
• កត់ត្រាទៅថ្នាំងណាមួយ;
• យន្តការ HA ដែលមានស្រាប់;
• មានតារាង Helm ពី Bitnami ។

កន្លាតDB

យោងតាមការពិពណ៌នា រឿងនេះគឺពិតជាគ្រាប់បែក និងជាគម្រោងប្រភពបើកចំហដែលសរសេរនៅក្នុង Go ។ អ្នកចូលរួមសំខាន់គឺ Cockroach Labs (បង្កើតឡើងដោយមនុស្សមកពី Google) ។ DBMS ទំនាក់ទំនងនេះត្រូវបានបង្កើតឡើងដំបូងដើម្បីចែកចាយ (ជាមួយនឹងការធ្វើមាត្រដ្ឋានផ្តេកចេញពីប្រអប់) និងមានភាពអត់ធ្មត់ចំពោះកំហុស។ អ្នកនិពន្ធរបស់ខ្លួនមកពីក្រុមហ៊ុនបានគូសបញ្ជាក់ពីគោលដៅនៃ "ការរួមបញ្ចូលភាពសម្បូរបែបនៃមុខងារ SQL ជាមួយនឹងលទ្ធភាពប្រើប្រាស់ផ្ដេកដែលស៊ាំនឹងដំណោះស្រាយ NoSQL"។

ប្រាក់រង្វាន់ដ៏ល្អមួយគឺការគាំទ្រសម្រាប់ពិធីការការតភ្ជាប់ក្រោយដំណើរការ។

Pgpool

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

ប៉ាតូនី

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

តើអ្នកជ្រើសរើសអ្វីនៅទីបញ្ចប់?

ជម្រើសមិនងាយស្រួលទេ៖

1. កន្លាតDB - ភ្លើងប៉ុន្តែងងឹត;
2. MySQL Galera - ក៏មិនអាក្រក់ដែរ វាត្រូវបានគេប្រើនៅកន្លែងជាច្រើន ប៉ុន្តែ MySQL;
3. Pgpool - អង្គភាពដែលមិនចាំបាច់ជាច្រើន ការរួមបញ្ចូលជាមួយពពក និង K8s ។
4. ប៉ាតូនី - ការរួមបញ្ចូលដ៏ល្អជាមួយ K8s គ្មានអង្គភាពដែលមិនចាំបាច់ រួមបញ្ចូលយ៉ាងល្អជាមួយ GCP LB ។

ដូច្នេះជម្រើសបានធ្លាក់លើ Patroni ។

ការរកឃើញ

វាដល់ពេលដែលត្រូវសរុបដោយសង្ខេប។ បាទ ពិភពលោកនៃហេដ្ឋារចនាសម្ព័ន្ធ IT បានផ្លាស់ប្តូរយ៉ាងខ្លាំង ហើយនេះគ្រាន់តែជាការចាប់ផ្តើមប៉ុណ្ណោះ។ ហើយប្រសិនបើពីមុនពពកគ្រាន់តែជាប្រភេទហេដ្ឋារចនាសម្ព័ន្ធផ្សេងទៀតនោះ ឥឡូវនេះអ្វីៗគឺខុសគ្នា។ ជាងនេះទៅទៀត ការច្នៃប្រឌិតនៅក្នុងពពកកំពុងលេចឡើងឥតឈប់ឈរ ពួកគេនឹងលេចឡើង ហើយប្រហែលជាពួកគេនឹងលេចឡើងតែនៅក្នុងពពកប៉ុណ្ណោះ ហើយនៅពេលនោះដោយការខិតខំប្រឹងប្រែងនៃការចាប់ផ្តើមអាជីវកម្ម តើពួកគេនឹងផ្ទេរទៅកន្លែងធ្វើការឬអត់។

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

ប្រភព: www.habr.com