របៀបមើលភ្នែក Cassandra ដោយមិនបាត់បង់ទិន្នន័យ ស្ថេរភាព និងជំនឿលើ NoSQL

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

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

Принцип действия системы следующий. На вход приходят файлы с определенной структурой, описывающей структуру вызова. Затем приложение обеспечивает сохранение этой структуры в соответствующие колонки. В дальнейшем сохраненные вызовы используются – для отображения информации по потреблению трафика для абонентов (начисления, звонки, история баланса).

វាច្បាស់ណាស់ថាហេតុអ្វីបានជាពួកគេជ្រើសរើស Cassandra - នាងសរសេរដូចជាកាំភ្លើងយន្ត ងាយស្រួលធ្វើមាត្រដ្ឋាន និងអត់ធ្មត់ចំពោះកំហុស។

ដូច្នេះ នេះជាបទពិសោធន៍ដែលផ្តល់ឱ្យយើង

បាទ ថ្នាំងដែលបរាជ័យមិនមែនជាសោកនាដកម្មទេ។ នេះគឺជាខ្លឹមសារនៃការអត់ឱនកំហុសរបស់ Cassandra ។ ប៉ុន្តែ ថ្នាំងអាចនៅរស់ ហើយក្នុងពេលតែមួយចាប់ផ្តើមរងទុក្ខក្នុងការអនុវត្ត. ដូចដែលវាបានប្រែក្លាយ វាប៉ះពាល់ដល់ដំណើរការនៃចង្កោមទាំងមូលភ្លាមៗ។

Cassandra នឹងមិនការពារអ្នកពីកន្លែងដែល Oracle បានជួយសង្គ្រោះអ្នកជាមួយនឹងឧបសគ្គរបស់វា។. ហើយប្រសិនបើអ្នកនិពន្ធនៃពាក្យសុំមិនយល់ពីរឿងនេះជាមុនទេនោះទ្វេដងដែលបានមកដល់ Cassandra គឺមិនអាក្រក់ជាងដើមទេ។ នៅពេលដែលវាមកដល់យើងនឹងដាក់វា។

IB មិនចូលចិត្ត Cassandra ដោយឥតគិតថ្លៃចេញពីប្រអប់៖ មិន​មាន​ការ​កត់ត្រា​សកម្មភាព​អ្នក​ប្រើ មិន​មាន​ការ​បែងចែក​សិទ្ធិ. ព័ត៌មានអំពីការហៅទូរសព្ទត្រូវបានចាត់ទុកថាជាទិន្នន័យផ្ទាល់ខ្លួន ដែលមានន័យថារាល់ការប៉ុនប៉ងដើម្បីស្នើសុំ/ផ្លាស់ប្តូរវាតាមមធ្យោបាយណាមួយត្រូវតែត្រូវបានកត់ត្រាជាមួយនឹងលទ្ធភាពនៃការធ្វើសវនកម្មជាបន្តបន្ទាប់។ ដូចគ្នានេះផងដែរ, អ្នកត្រូវដឹងអំពីតម្រូវការដើម្បីបំបែកសិទ្ធិនៅកម្រិតផ្សេងគ្នាសម្រាប់អ្នកប្រើប្រាស់ផ្សេងគ្នា។ វិស្វករប្រតិបត្តិការសាមញ្ញ និងអ្នកគ្រប់គ្រងជាន់ខ្ពស់ ដែលអាចលុបចន្លោះគន្លឹះទាំងមូលដោយសេរី មានតួនាទី ទំនួលខុសត្រូវ និងសមត្ថភាពខុសៗគ្នា។ បើគ្មានភាពខុសគ្នានៃសិទ្ធិចូលប្រើទេ តម្លៃ និងភាពត្រឹមត្រូវនៃទិន្នន័យនឹងកើតឡើងភ្លាមៗ លឿនជាងកម្រិតភាពស៊ីសង្វាក់ណាមួយ។

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

យើងជួបប្រទះបញ្ហាក្នុងការផ្ទេរទិន្នន័យទៅកាន់តំបន់សាកល្បង (5 ថ្នាំងក្នុងការធ្វើតេស្តធៀបនឹង 20 ក្នុងពិធីជប់លៀង) ។ ក្នុងករណីនេះ ការចាក់សំរាមមិនអាចប្រើបានទេ។

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

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

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

របៀបដែលយើងបានសម្រេចចិត្ត

ដើម្បីការពារថ្នាំងពីការលិច SWAP ត្រូវបានបិទ. ហើយឥឡូវនេះ ប្រសិនបើខ្វះអង្គចងចាំ នោះថ្នាំងគួរតែចុះក្រោម និងមិនបង្កើតការផ្អាក gc ធំនោះទេ។

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

យើងបានទិញការគាំទ្រពី DataStax ។ ការអភិវឌ្ឍប្រអប់ Cassandra បានឈប់ដំណើរការហើយ (ការប្តេជ្ញាចិត្តចុងក្រោយគឺនៅក្នុងខែកុម្ភៈ 2018) ។ ក្នុងពេលជាមួយគ្នានេះ Datastax ផ្តល់នូវសេវាកម្មដ៏ល្អឥតខ្ចោះ និងដំណោះស្រាយមួយចំនួនធំដែលបានកែប្រែ និងកែសម្រួលសម្រាប់ដំណោះស្រាយ IP ដែលមានស្រាប់។

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

យើងបានពិចារណាជម្រើសពីរ។ នៅក្នុងជម្រើសទីមួយ យើងសរសេរការហៅទូរស័ព្ទមិនត្រឹមតែនៅក្នុង C* ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មាននៅក្នុងឃ្លាំងទិន្នន័យ Oracle ដែលបានទុកក្នុងប័ណ្ណសារផងដែរ។ មិនដូច C* ទេ មូលដ្ឋានទិន្នន័យនេះរក្សាទុកការហៅទូរសព្ទសម្រាប់តែខែបច្ចុប្បន្នប៉ុណ្ណោះ (ជម្រៅនៃការហៅទូរសព្ទគ្រប់គ្រាន់សម្រាប់ករណីបញ្ចូលថ្ម)។ នៅទីនេះយើងឃើញបញ្ហាខាងក្រោមភ្លាមៗ៖ ប្រសិនបើយើងសរសេរសមកាលកម្ម នោះយើងបាត់បង់គុណសម្បត្តិទាំងអស់នៃ C* ដែលភ្ជាប់ជាមួយការបញ្ចូលរហ័ស ប្រសិនបើយើងសរសេរអសមកាល នោះវាមិនមានការធានាថាការហៅចាំបាច់ទាំងអស់ចូលទៅក្នុង Oracle ទាល់តែសោះ។ មានបូកមួយ ប៉ុន្តែធំមួយ៖ សម្រាប់ប្រតិបត្តិការ អ្នកអភិវឌ្ឍន៍ PL/SQL ដែលធ្លាប់ស្គាល់ដូចគ្នានៅតែមាន ពោលគឺយើងអនុវត្តលំនាំ "Facade" ជាជម្រើសជំនួស។ យើងអនុវត្តយន្តការដែលដកការហៅចេញពី C* ទាញទិន្នន័យមួយចំនួនសម្រាប់ការពង្រឹងពីតារាងដែលត្រូវគ្នានៅក្នុង Oracle ចូលរួមជាមួយគំរូលទ្ធផល និងផ្តល់ឱ្យយើងនូវលទ្ធផលដែលបន្ទាប់មកយើងប្រើដូចម្ដេច (រមៀលត្រឡប់មកវិញ ធ្វើម្តងទៀត វិភាគ សរសើរ)។ គុណវិបត្តិ៖ ដំណើរការគឺច្រើនជំហាន ហើយលើសពីនេះទៅទៀត មិនមានចំណុចប្រទាក់សម្រាប់បុគ្គលិកប្រតិបត្តិការទេ។

នៅទីបញ្ចប់យើងបានដោះស្រាយជម្រើសទីពីរ។ Apache Spark ត្រូវបានប្រើដើម្បីយកគំរូពីពាងផ្សេងៗគ្នា។ ខ្លឹមសារនៃយន្តការត្រូវបានកាត់បន្ថយទៅជាកូដ Java ដែលដោយប្រើគ្រាប់ចុចដែលបានបញ្ជាក់ (អ្នកជាវ ពេលវេលាហៅទូរសព្ទ - គ្រាប់ចុចផ្នែក) ទាញទិន្នន័យចេញពី C* ក៏ដូចជាទិន្នន័យចាំបាច់សម្រាប់ការពង្រឹងពីមូលដ្ឋានទិន្នន័យផ្សេងទៀត។ បន្ទាប់ពីនោះវាភ្ជាប់ពួកវានៅក្នុងអង្គចងចាំរបស់វាហើយបង្ហាញលទ្ធផលនៅក្នុងតារាងលទ្ធផល។ យើង​បាន​គូរ​មុខ​បណ្ដាញ​លើ​ផ្កាភ្លើង ហើយ​វា​អាច​ប្រើ​បាន​ណាស់។

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

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

ដើម្បីធានាបាននូវភាពអាចរកបានជាបន្តបន្ទាប់នៃ Cassandra អ្នកត្រូវការ dba ហើយមិនត្រឹមតែគាត់ប៉ុណ្ណោះទេ។ មនុស្សគ្រប់រូបដែលធ្វើការជាមួយកម្មវិធីត្រូវតែយល់ពីកន្លែង និងរបៀបមើលស្ថានភាពបច្ចុប្បន្ន និងរបៀបធ្វើរោគវិនិច្ឆ័យបញ្ហាទាន់ពេលវេលា។ ដើម្បីធ្វើដូច្នេះ យើងប្រើយ៉ាងសកម្ម DataStax OpsCenter (ការគ្រប់គ្រង និងត្រួតពិនិត្យបន្ទុកការងារ) រង្វាស់ប្រព័ន្ធកម្មវិធីបញ្ជា Cassandra (ចំនួននៃការអស់ពេលសម្រាប់ការសរសេរទៅ C* ចំនួននៃការអស់ពេលសម្រាប់ការអានពី C* ភាពយឺតអតិបរមា។ល។) តាមដានប្រតិបត្តិការ។ នៃកម្មវិធីខ្លួនវាធ្វើការជាមួយ Cassandra ។

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

ជាលទ្ធផលសម្រាប់ពេលនេះ ឈប់នៅកម្រិតភាពស៊ីសង្វាក់គ្នាសម្រាប់ការសរសេរ EACH_QUORUM សម្រាប់ការអាន - LOCAL_QUORUM

ចំណាប់អារម្មណ៍ខ្លីៗ និងការសន្និដ្ឋាន

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

ភ្លាមៗនោះ ការវាយតម្លៃទិន្នន័យសម្រាប់កម្មវិធីដូចជា "បង់ប្រាក់នៅពេលដែលវាងាយស្រួល" (យើងផ្ទុកព័ត៌មានទៅក្នុង C* ការគណនាដោយប្រើស្គ្រីប Spark) គណនេយ្យសម្រាប់ការទាមទារជាមួយនឹងការប្រមូលផ្តុំតាមតំបន់ រក្សាទុកតួនាទី និងការគណនាសិទ្ធិចូលប្រើរបស់អ្នកប្រើប្រាស់ដោយផ្អែកលើតួនាទី។ ម៉ាទ្រីស។

ដូចដែលអ្នកបានឃើញហើយ ល្ខោនខោលគឺធំទូលាយ និងផ្លាស់ប្តូរ។ ហើយប្រសិនបើយើងជ្រើសរើសជំរុំអ្នកគាំទ្រ/គូប្រជែងរបស់ NoSQL នោះយើងនឹងចូលរួមជាមួយអ្នកគាំទ្រ ដោយសារយើងទទួលបានគុណសម្បត្តិរបស់យើង និងជាកន្លែងដែលយើងរំពឹងទុក។

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

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

ឧទាហរណ៍ តាមដានព័ត៌មានថ្មីៗរបស់ Cassandra ក្នុងលក្ខណៈទាន់ពេលវេលាដោយសារតែបញ្ហាមួយចំនួនដែលយើងទទួលបានត្រូវបានដឹង និងជួសជុលរួចហើយ។

កុំដាក់ទាំង database ខ្លួនវា និង Spark នៅលើ nodes តែមួយ (ឬបែងចែកយ៉ាងតឹងរ៉ឹងដោយបរិមាណនៃការប្រើប្រាស់ធនធានដែលអាចអនុញ្ញាតបាន) ចាប់តាំងពី Spark អាចស៊ី OP ច្រើនជាងការរំពឹងទុក ហើយយើងនឹងទទួលបានបញ្ហាលេខ 1 ពីបញ្ជីរបស់យើងយ៉ាងឆាប់រហ័ស។

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

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

មិនអាក្រក់ ផ្តល់ភ្លាមៗសម្រាប់ការភ្ជាប់ TTL និងសម្អាតទិន្នន័យហួសសម័យ។

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

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

ប្រសិនបើយើងធ្វើការជាមួយព័ត៌មានសំខាន់ៗ (ដូចជាទិន្នន័យសម្រាប់ការចេញវិក្កយបត្រ ការគណនាបំណុលអតិថិជន) នោះវាក៏មានតម្លៃផងដែរក្នុងការយកចិត្តទុកដាក់លើឧបករណ៍ដែលនឹងកាត់បន្ថយហានិភ័យដែលកើតឡើងដោយសារតែលក្ខណៈពិសេសរបស់ DBMS ។ ឧទាហរណ៍ ប្រើឧបករណ៍ប្រើប្រាស់ nodesync (Datastax) ដោយបានបង្កើតយុទ្ធសាស្ត្រដ៏ល្អប្រសើរសម្រាប់ការប្រើប្រាស់របស់វាតាមលំដាប់លំដោយ។ សម្រាប់ជាប្រយោជន៍នៃភាពជាប់លាប់កុំបង្កើតបន្ទុកលើសលើ Cassandra ហើយប្រើវាសម្រាប់តែតារាងមួយចំនួនក្នុងកំឡុងពេលជាក់លាក់មួយ។

តើមានអ្វីកើតឡើងចំពោះ Cassandra បន្ទាប់ពីប្រាំមួយខែនៃជីវិត? ជាទូទៅមិនមានបញ្ហាដែលមិនទាន់ដោះស្រាយទេ។ យើង​ក៏​មិន​អនុញ្ញាត​ឱ្យ​មាន​គ្រោះថ្នាក់​ធ្ងន់ធ្ងរ ឬ​បាត់បង់​ទិន្នន័យ​ដែរ។ បាទ/ចាស៎ យើងត្រូវគិតអំពីការប៉ះប៉ូវសម្រាប់បញ្ហាមួយចំនួនដែលមិនបានកើតឡើងពីមុនមក ប៉ុន្តែនៅទីបញ្ចប់ នេះមិនបានបិទបាំងដំណោះស្រាយស្ថាបត្យកម្មរបស់យើងយ៉ាងខ្លាំងនោះទេ។ ប្រសិនបើអ្នកចង់និងមិនខ្លាចក្នុងការសាកល្បងអ្វីដែលថ្មីហើយក្នុងពេលតែមួយមិនចង់ខកចិត្តខ្លាំងពេកនោះត្រៀមខ្លួនសម្រាប់ការពិតដែលថាគ្មានអ្វីឥតគិតថ្លៃទេ។ អ្នកនឹងត្រូវយល់ ស្វែងយល់ពីឯកសារ និងប្រមូលផ្តុំនូវតុងរួចផ្ទាល់ខ្លួនរបស់អ្នក ច្រើនជាងនៅក្នុងដំណោះស្រាយកេរ្តិ៍ដំណែលចាស់ ហើយគ្មានទ្រឹស្ដីណាមួយនឹងប្រាប់អ្នកជាមុនថាតុងរួចមួយណាកំពុងរង់ចាំអ្នក។

ប្រភព: www.habr.com