តើមូលដ្ឋានទិន្នន័យរស់នៅក្នុង Kubernetes ដែរឬទេ?

យ៉ាងដូចម្ដេច ជាប្រវត្តិសាស្ត្រ ឧស្សាហកម្ម IT ត្រូវបានបែងចែកទៅជាជំរុំលក្ខខណ្ឌពីរសម្រាប់ហេតុផលណាមួយ៖ អ្នកដែល "សម្រាប់" និងអ្នកដែល "ប្រឆាំងនឹង" ។ ជាងនេះទៅទៀត កម្មវត្ថុនៃវិវាទអាចជាការបំពានទាំងស្រុង។ តើ OS មួយណាល្អជាង៖ Win ឬ Linux? នៅលើស្មាតហ្វូន Android ឬ iOS? តើ​អ្នក​គួរ​ទុក​អ្វី​គ្រប់​យ៉ាង​នៅ​ក្នុង​ពពក ឬ​ដាក់​វា​នៅ​កន្លែង​ផ្ទុក RAID ត្រជាក់ ហើយ​ដាក់​វីស​នៅ​កន្លែង​សុវត្ថិភាព? តើមនុស្ស PHP មានសិទ្ធិត្រូវបានគេហៅថាជាអ្នកសរសេរកម្មវិធីទេ? វិវាទទាំងនេះ ជួនកាលមានទាំងស្រុងនៅក្នុងធម្មជាតិ ហើយមិនមានមូលដ្ឋានអ្វីក្រៅពីចំណាប់អារម្មណ៍កីឡា។

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

ហើយវានឹងហាក់បីដូចជា នេះនឹងក្លាយជាជម្លោះដ៏សាមញ្ញមួយរវាងភាគីទាំងពីរនៃកាក់ដូចគ្នា។ ដូចជាគ្មានន័យ និងគ្មានមេត្តា ដូចការប្រឈមមុខគ្នាដ៏អស់កល្បរវាង Win vs Linux ដែលមនុស្សគ្រប់គ្រាន់មាននៅកន្លែងណាមួយនៅកណ្តាល។ ប៉ុន្តែនៅក្នុងករណីនៃកុងតឺន័រ មិនមែនអ្វីៗទាំងអស់គឺសាមញ្ញនោះទេ។ ជាធម្មតានៅក្នុងវិវាទបែបនេះមិនមានភាគីខាងស្ដាំទេ ប៉ុន្តែក្នុងករណី "ប្រើ" ឬ "មិនប្រើ" ធុងសម្រាប់រក្សាទុកមូលដ្ឋានទិន្នន័យ អ្វីគ្រប់យ៉ាងប្រែទៅជាចិត្តសប្បុរសដោយអាស្រ័យ។ ដោយសារតែក្នុងន័យជាក់លាក់មួយ ទាំងអ្នកគាំទ្រ និងអ្នកប្រឆាំងនៃវិធីសាស្រ្តនេះគឺត្រឹមត្រូវ។

ផ្នែក​ខាង​ភ្លឺ

ទឡ្ហីករណ៍របស់ The Light Side អាចត្រូវបានពិពណ៌នាយ៉ាងខ្លីនៅក្នុងឃ្លាមួយថា “ជំរាបសួរ 2k19 គឺនៅខាងក្រៅបង្អួច!” ពិតណាស់ វាស្តាប់ទៅដូចជាប្រជាភិថុតិ ប៉ុន្តែប្រសិនបើអ្នកស្វែងយល់លម្អិតអំពីស្ថានភាពនោះ វាមានគុណសម្បត្តិរបស់វា។ ចូរតម្រៀបពួកវាចេញឥឡូវនេះ។

ឧបមាថាអ្នកមានគម្រោងបណ្តាញដ៏ធំមួយ។ វា​អាច​ត្រូវ​បាន​បង្កើត​ឡើង​ដំបូង​ដោយ​ឈរ​លើ​មូលដ្ឋាន​នៃ​វិធី​សាស្រ្ដ​មីក្រូ​សេវា ឬ​នៅ​ពេល​ខ្លះ​វា​បាន​មក​ដល់​វា​តាម​រយៈ​ផ្លូវ​វិវត្តន៍ - តាមពិត​នេះ​មិន​សំខាន់​ខ្លាំង​ទេ។ អ្នកបានខ្ចាត់ខ្ចាយគម្រោងរបស់យើងទៅជាសេវាកម្មខ្នាតតូចដាច់ដោយឡែក រៀបចំការចាត់ចែង ការផ្ទុកតុល្យភាព និងការធ្វើមាត្រដ្ឋាន។ ហើយឥឡូវនេះ ដោយមានមនសិការច្បាស់លាស់ អ្នកពិសា mojito នៅក្នុងអង្រឹងកំឡុងពេលផលប៉ះពាល់ habra ជំនួសឱ្យការបង្កើន servers ដែលធ្លាក់ចុះ។ ប៉ុន្តែនៅក្នុងសកម្មភាពទាំងអស់អ្នកត្រូវតែស្រប។ ជាញឹកញាប់ណាស់ មានតែកម្មវិធីខ្លួនវាប៉ុណ្ណោះ កូដ - ត្រូវបានផ្ទុក។ តើ​យើង​មាន​អ្វី​ទៀត​ក្រៅ​ពី​កូដ?

ត្រូវហើយ ទិន្នន័យ។ បេះដូងនៃគម្រោងណាមួយគឺទិន្នន័យរបស់វា៖ វាអាចជា DBMS ធម្មតា - MySQL, Postgre, MongoDB ឬការផ្ទុកដែលប្រើសម្រាប់ការស្វែងរក (ElasticSearch) ការផ្ទុកតម្លៃគន្លឹះសម្រាប់ឃ្លាំងសម្ងាត់ - ឧទាហរណ៍ redis ។ល។ បច្ចុប្បន្ននេះយើងមិន យើងនឹងនិយាយអំពីជម្រើសនៃការអនុវត្តកម្មវិធីខាងក្រោយដែលគាំងនៅពេលដែលមូលដ្ឋានទិន្នន័យគាំងដោយសារតែសំណួរដែលសរសេរមិនបានល្អ ហើយផ្ទុយទៅវិញយើងនឹងនិយាយអំពីការធានានូវកំហុសនៃមូលដ្ឋានទិន្នន័យនេះនៅក្រោមការផ្ទុកម៉ាស៊ីនភ្ញៀវ។ យ៉ាងណាមិញ នៅពេលដែលយើងផ្ទុកកម្មវិធីរបស់យើង ហើយអនុញ្ញាតឱ្យវាធ្វើមាត្រដ្ឋានដោយសេរី ដើម្បីដំណើរការចំនួននៃសំណើចូលណាមួយ វានឹងបង្កើនការផ្ទុកនៅលើមូលដ្ឋានទិន្នន័យ។

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

វាមានភាពឡូជីខលច្រើនក្នុងការដាក់ចង្កោមមិនត្រឹមតែកម្មវិធីខ្លួនវាប៉ុណ្ណោះទេ ថែមទាំងសេវាកម្មដែលទទួលខុសត្រូវក្នុងការរក្សាទុកទិន្នន័យផងដែរ។ ដោយការដាក់ចង្កោម និងដាក់ពង្រាយម៉ាស៊ីនមេគេហទំព័រដែលធ្វើការដោយឯករាជ្យ និងចែកចាយបន្ទុកក្នុងចំណោមពួកគេនៅក្នុង k8s យើងកំពុងដោះស្រាយបញ្ហានៃការធ្វើសមកាលកម្មទិន្នន័យរួចហើយ - មតិដូចគ្នានៅលើការបង្ហោះ ប្រសិនបើយើងយកប្រព័ន្ធផ្សព្វផ្សាយ ឬប្លក់វេទិកាមួយចំនួនជាឧទាហរណ៍។ ក្នុងករណីណាក៏ដោយ យើងមាន intra-cluster សូម្បីតែនិម្មិត តំណាងនៃ database ជា ExternalService។ សំណួរគឺថាមូលដ្ឋានទិន្នន័យខ្លួនវាមិនទាន់ត្រូវបានចង្កោមនៅឡើយទេ - ម៉ាស៊ីនមេបណ្តាញដែលដាក់ពង្រាយក្នុងគូបយកព័ត៌មានអំពីការផ្លាស់ប្តូរពីមូលដ្ឋានទិន្នន័យប្រយុទ្ធឋិតិវន្តរបស់យើង ដែលបង្វិលដោយឡែកពីគ្នា។

តើអ្នកមានអារម្មណ៍ថាចាប់បានដែរឬទេ? យើងប្រើ k8s ឬ Swarm ដើម្បីចែកចាយបន្ទុក និងជៀសវាងការគាំងម៉ាស៊ីនមេគេហទំព័រ ប៉ុន្តែយើងមិនធ្វើបែបនេះសម្រាប់មូលដ្ឋានទិន្នន័យទេ។ ប៉ុន្តែប្រសិនបើមូលដ្ឋានទិន្នន័យគាំង នោះហេដ្ឋារចនាសម្ព័ន្ធចង្កោមទាំងមូលរបស់យើងគ្មានន័យអ្វីទេ តើទំព័របណ្ដាញទទេដែលត្រឡប់កំហុសក្នុងការចូលប្រើមូលដ្ឋានទិន្នន័យល្អ?

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

លើសពីនេះ គំរូមូលដ្ឋានទិន្នន័យដែលបានចែកចាយក្នុងចង្កោមអនុញ្ញាតឱ្យអ្នកយកមូលដ្ឋានទិន្នន័យនេះទៅកន្លែងដែលវាត្រូវការ។ ប្រសិនបើយើងកំពុងនិយាយអំពីសេវាកម្មសកលនោះ វាពិតជាមិនសមហេតុផលទេក្នុងការបង្វិលក្រុមបណ្តាញនៅកន្លែងណាមួយនៅក្នុងតំបន់ San Francisco ហើយក្នុងពេលតែមួយផ្ញើកញ្ចប់ព័ត៌មាននៅពេលចូលប្រើមូលដ្ឋានទិន្នន័យក្នុងតំបន់ Moscow និងត្រឡប់មកវិញ។

ដូចគ្នានេះផងដែរ, containerization នៃ database អនុញ្ញាតឱ្យអ្នកបង្កើតធាតុទាំងអស់នៃប្រព័ន្ធនៅកម្រិតដូចគ្នានៃ abstraction ។ ដែលធ្វើឱ្យវាអាចគ្រប់គ្រងប្រព័ន្ធនេះដោយផ្ទាល់ពីកូដ ដោយអ្នកអភិវឌ្ឍន៍ ដោយគ្មានការចូលរួមយ៉ាងសកម្មពីអ្នកគ្រប់គ្រង។ អ្នកអភិវឌ្ឍន៍បានគិតថាត្រូវការ DBMS ដាច់ដោយឡែកសម្រាប់គម្រោងរងថ្មី ងាយស្រួល! បានសរសេរឯកសារ yaml បង្ហោះវាទៅក្នុងចង្កោម ហើយអ្នករួចរាល់ហើយ។

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

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

ហើយឥឡូវនេះ វាដល់ពេលហើយដើម្បីផ្លាស់ប្តូរទៅជាគូប្រជែងនៃការប្រមូលផ្តុំមូលដ្ឋានទិន្នន័យ។

ផ្នែក​ដែល​ងងឹត

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

យល់ស្រប គម្រោងដែលពិតជាត្រូវការមូលដ្ឋាននៅក្នុងកុងតឺន័រ អាចត្រូវបានរាប់នៅលើម្រាមដៃនៃដៃម្ខាង ដោយមិនមែនជាប្រតិបត្តិករម៉ាស៊ីនកិនល្អបំផុតនោះទេ។ សម្រាប់ផ្នែកភាគច្រើន សូម្បីតែការប្រើប្រាស់ k8s ឬ Docker Swarm ខ្លួនវាក៏មិនអាចខ្វះបានដែរ - ជាញឹកញាប់ឧបករណ៍ទាំងនេះត្រូវបានប្រើប្រាស់ដោយសារតែការឃោសនាបំផ្លើសនៃបច្ចេកវិទ្យា និងអាកប្បកិរិយារបស់ "អ្នកមានអំណាច" នៅក្នុងមនុស្សភេទ ដើម្បីរុញអ្វីៗគ្រប់យ៉ាងទៅក្នុង ពពកនិងធុង។ ជាការប្រសើរណាស់, ដោយសារតែឥឡូវនេះវាជាម៉ូតហើយមនុស្សគ្រប់គ្នាធ្វើវាបាន។

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

ជាទូទៅ មានមតិមួយដែលថា docker/cube mafia កំពុងកំទេចអតិថិជនដោយឆោតល្ងង់ ដែលចេញប្រភពបញ្ហាហេដ្ឋារចនាសម្ព័ន្ធទាំងនេះ។ យ៉ាងណាមិញដើម្បីធ្វើការជាមួយចង្កោមយើងត្រូវការវិស្វករដែលមានសមត្ថភាពនេះហើយជាទូទៅយល់ពីស្ថាបត្យកម្មនៃដំណោះស្រាយដែលបានអនុវត្ត។ យើងបានពណ៌នាករណីរបស់យើងរួចហើយជាមួយនឹងការបោះពុម្ពផ្សាយរបស់សាធារណរដ្ឋ - នៅទីនោះយើងបានបណ្តុះបណ្តាលក្រុមរបស់អតិថិជនឱ្យធ្វើការនៅក្នុងការពិតនៃ Kubernetis ហើយអ្នកគ្រប់គ្នាពេញចិត្ត។ ហើយវាសមរម្យណាស់។ ជាញឹកញាប់ k8s "អ្នកអនុវត្ត" ចាប់ចំណាប់ខ្មាំងហេដ្ឋារចនាសម្ព័ន្ធរបស់អតិថិជន - ដោយសារតែឥឡូវនេះមានតែពួកគេទេដែលយល់ពីរបៀបដែលអ្វីៗដំណើរការនៅទីនោះ មិនមានអ្នកឯកទេសខាងអតិថិជនទេ។

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

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

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

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

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

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

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

ជំនួសឱ្យលទ្ធផល។

ប្រសិនបើអ្នកកំពុងរង់ចាំការសន្និដ្ឋានច្បាស់លាស់ "ដើម្បីធ្វើនិម្មិតមូលដ្ឋានទិន្នន័យឬអត់" នោះយើងនឹងខកចិត្តអ្នក៖ វានឹងមិននៅទីនេះទេ។ ដោយសារតែនៅពេលបង្កើតដំណោះស្រាយហេដ្ឋារចនាសម្ព័ន្ធណាមួយ មនុស្សម្នាក់ត្រូវតែត្រូវបានដឹកនាំមិនមែនដោយម៉ូដ និងវឌ្ឍនភាពនោះទេ ប៉ុន្តែជាដំបូងដោយសុភវិនិច្ឆ័យ។

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

ប្រភព: www.habr.com