HighLoad++, Mikhail Tyulenev (MongoDB)៖ ភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុ៖ ពីទ្រឹស្តីទៅការអនុវត្ត

សន្និសីទ HighLoad++ លើកក្រោយនឹងធ្វើឡើងនៅថ្ងៃទី 6 និង 7 ខែមេសា ឆ្នាំ 2020 នៅ St.
ព័ត៌មានលម្អិត និងសំបុត្រ តំណភ្ជាប់. HighLoad++ ស៊ីបេរីឆ្នាំ 2019 ។ សាល "Krasnoyarsk" ។ ថ្ងៃទី 25 ខែមិថុនាម៉ោង 12:00 ។ ទាំងនេះ និង បទបង្ហាញ.

វាកើតឡើងដែលតម្រូវការជាក់ស្តែងផ្ទុយនឹងទ្រឹស្តី ដែលទិដ្ឋភាពសំខាន់ៗសម្រាប់ផលិតផលពាណិជ្ជកម្មមិនត្រូវបានគេយកមកពិចារណា។ ការពិភាក្សានេះបង្ហាញពីដំណើរការសម្រាប់ការជ្រើសរើស និងរួមបញ្ចូលគ្នានូវវិធីសាស្រ្តផ្សេងៗដើម្បីបង្កើតសមាសធាតុភាពស៊ីសង្វាក់គ្នា Causal ដោយផ្អែកលើការស្រាវជ្រាវសិក្សាដោយផ្អែកលើតម្រូវការនៃផលិតផលពាណិជ្ជកម្ម។ អ្នកស្តាប់នឹងសិក្សាអំពីវិធីសាស្រ្តទ្រឹស្តីដែលមានស្រាប់ចំពោះនាឡិកាឡូជីខល ការតាមដានភាពអាស្រ័យ សុវត្ថិភាពប្រព័ន្ធ ការធ្វើសមកាលកម្មនាឡិកា និងមូលហេតុដែល MongoDB ដោះស្រាយលើដំណោះស្រាយជាក់លាក់។

Mikhail Tyulenev (តទៅនេះហៅថា MT)៖ - ខ្ញុំនឹងនិយាយអំពីភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុ - នេះគឺជាលក្ខណៈពិសេសដែលយើងបានធ្វើការនៅក្នុង MongoDB ។ ខ្ញុំ​ធ្វើ​ការ​ក្នុង​ក្រុម​ប្រព័ន្ធ​ចែកចាយ យើង​បាន​ធ្វើ​វា​ប្រហែល​ពីរ​ឆ្នាំ​មុន។

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

ខ្ញុំនឹងនិយាយអំពីរបៀបដែលយើង ក្នុងនាមជាអ្នកប្រើប្រាស់នៃការស្រាវជ្រាវសិក្សា រៀបចំអ្វីមួយពីវា ដែលយើងអាចបង្ហាញដល់អ្នកប្រើប្រាស់របស់យើងជាម្ហូបដែលត្រៀមរួចជាស្រេច ដែលងាយស្រួល និងមានសុវត្ថិភាពក្នុងការប្រើប្រាស់។

ភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុ។ ចូរយើងកំណត់និយមន័យ

ដើម្បីចាប់ផ្តើម ខ្ញុំចង់និយាយក្នុងន័យទូទៅថា ភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុគឺជាអ្វី។ មានតួអង្គពីរគឺ Leonard និង Penny (រឿងភាគទូរទស្សន៍ "The Big Bang Theory"):

ចូរនិយាយថា Penny នៅអឺរ៉ុប ហើយ Leonard ចង់ជប់លៀងឱ្យនាងភ្ញាក់ផ្អើល។ ហើយគាត់មិនអាចគិតអ្វីល្អជាងការបោះនាងចេញពីបញ្ជីមិត្តភ័ក្តិរបស់គាត់ឡើយ ដោយផ្ញើជូនមិត្តភ័ក្តិរបស់គាត់ទាំងអស់នូវការអាប់ដេតលើមតិព័ត៌មាន៖ "តោះធ្វើឱ្យ Penny សប្បាយចិត្ត!" (នាង​នៅ​អឺរ៉ុប ពេល​នាង​ដេក នាង​មើល​មិន​ឃើញ​អ្វី​ទាំង​អស់ ព្រោះ​នាង​មិន​នៅ)។ ទីបំផុត នាងបានលុបការបង្ហោះនេះ លុបវាចេញពី Feed និងស្ដារការចូលប្រើប្រាស់ឡើងវិញ ដើម្បីកុំឱ្យនាងកត់សម្គាល់អ្វីទាំងអស់ ហើយមិនមានរឿងអាស្រូវឡើយ។
នេះគឺល្អ និងល្អ ប៉ុន្តែសូមសន្មតថាប្រព័ន្ធត្រូវបានចែកចាយ ហើយអ្វីៗបានខុសបន្តិច។ ជាឧទាហរណ៍ វាអាចកើតឡើងដែលការរឹតបន្តឹងការចូលប្រើរបស់ Penny បានកើតឡើងបន្ទាប់ពីការបង្ហោះនេះបានបង្ហាញខ្លួន ប្រសិនបើព្រឹត្តិការណ៍មិនទាក់ទងគ្នាដោយមូលហេតុ និងឥទ្ធិពល។ តាមពិតនេះគឺជាឧទាហរណ៍នៃពេលដែលតម្រូវឱ្យមានភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុ ដើម្បីអនុវត្តមុខងារអាជីវកម្ម (ក្នុងករណីនេះ)។

តាមពិត ទាំងនេះគឺជាលក្ខណៈសម្បត្តិមិនសំខាន់នៃមូលដ្ឋានទិន្នន័យ មានមនុស្សតិចណាស់ដែលគាំទ្រពួកគេ។ ចូរបន្តទៅម៉ូដែល។

គំរូនៃភាពស៊ីសង្វាក់គ្នា។

អ្វី​ទៅ​ជា​គំរូ​ភាព​ស៊ីសង្វាក់​គ្នា​ក្នុង​មូលដ្ឋាន​ទិន្នន័យ? នេះគឺជាការធានាមួយចំនួនដែលប្រព័ន្ធចែកចាយផ្តល់ឱ្យអំពីទិន្នន័យដែលអតិថិជនអាចទទួលបាន និងក្នុងលំដាប់ណា។

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

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

ម៉ូដែលខ្លាំង

តាមពិតម៉ូដែលដំបូងបំផុតគឺខ្លាំង (ឬបន្ទាត់សមត្ថភាពកើនឡើងដូចដែលវាត្រូវបានគេហៅថាជាញឹកញាប់) ។ នេះគឺជាគំរូនៃភាពស៊ីសង្វាក់គ្នា ដែលធានាថារាល់ការផ្លាស់ប្តូរ ដែលត្រូវបានបញ្ជាក់ថាវាបានកើតឡើង អ្នកប្រើប្រាស់ទាំងអស់នៃប្រព័ន្ធនឹងអាចមើលឃើញ។

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

មានទ្រព្យសម្បត្តិដ៏រឹងមាំមួយទៀតដែលត្រូវបានគាំទ្រនៅក្នុង Spanner - ហៅថា External Consistency។ យើងនឹងនិយាយអំពីវាបន្តិចក្រោយមក។

មូលហេតុ

បន្ទាប់គឺ Causal ដែលជាអ្វីដែលខ្ញុំកំពុងនិយាយ។ មានកម្រិតរងមួយចំនួនទៀតរវាង Strong និង Causal ដែលខ្ញុំនឹងមិននិយាយអំពី ប៉ុន្តែពួកគេទាំងអស់ឈានដល់ Causal ។ នេះគឺជាគំរូដ៏សំខាន់ព្រោះវាខ្លាំងបំផុតនៃម៉ូដែលទាំងអស់ ភាពស៊ីសង្វាក់គ្នាខ្លាំងបំផុតនៅក្នុងវត្តមាននៃបណ្តាញឬភាគថាស។

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

ទីបំផុត

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

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

ខ្ញុំចង់ផ្តល់ឧទាហរណ៍ប្រៀបធៀបមួយចំនួន៖

តើព្រួញទាំងនេះមានន័យយ៉ាងណា?

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

ទ្រឹស្តីបទ CAP

នៅពេលដែលអ្នកឃើញពាក្យថាជាប់លាប់ ភាពអាចរកបាន - តើមានអ្វីមកក្នុងចិត្តរបស់អ្នក? ត្រឹមត្រូវហើយ - ទ្រឹស្តីបទ CAP! ឥឡូវនេះខ្ញុំចង់បំបាត់ទេវកថា... វាមិនមែនជាខ្ញុំទេ - វាគឺជា Martin Kleppmann ដែលបានសរសេរអត្ថបទដ៏អស្ចារ្យ សៀវភៅដ៏អស្ចារ្យមួយ។

ទ្រឹស្តីបទ CAP គឺជាគោលការណ៍មួយដែលត្រូវបានបង្កើតឡើងក្នុងទសវត្សរ៍ឆ្នាំ 2000 ដែលភាពជាប់លាប់ ភាពអាចរកបាន ភាគថាសៈ យកពីរណាមួយ ហើយអ្នកមិនអាចជ្រើសរើសបីបានទេ។ វាជាគោលការណ៍ជាក់លាក់មួយ។ វាត្រូវបានបង្ហាញថាជាទ្រឹស្តីបទមួយពីរបីឆ្នាំក្រោយមកដោយ Gilbert និង Lynch ។ បន្ទាប់មកវាបានចាប់ផ្តើមត្រូវបានប្រើជា mantra - ប្រព័ន្ធបានចាប់ផ្តើមត្រូវបានបែងចែកទៅជា CA, CP, AP និងដូច្នេះនៅលើ។

ទ្រឹស្តីបទនេះត្រូវបានបញ្ជាក់យ៉ាងពិតប្រាកដសម្រាប់ករណីខាងក្រោម... ជាដំបូង ភាពអាចរកបានត្រូវបានចាត់ទុកថាមិនមែនជាតម្លៃបន្តពីសូន្យដល់រាប់រយ (0 - ប្រព័ន្ធគឺ "ស្លាប់" 100 - ឆ្លើយតបយ៉ាងឆាប់រហ័ស យើងធ្លាប់ពិចារណាវាតាមវិធីនោះ) ប៉ុន្តែជាកម្មសិទ្ធិរបស់ algorithm ដែលធានាថាសម្រាប់ការប្រតិបត្តិរបស់វាទាំងអស់ វាត្រឡប់ទិន្នន័យ។

មិនមានពាក្យអំពីពេលវេលាឆ្លើយតបទាល់តែសោះ! មានក្បួនដោះស្រាយមួយដែលត្រឡប់ទិន្នន័យបន្ទាប់ពី 100 ឆ្នាំ - ជាក្បួនដោះស្រាយដ៏អស្ចារ្យដែលអាចប្រើបានដែលជាផ្នែកមួយនៃទ្រឹស្តីបទ CAP ។
ទីពីរ៖ ទ្រឹស្តីបទត្រូវបានបញ្ជាក់សម្រាប់ការផ្លាស់ប្តូរតម្លៃនៃគន្លឹះដូចគ្នា ទោះបីជាការពិតដែលថាការផ្លាស់ប្តូរទាំងនេះអាចផ្លាស់ប្តូរទំហំបានក៏ដោយ។ នេះមានន័យថាតាមការពិត ពួកវាមិនត្រូវបានគេប្រើប្រាស់ជាក់ស្តែងទេ ព្រោះម៉ូដែលមានភាពស៊ីសង្វាក់គ្នា ភាពស៊ីសង្វាក់គ្នាខ្លាំង (ប្រហែលជា)។

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

ភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុគឺជាគំរូខ្លាំងបំផុត។

អ្វី​ដែល​កំពុង​កើត​ឡើង​នៅ​ពេល​នេះ​គឺ​ថា​អ្នក​អាច​ទទួល​បាន​របស់​ទាំង​បី​: Consistency, Availability ដោយ​ប្រើ Partitions ។ ជាពិសេស ភាពស្ថិតស្ថេរ Causal គឺជាគំរូនៃភាពស៊ីសង្វាក់គ្នាខ្លាំងបំផុត ដែលនៅតែដំណើរការនៅក្នុងវត្តមាននៃភាគថាស (ការបំបែកនៅក្នុងបណ្តាញ)។ ហេតុ​នេះ​ហើយ​បាន​ជា​វា​មាន​ការ​ចាប់​អារម្មណ៍​យ៉ាង​ខ្លាំង ហើយ​នោះ​ជា​មូល​ហេតុ​ដែល​យើង​យក​វា​ឡើង។

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

ផ្ទះបាយខាងក្នុង MongoDB

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

MongoDB (តទៅនេះហៅថា "MongoDB") គឺជាប្រព័ន្ធចែកចាយដែលគាំទ្រការធ្វើមាត្រដ្ឋានផ្តេក ពោលគឺ sharding; ហើយនៅក្នុង shard នីមួយៗវាក៏គាំទ្រការលែងត្រូវការទិន្នន័យផងដែរ ពោលគឺការចម្លង។

ការចែករំលែកនៅក្នុង MongoDB (មិនមែនជាមូលដ្ឋានទិន្នន័យទំនាក់ទំនង) ធ្វើសមតុល្យដោយស្វ័យប្រវត្តិ ពោលគឺការប្រមូលឯកសារនីមួយៗ (ឬ "តារាង" នៅក្នុងលក្ខខណ្ឌនៃទិន្នន័យទំនាក់ទំនង) ត្រូវបានបែងចែកទៅជាបំណែក ហើយម៉ាស៊ីនមេផ្លាស់ទីពួកវាដោយស្វ័យប្រវត្តិរវាងបំណែក។

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

ចំណុចសំខាន់មួយទៀត៖ MongoDB គឺជាមេតែមួយ។ មានបឋមសិក្សាមួយ - វាអាចយកកំណត់ត្រាដែលគាំទ្រសោដែលវាមាន។ អ្នកមិនអាចសរសេរពហុមេបានទេ។

យើងបានបង្កើតការចេញផ្សាយ 4.2 - អ្វីដែលគួរឱ្យចាប់អារម្មណ៍ថ្មីបានបង្ហាញខ្លួននៅទីនោះ។ ជាពិសេស ពួកគេបានបញ្ចូល Lucene - search - នោះគឺ java ដែលអាចប្រតិបត្តិបានដោយផ្ទាល់ទៅក្នុង Mongo ហើយនៅទីនោះ វាអាចធ្វើការស្វែងរកតាមរយៈ Lucene ដូចគ្នាទៅនឹង Elastica ដែរ។

ហើយពួកគេបានផលិតផលិតផលថ្មី - តារាង វាក៏មាននៅលើ Atlas (ពពកផ្ទាល់ខ្លួនរបស់ Mongo) ផងដែរ។ ពួកគេមានថ្នាក់ឥតគិតថ្លៃ - អ្នកអាចលេងជាមួយវាបាន។ ខ្ញុំពិតជាចូលចិត្តគំនូសតាង - ការមើលឃើញទិន្នន័យ វិចារណញាណខ្លាំងណាស់។

ធាតុផ្សំ ភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុ

ខ្ញុំបានរាប់អត្ថបទប្រហែល 230 ដែលត្រូវបានបោះពុម្ពលើប្រធានបទនេះ - ពី Leslie Lampert ។ ឥឡូវនេះពីការចងចាំរបស់ខ្ញុំ ខ្ញុំនឹងប្រាប់អ្នកនូវផ្នែកខ្លះនៃសម្ភារៈទាំងនេះ។

វាទាំងអស់បានចាប់ផ្តើមជាមួយនឹងអត្ថបទមួយដោយ Leslie Lampert ដែលត្រូវបានសរសេរនៅក្នុងទសវត្សរ៍ឆ្នាំ 1970 ។ ដូចដែលអ្នកអាចឃើញការស្រាវជ្រាវមួយចំនួនលើប្រធានបទនេះនៅតែកំពុងបន្ត។ ឥឡូវនេះ ភាពស៊ីសង្វាក់គ្នានៃ Causal កំពុងមានចំណាប់អារម្មណ៍ទាក់ទងនឹងការអភិវឌ្ឍន៍ប្រព័ន្ធចែកចាយ។

ការរឹតត្បិត

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

• ទីមួយ "MongoDB" គឺជាមេតែមួយដូចដែលខ្ញុំបាននិយាយរួចមកហើយ (នេះធ្វើឱ្យកាន់តែងាយស្រួល)។
• យើងជឿថាប្រព័ន្ធនេះគួរតែគាំទ្រប្រហែល 10 ពាន់ shards ។ យើងមិនអាចធ្វើការសម្រេចចិត្តស្ថាបត្យកម្មណាមួយដែលនឹងកំណត់តម្លៃនេះយ៉ាងច្បាស់នោះទេ។
• យើងមានពពក ប៉ុន្តែយើងសន្មត់ថាមនុស្សម្នាក់នៅតែមានឱកាសនៅពេលដែលគាត់ទាញយកប្រព័ន្ធគោលពីរ ដំណើរការវានៅលើកុំព្យូទ័រយួរដៃរបស់គាត់ ហើយអ្វីៗដំណើរការបានល្អ។
• យើងសន្មតថាអ្វីមួយដែលការស្រាវជ្រាវកម្រសន្មត់ថា: អតិថិជនខាងក្រៅអាចធ្វើអ្វីដែលពួកគេចង់បាន។ MongoDB គឺជាប្រភពបើកចំហ។ ដូច្នោះហើយ អតិថិជនអាចឆ្លាត និងខឹងខ្លាំង ពួកគេអាចចង់បំបែកអ្វីៗទាំងអស់។ យើងប៉ាន់ស្មានថា Byzantine Feilors អាចមានប្រភពដើម។
• សម្រាប់អតិថិជនខាងក្រៅដែលនៅក្រៅបរិវេណ វាមានដែនកំណត់សំខាន់មួយ៖ ប្រសិនបើមុខងារនេះត្រូវបានបិទ នោះមិនគួរសង្កេតឃើញការថយចុះនៃដំណើរការនោះទេ។
• ចំណុចមួយទៀតជាទូទៅគឺការប្រឆាំងនឹងការសិក្សា៖ ភាពឆបគ្នានៃកំណែមុន និងអនាគត។ កម្មវិធីបញ្ជាចាស់ត្រូវតែគាំទ្រការអាប់ដេតថ្មី ហើយមូលដ្ឋានទិន្នន័យត្រូវតែគាំទ្រកម្មវិធីបញ្ជាចាស់។

ជាទូទៅទាំងអស់នេះដាក់កម្រិត។

សមាសធាតុផ្សំគ្នានៃបុព្វហេតុ

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

ការតាមដានភាពអាស្រ័យពេញលេញ

ហេតុអ្វីបានជាវាត្រូវការ? ដូច្នេះនៅពេលដែលទិន្នន័យត្រូវបានចម្លង កំណត់ត្រានីមួយៗ ការផ្លាស់ប្តូរទិន្នន័យនីមួយៗមានព័ត៌មានអំពីការផ្លាស់ប្តូរដែលវាអាស្រ័យលើ។ ការផ្លាស់ប្តូរដំបូង និងឆោតល្ងង់គឺនៅពេលដែលសារនីមួយៗដែលមានកំណត់ត្រាមានព័ត៌មានអំពីសារពីមុន៖

ក្នុងឧទាហរណ៍នេះ លេខក្នុងតង្កៀបអង្កាញ់ គឺជាលេខកំណត់ត្រា។ ពេលខ្លះកំណត់ត្រាទាំងនេះជាមួយនឹងតម្លៃត្រូវបានផ្ទេរសូម្បីតែទាំងស្រុងរបស់ពួកគេ ពេលខ្លះកំណែមួយចំនួនត្រូវបានផ្ទេរ។ ចំណុចសំខាន់គឺថាការផ្លាស់ប្តូរនីមួយៗមានព័ត៌មានអំពីរឿងមុន (ជាក់ស្តែងមានអ្វីៗទាំងអស់នេះនៅក្នុងខ្លួនវា)។

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

ការតាមដានភាពអាស្រ័យច្បាស់លាស់

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

នាងមើលឃើញថាកំណត់ត្រា 5 អាស្រ័យលើកំណត់ត្រា 1, 2, 3, 4 - អាស្រ័យហេតុនេះ នាងរង់ចាំមុនពេលអតិថិជនអាចចូលប្រើការផ្លាស់ប្តូរដែលបានធ្វើឡើងដោយការសម្រេចចិត្តចូលប្រើរបស់ Penny នៅពេលដែលការផ្លាស់ប្តូរពីមុនទាំងអស់បានឆ្លងកាត់មូលដ្ឋានទិន្នន័យរួចហើយ។

នេះ​មិន​ស័ក្តិសម​នឹង​យើង​ទេ ព្រោះ​នៅ​មាន​ព័ត៌មាន​ច្រើន​ពេក ហើយ​វា​នឹង​ធ្វើ​ឲ្យ​អ្វីៗ​ថយ​ចុះ។ មានវិធីសាស្រ្តមួយទៀត...

នាឡិកា Lamport

ពួកគេចាស់ណាស់។ Lamport Clock មានន័យថាភាពអាស្រ័យទាំងនេះត្រូវបានបត់ចូលទៅក្នុងមុខងារ scalar ដែលត្រូវបានគេហៅថា Lamport Clock ។

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

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

អ្នកឃើញពីរបៀបដែលពេលវេលារាប់នៅលើ Feed កើនឡើងដោយឡូជីខល៖

ដូច្នេះលក្ខណសម្បត្តិចម្បងនៃនាឡិកា Lamport និងភាពស៊ីសង្វាក់គ្នានៃមូលហេតុ (ពន្យល់តាមរយៈនាឡិកា Lamport) គឺនេះ៖ ប្រសិនបើយើងមានព្រឹត្តិការណ៍ A និង B ហើយព្រឹត្តិការណ៍ B អាស្រ័យលើព្រឹត្តិការណ៍ A* នោះវាកើតឡើងថា LogicalTime នៃព្រឹត្តិការណ៍ A គឺតិចជាង LogicalTime ពីព្រឹត្តិការណ៍ B.

* ពេលខ្លះពួកគេក៏និយាយថា A បានកើតឡើងមុន B ពោលគឺ A បានកើតឡើងមុន B - នេះគឺជាទំនាក់ទំនងជាក់លាក់ដែលបញ្ជាដោយផ្នែកនៃព្រឹត្តិការណ៍ទាំងមូលដែលបានកើតឡើងជាទូទៅ។

ភាពផ្ទុយគ្នាគឺមិនត្រឹមត្រូវទេ។ នេះពិតជាគុណវិបត្តិចម្បងមួយនៃ Lamport Clock - លំដាប់ដោយផ្នែក។ មានគោលគំនិតអំពីព្រឹត្តិការណ៍ដំណាលគ្នា ពោលគឺព្រឹត្តិការណ៍ដែលទាំង (A កើតឡើងមុន B) ឬ (A កើតឡើងមុន B) ។ ឧទាហរណ៍​មួយ​នឹង​ជា​ការ​បន្ថែម​ស្រប​គ្នា​របស់​លោក Leonard លើ​អ្នក​ផ្សេង​ទៀត​ជា​មិត្តភ័ក្ដិ (មិនមែន​សូម្បី​តែ Leonard ប៉ុន្តែ Sheldon ជា​ឧទាហរណ៍)។
នេះគឺជាទ្រព្យសម្បត្តិដែលត្រូវបានប្រើជាញឹកញាប់នៅពេលធ្វើការជាមួយនាឡិកា Lamport: ពួកគេមើលទៅជាពិសេសលើមុខងារហើយពីនេះពួកគេសន្និដ្ឋានថាប្រហែលជាព្រឹត្តិការណ៍ទាំងនេះអាស្រ័យ។ ដោយសារតែវិធីមួយគឺជាការពិត៖ ប្រសិនបើ LogicalTime A តិចជាង LogicalTime B នោះ B មិនអាចកើតឡើងមុន A បានទេ។ ហើយប្រសិនបើច្រើនទៀត នោះប្រហែលជា។

នាឡិកាវ៉ិចទ័រ

ការអភិវឌ្ឍន៍ឡូជីខលនៃនាឡិកា Lamport គឺនាឡិកាវ៉ិចទ័រ។ ពួកវាខុសគ្នាត្រង់ថាថ្នាំងនីមួយៗដែលនៅទីនេះមាននាឡិកាដាច់ដោយឡែករបស់វា ហើយពួកវាត្រូវបានបញ្ជូនជាវ៉ិចទ័រ។
ក្នុងករណីនេះ អ្នកឃើញថាសន្ទស្សន៍សូន្យនៃវ៉ិចទ័រគឺទទួលខុសត្រូវចំពោះ Feed ហើយសន្ទស្សន៍ដំបូងនៃវ៉ិចទ័រគឺសម្រាប់មិត្ត (នីមួយៗនៃថ្នាំងទាំងនេះ)។ ហើយឥឡូវនេះពួកគេនឹងកើនឡើង៖ សន្ទស្សន៍សូន្យនៃ "មតិព័ត៌មាន" កើនឡើងនៅពេលសរសេរ - 1, 2, 3:

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

ប្រសិនបើយើងមាន 10 shards យើងមិនអាចផ្ទេរសមាសភាគ 10 បានទេ ទោះបីជាយើងបង្ហាប់វា ឬមកជាមួយអ្វីផ្សេងទៀតក៏ដោយ - payload នឹងនៅតែតូចជាងបរិមាណនៃវ៉ិចទ័រទាំងមូលនេះច្រើនដង។ ហេតុដូច្នេះហើយ ការក្រហាយចិត្ត និងធ្មេញរបស់យើង យើងបោះបង់វិធីសាស្រ្តនេះ ហើយបន្តទៅវិធីមួយទៀត។

Spanner TrueTime ។ នាឡិកាអាតូមិច

ខ្ញុំបាននិយាយថានឹងមានរឿងមួយអំពី Spanner ។ នេះ​គឺ​ជា​រឿង​ដ៏​ត្រជាក់​មួយ​ត្រង់​នៃ​សតវត្សរ៍​ទី XNUMX: នាឡិកា​អាតូមិក ការ​ធ្វើ​សមកាលកម្ម GPS ។

តើ​មាន​គំនិត​អ្វី? “Spanner” គឺជាប្រព័ន្ធរបស់ Google ដែលថ្មីៗនេះក៏មានសម្រាប់មនុស្សផងដែរ (ពួកគេបានបន្ថែម SQL ទៅវា)។ ប្រតិបត្តិការនីមួយៗនៅទីនោះមានត្រាពេលវេលាមួយចំនួន។ ដោយសារពេលវេលាត្រូវបានធ្វើសមកាលកម្ម* ព្រឹត្តិការណ៍នីមួយៗអាចត្រូវបានកំណត់ពេលវេលាជាក់លាក់មួយ - នាឡិកាអាតូមិកមានពេលវេលារង់ចាំ បន្ទាប់មកពេលវេលាផ្សេងគ្នាត្រូវបានធានាថានឹង "កើតឡើង"។

ដូច្នេះ ដោយគ្រាន់តែសរសេរទៅកាន់មូលដ្ឋានទិន្នន័យ ហើយរង់ចាំរយៈពេលខ្លះ ភាពអាចដំណើរការបាននៃព្រឹត្តិការណ៍ត្រូវបានធានាដោយស្វ័យប្រវត្តិ។ ពួកគេមានគំរូ Consistency ខ្លាំងបំផុតដែលអាចស្រមៃបានជាគោលការណ៍ - វាគឺជា External Consistency ។

* នេះគឺជាបញ្ហាចម្បងជាមួយនាឡិកា Lampart - ពួកគេមិនដែលធ្វើសមកាលកម្មនៅលើប្រព័ន្ធចែកចាយទេ។ ពួកគេអាចបែងចែកបាន សូម្បីតែ NTP ក៏ដោយ ក៏ពួកគេនៅតែមិនដំណើរការល្អដែរ។ "Spanner" មាននាឡិកាអាតូមិច និងការធ្វើសមកាលកម្ម វាហាក់ដូចជាមីក្រូវិនាទី។

ហេតុអ្វីបានជាយើងមិនជ្រើសរើស? យើងមិនសន្មត់ថាអ្នកប្រើប្រាស់របស់យើងមាននាឡិកាអាតូមិកដែលភ្ជាប់មកជាមួយនោះទេ។ នៅពេលដែលពួកវាលេចឡើង ដែលត្រូវបានបង្កើតឡើងនៅក្នុងកុំព្យូទ័រយួរដៃនីមួយៗ នឹងមានប្រភេទនៃការធ្វើសមកាលកម្ម GPS ដ៏អស្ចារ្យមួយចំនួន - បន្ទាប់មកបាទ... ប៉ុន្តែសម្រាប់ពេលនេះល្អបំផុតដែលអាចធ្វើទៅបានគឺ Amazon, Base Stations - សម្រាប់អ្នកគាំទ្រ... ដូច្នេះយើងបានប្រើនាឡិកាផ្សេងទៀត .

នាឡិកាកូនកាត់

នេះពិតជាអ្វីដែលធីកនៅក្នុង MongoDB នៅពេលធានានូវភាពស៊ីសង្វាក់គ្នានៃមូលហេតុ។ តើពួកវាជាកូនកាត់យ៉ាងដូចម្តេច? កូនកាត់គឺជាតម្លៃមាត្រដ្ឋាន ប៉ុន្តែវាមានធាតុផ្សំពីរ៖

• ទីមួយគឺសម័យយូនីក (ប៉ុន្មានវិនាទីបានកន្លងផុតទៅចាប់តាំងពី "ការចាប់ផ្តើមនៃពិភពកុំព្យូទ័រ") ។
• ទីពីរគឺជាការបង្កើនមួយចំនួន ក៏ជា 32-bit unsigned int ផងដែរ។

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

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

ខ្ញុំ​នឹង​ប្រាប់​អ្នក​ពី​ហេតុផល​សំខាន់​បំផុត​សម្រាប់​តែ​អ្នក (សូម​កុំ​ប្រាប់​នរណា​ម្នាក់​)! យើងបានធ្វើដូច្នេះព្រោះនេះជាអ្វីដែលរៀបចំ និងធ្វើលិបិក្រមទិន្នន័យមើលទៅដូចនៅក្នុង MongoDB OpLog។ OpLog គឺជារចនាសម្ព័ន្ធទិន្នន័យដែលមានការផ្លាស់ប្តូរទាំងអស់នៅក្នុងមូលដ្ឋានទិន្នន័យ៖ ដំបូងពួកគេចូលទៅកាន់ OpLog ហើយបន្ទាប់មកពួកវាត្រូវបានអនុវត្តទៅការផ្ទុកដោយខ្លួនវាក្នុងករណីដែលវាជាកាលបរិច្ឆេទចម្លង ឬ shard ។

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

ការធ្វើសមកាលកម្មនាឡិកា

មានវិធីសាស្រ្តធ្វើសមកាលកម្មជាច្រើនដែលត្រូវបានពិពណ៌នានៅក្នុងអក្សរសិល្ប៍វិទ្យាសាស្ត្រ។ ខ្ញុំកំពុងនិយាយអំពីការធ្វើសមកាលកម្មនៅពេលដែលយើងមាន shards ពីរផ្សេងគ្នា។ ប្រសិនបើមានសំណុំចម្លងមួយ នោះមិនចាំបាច់ធ្វើសមកាលកម្មណាមួយទេ៖ នេះគឺជា "មេតែមួយ" ។ យើងមាន OpLog ដែលក្នុងនោះការផ្លាស់ប្តូរទាំងអស់ធ្លាក់ចុះ - ក្នុងករណីនេះអ្វីគ្រប់យ៉ាងត្រូវបានតម្រៀបតាមលំដាប់លំដោយនៅក្នុង "Oplog" ខ្លួនវារួចហើយ។ ប៉ុន្តែប្រសិនបើយើងមានពីរផ្សេងគ្នា ការធ្វើសមកាលកម្មពេលវេលាមានសារៈសំខាន់នៅទីនេះ។ នេះជាកន្លែងដែលនាឡិកាវ៉ិចទ័របានជួយកាន់តែច្រើន! ប៉ុន្តែយើងមិនមានពួកគេទេ។

ទីពីរគឺសមរម្យ - នេះគឺជា "ចង្វាក់បេះដូង" ។ វាអាចទៅរួចក្នុងការផ្លាស់ប្តូរសញ្ញាមួយចំនួនដែលកើតឡើងរាល់ឯកតានៃពេលវេលា។ ប៉ុន្តែចង្វាក់បេះដូងយឺតពេក យើងមិនអាចផ្តល់ភាពយឺតយ៉ាវដល់អតិថិជនរបស់យើងបានទេ។

ជាការពិតណាស់ ពេលវេលាពិតជាអស្ចារ្យណាស់។ ប៉ុន្តែ ជាថ្មីម្តងទៀត នេះប្រហែលជាអនាគត... ទោះបីជាវាអាចត្រូវបានធ្វើរួចនៅក្នុង Atlas ក៏ដោយ វាមានឧបករណ៍ធ្វើសមកាលកម្មពេលវេលាលឿន "Amazon" រួចហើយ។ ប៉ុន្តែវានឹងមិនមានសម្រាប់មនុស្សគ្រប់គ្នាទេ។

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

តើវាដំណើរការជាមួយគ្នាយ៉ាងដូចម្តេច?

នៅទីនេះខ្ញុំកំពុងមើលឈុតចម្លងមួយដើម្បីធ្វើឱ្យវាកាន់តែងាយស្រួលបន្តិច។ មានបឋមសិក្សា និងអនុវិទ្យាល័យ។ អនុវិទ្យាល័យ​ធ្វើ​ការ​ចម្លង ហើយ​មិន​តែងតែ​ត្រូវ​បាន​ធ្វើ​សមកាលកម្ម​ទាំងស្រុង​ជាមួយ​នឹង​បឋម​ទេ។

ការបញ្ចូលកើតឡើងនៅក្នុង "បឋម" ជាមួយនឹងតម្លៃពេលវេលាជាក់លាក់។ ការបញ្ចូលនេះបង្កើនចំនួនខាងក្នុងដោយ 11 ប្រសិនបើនេះជាអតិបរមា។ ឬវានឹងពិនិត្យមើលតម្លៃនាឡិកា និងធ្វើសមកាលកម្មទៅនឹងនាឡិកា ប្រសិនបើតម្លៃនាឡិកាធំជាង។ នេះអនុញ្ញាតឱ្យអ្នករៀបចំតាមពេលវេលា។

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

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

តម្លៃដែលត្រូវបានសរសេររួចហើយទៅ "Oplog" ត្រូវបានត្រឡប់ - យើងដឹងថា "Oplog" មានតម្លៃនេះរួចហើយ ហើយពេលវេលារបស់វាគឺ 12 ។ ឥឡូវនេះ ចូរនិយាយថា ការអានចាប់ផ្តើមពីថ្នាំងផ្សេងទៀត (បន្ទាប់បន្សំ) ហើយវាបញ្ជូនបន្ទាប់ពី ClusterTime នៅក្នុង សារ។ គាត់​និយាយ​ថា​៖ ​«​ខ្ញុំ​ត្រូវ​ការ​អ្វី​គ្រប់​យ៉ាង​ដែល​បាន​កើត​ឡើង​យ៉ាង​ហោច​ណាស់​បន្ទាប់​ពី​ម៉ោង ១២ ឬ​ក្នុង​អំឡុង​ពេល​ដប់ពីរ​នាក់​» (​មើល​រូបភាព​ខាងលើ​) ។

នេះ​ជា​អ្វី​ដែល​ត្រូវ​បាន​គេ​ហៅថា Causal a ស្រប (CAT)។ មានគំនិតបែបនេះនៅក្នុងទ្រឹស្ដីដែលថានេះគឺជាចំណែកនៃពេលវេលាដែលស្របគ្នានៅក្នុងខ្លួនវាផ្ទាល់។ ក្នុងករណីនេះយើងអាចនិយាយបានថានេះគឺជាស្ថានភាពនៃប្រព័ន្ធដែលត្រូវបានគេសង្កេតឃើញនៅម៉ោង 12 ។

ឥឡូវនេះមិនមានអ្វីនៅទីនេះនៅឡើយទេ ព្រោះប្រភេទនេះក្លែងធ្វើស្ថានភាពនៅពេលដែលអ្នកត្រូវការ Secondary ដើម្បីចម្លងទិន្នន័យពី Primary ។ គាត់រង់ចាំ ... ហើយឥឡូវនេះទិន្នន័យបានមកដល់ - គាត់ត្រឡប់តម្លៃទាំងនេះត្រឡប់មកវិញ។

នោះហើយជារបៀបដែលវាដំណើរការទាំងអស់។ ស្ទើរតែ។

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

ហេតុអ្វីបានជា "ដកមួយ"? ដោយសារតែនាឡិកាខាងក្នុងនឹងត្រូវបានជំនួសដោយតម្លៃនេះ (ជាក់ស្តែងនេះគឺជាធំបំផុតដែលអាចធ្វើទៅបាននិងធំជាងពេលបច្ចុប្បន្ន) បន្ទាប់មកធាតុនឹងកើតឡើងនៅក្នុង "Oplog" ហើយនាឡិកានឹងត្រូវបានបង្កើនដោយឯកតាផ្សេងទៀត - ហើយវានឹងមានរួចហើយ។ ជា​តម្លៃ​អតិបរមា (មាន​ឯកតា​ទាំងអស់ គ្មាន​កន្លែង​ណា​ត្រូវ​ទៅ​ទេ) unsaint ints)។

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

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

វិធីរបស់យើងគឺដើម្បីចុះហត្ថលេខាលើ clusterTime

នេះជារបៀបដែលវាត្រូវបានបញ្ជូននៅក្នុងសារ (មុនអត្ថបទពណ៌ខៀវ) ។ ប៉ុន្តែយើងក៏ចាប់ផ្តើមបង្កើតហត្ថលេខា (អត្ថបទពណ៌ខៀវ)៖

ហត្ថលេខា​ត្រូវ​បាន​បង្កើត​ឡើង​ដោយ​សោ​ដែល​ត្រូវ​បាន​រក្សា​ទុក​នៅ​ក្នុង​មូលដ្ឋាន​ទិន្នន័យ, នៅ​ក្នុង​បរិវេណ​សុវត្ថិភាព; ខ្លួនវាត្រូវបានបង្កើត និងធ្វើបច្ចុប្បន្នភាព (អ្នកប្រើប្រាស់មិនឃើញអ្វីអំពីវាទេ)។ សញ្ញាត្រូវបានបង្កើត ហើយសារនីមួយៗត្រូវបានចុះហត្ថលេខានៅពេលបង្កើត និងបញ្ជាក់នៅពេលទទួលបាន។
សំណួរប្រហែលជាកើតឡើងនៅក្នុងចិត្តរបស់មនុស្ស៖ "តើវាថយចុះប៉ុន្មាន?" ខ្ញុំបានប្រាប់អ្នកថា វាគួរតែដំណើរការយ៉ាងឆាប់រហ័ស ជាពិសេសក្នុងករណីដែលគ្មានមុខងារនេះ។

តើ​ការ​ប្រើ​ភាព​ស៊ីសង្វាក់​គ្នា​នៃ Causal ក្នុង​ករណី​នេះ​មានន័យ​ដូចម្តេច? នេះគឺដើម្បីបង្ហាញប៉ារ៉ាម៉ែត្រ afterClusterTime ។ បើគ្មាននេះទេ វានឹងហុចតម្លៃយ៉ាងសាមញ្ញ។ ការនិយាយដើម ចាប់ផ្តើមពីកំណែ 3.6 តែងតែដំណើរការ។

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

ធ្វើវាឱ្យលឿន!

វាជារឿងសាមញ្ញមួយ ប៉ុន្តែល្បិចគឺគួរឱ្យចាប់អារម្មណ៍ - ខ្ញុំនឹងចែករំលែកវា ប្រហែលជាមាននរណាម្នាក់ចាប់អារម្មណ៍។
យើងមាន hash ដែលរក្សាទុកទិន្នន័យដែលបានចុះហត្ថលេខា។ ទិន្នន័យទាំងអស់ឆ្លងកាត់ឃ្លាំងសម្ងាត់។ ឃ្លាំងសម្ងាត់មិនចុះហត្ថលេខាលើពេលវេលាជាក់លាក់នោះទេប៉ុន្តែជួរ។ នៅពេលដែលតម្លៃខ្លះមកដល់ យើងបង្កើត Range បិទបាំង 16 ប៊ីតចុងក្រោយ ហើយយើងចុះហត្ថលេខាលើតម្លៃនេះ៖

ដោយទទួលបានហត្ថលេខាបែបនេះយើងបង្កើនល្បឿនប្រព័ន្ធ (ទាក់ទង) 65 ពាន់ដង។ វាដំណើរការល្អណាស់៖ នៅពេលដែលយើងធ្វើការពិសោធន៍ ពេលវេលាពិតជាបានថយចុះ 10 ពាន់ដង នៅពេលដែលយើងមានការអាប់ដេតជាបន្តបន្ទាប់។ វាច្បាស់ណាស់ថានៅពេលដែលពួកគេមានហាងឆេង វាមិនដំណើរការទេ។ ប៉ុន្តែនៅក្នុងករណីជាក់ស្តែងភាគច្រើនវាដំណើរការ។ ការរួមបញ្ចូលគ្នានៃហត្ថលេខា Range រួមជាមួយនឹងហត្ថលេខាបានដោះស្រាយបញ្ហាសុវត្ថិភាព។

តើយើងបានរៀនអ្វីខ្លះ?

មេរៀនដែលយើងរៀនពីនេះ៖

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

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

• នៅក្នុងការផលិតតម្រូវការគឺខុសគ្នាទាំងស្រុង។ ខ្ញុំប្រាកដថា អ្នកទាំងអស់គ្នាមិនប្រឈមមុខនឹងមូលដ្ឋានទិន្នន័យ "ស្វ៊ែរ" នៅក្នុងកន្លែងទំនេរអរូបីនោះទេ ប៉ុន្តែជាមួយនឹងរឿងធម្មតាធម្មតា ដែលមានបញ្ហាជាមួយនឹងភាពអាចរកបាន ភាពយឺតយ៉ាវ និងការអត់ធ្មត់ចំពោះកំហុស។
• រឿងចុងក្រោយគឺថា យើងត្រូវមើលគំនិតផ្សេងៗគ្នា ហើយបញ្ចូលអត្ថបទខុសគ្នាទាំងស្រុងមួយចំនួនទៅក្នុងវិធីសាស្រ្តតែមួយជាមួយគ្នា។ ជាឧទាហរណ៍ គំនិតអំពីការចុះហត្ថលេខា ជាទូទៅបានមកពីអត្ថបទដែលចាត់ទុកពិធីការ Paxos ដែលសម្រាប់អ្នកដែលមិនមែនជា Byzantine Failors គឺនៅក្នុងពិធីការអនុញ្ញាតសម្រាប់ Byzantine - នៅខាងក្រៅពិធីការអនុញ្ញាត... ជាទូទៅ នេះពិតជាអ្វីដែលយើង បានបញ្ចប់ដោយធ្វើ។

  គ្មានអ្វីថ្មីទេនៅទីនេះ! ប៉ុន្តែនៅពេលយើងលាយវាចូលគ្នា... វាដូចគ្នានឹងការនិយាយថារូបមន្តសាឡាត់ Olivier គឺមិនសមហេតុសមផលទេព្រោះស៊ុត mayonnaise និងត្រសក់ត្រូវបានបង្កើតរួចហើយ ... វានិយាយអំពីរឿងដូចគ្នា។

ខ្ញុំនឹងបញ្ចប់រឿងនេះ។ សូមអរគុណ!

សំណួរ

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

MT៖ - សំណួរដ៏អស្ចារ្យ! ខ្ញុំ​គ្រាន់​តែ​ចង់​និយាយ​អំពី shards ។ ប្រសិនបើខ្ញុំយល់សំណួរបានត្រឹមត្រូវ យើងមានស្ថានភាពដូចតទៅ៖ មាន shard 1 និង shard 2 ការអានកើតឡើងពី shard ទាំងពីរនេះ - ពួកគេមានភាពមិនស្របគ្នាពួកគេមិនទាក់ទងគ្នាទេព្រោះពេលវេលាដែលពួកគេដឹងគឺខុសគ្នា។ ជាពិសេសពេលវេលាដែលពួកគេមាននៅក្នុង oplogs ។
ចូរនិយាយថា shard 1 បានបង្កើតកំណត់ត្រាមួយលាន, shard 2 មិនបានធ្វើអ្វីទាល់តែសោះហើយសំណើបានមកដល់ពីរ shards ។ ហើយទីមួយមាន afterClusterTime ជាងមួយលាន។ ក្នុង​ស្ថានភាព​បែប​នេះ ដូច​ខ្ញុំ​បាន​ពន្យល់​ហើយ shard 2 នឹង​មិន​ឆ្លើយ​តប​ទាល់​តែ​សោះ។

ក្នុង៖ – ខ្ញុំចង់ដឹងពីរបៀបដែលពួកគេធ្វើសមកាលកម្ម និងជ្រើសរើសពេលវេលាឡូជីខលមួយ?

MT៖ - ងាយស្រួលណាស់ក្នុងការធ្វើសមកាលកម្ម។ Shard នៅពេលដែល AfterClusterTime មករកគាត់ ហើយគាត់មិនស្វែងរកពេលវេលានៅក្នុង "Oplog" ទេនោះ ចាប់ផ្តើមមិនមានការយល់ព្រម។ នោះគឺគាត់លើកដៃរបស់គាត់ទៅតម្លៃនេះ។ នេះមានន័យថាវាមិនមានព្រឹត្តិការណ៍ដែលត្រូវនឹងសំណើនេះទេ។ គាត់​បង្កើត​ព្រឹត្តិការណ៍​នេះ​ដោយ​សិប្បនិម្មិត ហើយ​ដូច្នេះ​បាន​ក្លាយ​ទៅ​ជា Causal Consistent។

ក្នុង៖ – ចុះ​បើ​មាន​ព្រឹត្តិការណ៍​ផ្សេង​ទៀត​មក​រក​គាត់​ដែល​បាត់​កន្លែង​ណា​មួយ​ក្នុង​បណ្តាញ?

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

ក្នុង៖ - ខ្ញុំមានសំណួរជាច្រើនទាក់ទងនឹងជួរ។ ភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុសន្មត់ថាមានជួរជាក់លាក់នៃសកម្មភាពដែលត្រូវអនុវត្ត។ តើមានអ្វីកើតឡើងប្រសិនបើកញ្ចប់ណាមួយរបស់យើងបាត់? មកដល់ថ្ងៃទី ១០ ទី ១១... ថ្ងៃទី ១២ បានបាត់ហើយ គ្រប់គ្នាកំពុងរង់ចាំវាក្លាយជាការពិត។ រំពេច​នោះ​ឡាន​របស់​យើង​ក៏​ស្លាប់ យើង​មិន​អាច​ធ្វើ​អ្វី​បាន​ទេ។ តើមានប្រវែងអតិបរមានៃជួរដែលប្រមូលផ្តុំមុនពេលត្រូវបានប្រតិបត្តិដែរឬទេ? តើ​ការ​បរាជ័យ​ធ្ងន់ធ្ងរ​អ្វី​កើត​ឡើង​នៅ​ពេល​រដ្ឋ​មួយ​ត្រូវ​បាន​បាត់បង់? ជាងនេះទៅទៀត បើយើងសរសេរថា មានសភាពពីមុនខ្លះ តើយើងគួរចាប់ផ្តើមដោយរបៀបណា? ប៉ុន្តែ​គេ​មិន​បាន​រុញ​គាត់​ចេញ​ទេ!

MT៖ - សំណួរដ៏អស្ចារ្យផងដែរ! ពួក​យើង​កំពុង​ធ្វើអ្វី​ហ្នឹង? MongoDB មានគោលគំនិតនៃកូរ៉ុមសរសេរ កូរ៉ុមអាន។ តើក្នុងករណីណាខ្លះអាចបាត់បង់សារ? នៅពេលដែលការសរសេរមិនមែនជាកូរ៉ុម ឬនៅពេលដែលការអានមិនមែនជាកូរ៉ុម (សំរាមប្រភេទខ្លះក៏អាចជាប់បានដែរ)។
ទាក់ទងនឹងភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុ ការធ្វើតេស្តពិសោធន៍ដ៏ធំមួយត្រូវបានអនុវត្ត ដែលលទ្ធផលគឺក្នុងករណីដែលការសរសេរ និងអានមិនមែនជាកូរ៉ុម ការរំលោភលើភាពស៊ីសង្វាក់គ្នានៃបុព្វហេតុកើតឡើង។ ពិត​ជា​អ្នក​និយាយ​មែន!

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

ក្នុង៖ - នៅពេលដែលយើងបង្កើត instance ដែលធ្វើការ sharding សម្រាប់ពួកយើង (មិនមែនជាម្ចាស់ ប៉ុន្តែជា slave រៀងៗខ្លួន) វាពឹងផ្អែកលើពេលវេលា Unix នៃម៉ាស៊ីនរបស់វាផ្ទាល់ ឬនៅលើពេលវេលានៃ "master" ។ តើវាធ្វើសមកាលកម្មជាលើកដំបូង ឬតាមកាលកំណត់?

MT៖ - ខ្ញុំនឹងបញ្ជាក់ឥឡូវនេះ។ Shard (ឧទាហរណ៍ភាគថាសផ្ដេក) - តែងតែមានបឋមនៅទីនោះ។ ហើយ shard អាចមាន "មេ" ហើយអាចមានការចម្លង។ ប៉ុន្តែ shard តែងតែគាំទ្រការថត ព្រោះវាត្រូវតែគាំទ្រ domain មួយចំនួន (shard មាន Primary)។

ក្នុង៖ - ដូច្នេះអ្វីគ្រប់យ៉ាងអាស្រ័យលើ "មេ" សុទ្ធសាធ? តើពេលវេលាមេតែងតែប្រើទេ?

MT៖ - បាទ។ អ្នក​អាច​និយាយ​ជា​ន័យ​ធៀប៖ នាឡិកា​ត្រូវ​បាន​គូស​នៅ​ពេល​ដែល​ការ​ចូល​ទៅ​ក្នុង "មេ" ចូល​ទៅ​ក្នុង "Oplog" កើតឡើង។

ក្នុង៖ - យើងមានអតិថិជនដែលភ្ជាប់ ហើយមិនចាំបាច់ដឹងអ្វីអំពីពេលវេលាទេ?

MT៖ - អ្នកមិនចាំបាច់ដឹងអ្វីទាំងអស់! ប្រសិនបើយើងនិយាយអំពីរបៀបដែលវាដំណើរការលើម៉ាស៊ីនភ្ញៀវ៖ នៅពេលដែលអតិថិជនចង់ប្រើភាពស៊ីសង្វាក់គ្នា Causal គាត់ត្រូវបើកវគ្គមួយ។ ឥឡូវនេះអ្វីគ្រប់យ៉ាងគឺនៅទីនោះ៖ ប្រតិបត្តិការនៅក្នុងវគ្គ និងទាញយកសិទ្ធិ... វគ្គមួយគឺជាលំដាប់នៃព្រឹត្តិការណ៍ឡូជីខលដែលកើតឡើងជាមួយអតិថិជន។

ប្រសិនបើគាត់បើកវគ្គនេះ ហើយនិយាយនៅទីនោះថាគាត់ចង់បានភាពស៊ីសង្វាក់គ្នានៃ Causal (ប្រសិនបើវគ្គនេះគាំទ្រភាពស៊ីសង្វាក់គ្នានៃ Causal តាមលំនាំដើម) អ្វីគ្រប់យ៉ាងដំណើរការដោយស្វ័យប្រវត្តិ។ អ្នកបើកបរចងចាំពេលវេលានេះហើយបង្កើនវានៅពេលដែលវាទទួលបានសារថ្មី។ វា​ចងចាំ​ថា​តើ​ការឆ្លើយតប​មុន​មួយ​ណា​បាន​ត្រឡប់​មក​ពី​ម៉ាស៊ីន​មេ​ដែល​បាន​ត្រឡប់​ទិន្នន័យ។ សំណើបន្ទាប់នឹងមាន afterCluster ("ពេលវេលាធំជាងនេះ")។

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

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

MT៖ - សំណួរ​ល្អ! CRDT មានន័យសម្រាប់ការសរសេរជម្លោះ៖ នៅក្នុង MongoDB មេតែមួយ។

ក្នុង៖ - ខ្ញុំ​មាន​សំណួរ​មួយ​ពី devops ។ នៅក្នុងពិភពពិតមានស្ថានភាព Jesuitical បែបនេះនៅពេលដែលការបរាជ័យ Byzantine កើតឡើង ហើយមនុស្សអាក្រក់នៅក្នុងបរិវេណដែលត្រូវបានការពារចាប់ផ្តើមចូលទៅក្នុងពិធីការផ្ញើកញ្ចប់សិប្បកម្មតាមរបៀបពិសេស?

MT៖ - មនុស្សអាក្រក់នៅខាងក្នុងបរិវេណគឺដូចជាសេះ Trojan! មនុស្សអាក្រក់នៅខាងក្នុងបរិវេណអាចធ្វើអំពើអាក្រក់ជាច្រើន។

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

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

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

ក្នុង៖ - នៅក្នុងបរិវេណដែលត្រូវបានការពារ មាននរណាម្នាក់បានព្យាយាមបង្កើតពិធីការដែលមិននឹកស្មានដល់សម្រាប់ម៉ាស៊ីនមេ ដើម្បីបំផ្លាញម៉ាស៊ីនមេទាំងស្រុង ហើយប្រសិនបើអ្នកមានសំណាង ចង្កោមទាំងមូល... តើវាធ្លាប់ទទួលបាន "ល្អ" ដែរឬទេ?

MT៖ "ខ្ញុំមិនដែលឮរឿងបែបនេះទេ" ការពិតដែលថាអ្នកអាចគាំងម៉ាស៊ីនមេតាមរបៀបនេះមិនមែនជាអាថ៌កំបាំងទេ។ បរាជ័យនៅខាងក្នុង មកពីពិធីការ ជាអ្នកប្រើប្រាស់ដែលមានការអនុញ្ញាត ដែលអាចសរសេរអ្វីមួយដូចនេះនៅក្នុងសារ... តាមពិតទៅ វាមិនអាចទៅរួចទេ ព្រោះវានៅតែត្រូវបានផ្ទៀងផ្ទាត់។ វាគឺអាចធ្វើទៅបានដើម្បីបិទការផ្ទៀងផ្ទាត់នេះសម្រាប់អ្នកប្រើប្រាស់ដែលមិនចង់បានវា - បន្ទាប់មកនោះគឺជាបញ្ហារបស់ពួកគេ; ពួកគេបានបំផ្លាញជញ្ជាំងខ្លួនឯង ហើយអ្នកអាចរុញដំរីនៅទីនោះ ដែលនឹងជាន់ឈ្លី... ប៉ុន្តែជាទូទៅ អ្នកអាចស្លៀកពាក់ជាអ្នកជួសជុល មកទាញវាចេញ!

ក្នុង៖ - អរគុណសម្រាប់របាយការណ៍។ លោក Sergey (Yandex) ។ មានថេរនៅក្នុងម៉ុងដែលកំណត់ចំនួនសមាជិកបោះឆ្នោតនៅក្នុងសំណុំចម្លង ហើយថេរនេះគឺ 7 (ប្រាំពីរ)។ ហេតុអ្វីបានជានេះជាថេរ? ហេតុអ្វីនេះមិនមែនជាប៉ារ៉ាម៉ែត្រខ្លះ?

MT៖ - យើងមានឈុតចម្លងដែលមាន 40 ថ្នាំង។ តែងតែមានភាគច្រើន។ មិន​ដឹង​ថា​កំណែ​មួយ​ណា...

ក្នុង៖ - នៅក្នុង Replica Set អ្នកអាចដំណើរការសមាជិកដែលមិនបោះឆ្នោតបាន ប៉ុន្តែមានសមាជិកបោះឆ្នោតអតិបរមា 7 នាក់ តើយើងអាចរួចផុតពីការបិទក្នុងករណីនេះដោយរបៀបណា ប្រសិនបើ Replica Set របស់យើងរីករាលដាលនៅទូទាំង 3 data center? មជ្ឈមណ្ឌលទិន្នន័យមួយអាចបិទបានយ៉ាងងាយស្រួល ហើយម៉ាស៊ីនមួយទៀតអាចធ្លាក់ចេញ។

MT៖ - នេះគឺហួសពីវិសាលភាពនៃរបាយការណ៍ទៅហើយ។ នេះគឺជាសំណួរទូទៅ។ ប្រហែលជាខ្ញុំអាចប្រាប់អ្នកអំពីវានៅពេលក្រោយ។

ការផ្សាយពាណិជ្ជកម្មមួយចំនួន🙂

សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, cloud VPS សម្រាប់អ្នកអភិវឌ្ឍន៍ចាប់ពី $4.99, analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ ការពិតទាំងមូលអំពី VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ចាប់ពី $19 ឬរបៀបចែករំលែកម៉ាស៊ីនមេ? (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។

Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ចាប់ពី $199 នៅប្រទេសហូឡង់! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ចាប់ពី $99! អាន​អំពី របៀបបង្កើតក្រុមហ៊ុនហេដ្ឋារចនាសម្ព័ន្ធ ថ្នាក់ជាមួយនឹងការប្រើប្រាស់ម៉ាស៊ីនមេ Dell R730xd E5-2650 v4 ដែលមានតម្លៃ 9000 អឺរ៉ូសម្រាប់មួយកាក់?

ប្រភព: www.habr.com