បទសម្ភាសន៍ខ្នាតតូចជាមួយ Oleg Anastasyev: ការអត់ឱនកំហុសនៅក្នុង Apache Cassandra

Odnoklassniki គឺជាអ្នកប្រើប្រាស់ធំបំផុតរបស់ Apache Cassandra នៅលើ RuNet និងជាក្រុមហ៊ុនធំបំផុតមួយក្នុងពិភពលោក។ យើងបានចាប់ផ្តើមប្រើ Cassandra ក្នុងឆ្នាំ 2010 ដើម្បីរក្សាទុកការវាយតម្លៃរូបថត ហើយឥឡូវនេះ Cassandra គ្រប់គ្រងទិន្នន័យ petabytes លើថ្នាំងរាប់ពាន់ តាមពិតយើងថែមទាំងបង្កើតរបស់យើងផ្ទាល់ទៀតផង។ មូលដ្ឋានទិន្នន័យប្រតិបត្តិការ NewSQL.
នៅថ្ងៃទី 12 ខែកញ្ញានៅក្នុងការិយាល័យ St. Petersburg របស់យើងយើងនឹងប្រារព្ធធ្វើ ការជួបលើកទីពីរឧទ្ទិសដល់ Apache Cassandra. វាគ្មិនសំខាន់នៃព្រឹត្តិការណ៍នេះនឹងក្លាយជាប្រធានវិស្វកររបស់ Odnoklassniki Oleg Anastasyev ។ Oleg គឺជាអ្នកជំនាញក្នុងវិស័យប្រព័ន្ធចែកចាយ និងអត់ឱនចំពោះកំហុស គាត់បានធ្វើការជាមួយ Cassandra អស់រយៈពេលជាង 10 ឆ្នាំហើយម្តងហើយម្តងទៀត។ បាននិយាយអំពីលក្ខណៈពិសេសនៃការប្រើប្រាស់ផលិតផលនេះនៅឯសន្និសីទ.

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

Oleg បានចាប់ផ្តើមអាជីពសរសេរកម្មវិធីរបស់គាត់នៅឆ្នាំ 1995 ។ គាត់បានបង្កើតកម្មវិធីនៅក្នុងធនាគារ ទូរគមនាគមន៍ និងការដឹកជញ្ជូន។ គាត់បានធ្វើការជាអ្នកអភិវឌ្ឍន៍ឈានមុខគេនៅ Odnoklassniki តាំងពីឆ្នាំ 2007 នៅលើក្រុមវេទិកា។ ទំនួលខុសត្រូវរបស់គាត់រួមមានការបង្កើតស្ថាបត្យកម្ម និងដំណោះស្រាយសម្រាប់ប្រព័ន្ធផ្ទុកខ្ពស់ ឃ្លាំងទិន្នន័យធំ និងការដោះស្រាយបញ្ហានៃដំណើរការវិបផតថល និងភាពជឿជាក់។ គាត់ក៏បណ្តុះបណ្តាលអ្នកអភិវឌ្ឍន៍នៅក្នុងក្រុមហ៊ុនផងដែរ។

- Oleg ជំរាបសួរ! នៅខែឧសភាបានកើតឡើង ជំនួបដំបូងឧទ្ទិសដល់ Apache Cassandra អ្នកចូលរួមនិយាយថាការពិភាក្សាបានបន្តរហូតដល់យប់ជ្រៅ សូមប្រាប់ខ្ញុំតើអ្នកចាប់អារម្មណ៍អ្វីខ្លះចំពោះការជួបគ្នាលើកដំបូង?

អ្នកអភិវឌ្ឍន៍ដែលមានប្រវត្តិផ្សេងៗគ្នាមកពីក្រុមហ៊ុនផ្សេងៗគ្នាបានមកជាមួយនឹងការឈឺចាប់ផ្ទាល់ខ្លួន ដំណោះស្រាយដែលមិននឹកស្មានដល់ចំពោះបញ្ហា និងរឿងរ៉ាវដ៏អស្ចារ្យ។ យើងបានគ្រប់គ្រងការប្រជុំភាគច្រើនជាទម្រង់ការពិភាក្សា ប៉ុន្តែមានការពិភាក្សាជាច្រើនដែលយើងអាចទាក់ទងបានតែលើប្រធានបទមួយភាគបីនៃប្រធានបទដែលបានគ្រោងទុកប៉ុណ្ណោះ។ យើងបានយកចិត្តទុកដាក់យ៉ាងខ្លាំងចំពោះរបៀប និងអ្វីដែលយើងត្រួតពិនិត្យដោយប្រើឧទាហរណ៍នៃសេវាកម្មផលិតកម្មពិតប្រាកដរបស់យើង។

ខ្ញុំចាប់អារម្មណ៍ ហើយពិតជាចូលចិត្តវា។

- វិនិច្ឆ័យដោយសេចក្តីប្រកាស។ ការជួបលើកទីពីរ នឹងត្រូវលះបង់ទាំងស្រុងចំពោះការអត់ឱនចំពោះកំហុស ហេតុអ្វីបានជាអ្នកជ្រើសរើសប្រធានបទនេះ?

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

- នៅពេលដែលវាមកដល់ Cassandra តើអ្នកមានន័យយ៉ាងណាចំពោះការអត់ឱនចំពោះកំហុស?

ជាដំបូង ជាការពិត សមត្ថភាពរបស់ប្រព័ន្ធអាចរួចផុតពីការបរាជ័យផ្នែករឹងធម្មតា៖ ការបាត់បង់ម៉ាស៊ីន ថាស ឬការតភ្ជាប់បណ្តាញជាមួយថ្នាំង/មជ្ឈមណ្ឌលទិន្នន័យ។ ប៉ុន្តែប្រធានបទខ្លួនវាកាន់តែទូលំទូលាយ ហើយជាពិសេសរួមបញ្ចូលទាំងការងើបឡើងវិញពីការបរាជ័យ រួមទាំងការបរាជ័យដែលមនុស្សកម្រត្រូវបានរៀបចំ ឧទាហរណ៍ កំហុសរបស់ប្រតិបត្តិករ។

- តើអ្នកអាចផ្តល់ឧទាហរណ៍នៃក្រុមទិន្នន័យដែលផ្ទុកច្រើនបំផុត និងធំបំផុតបានទេ?

ចង្កោមដ៏ធំបំផុតមួយរបស់យើងគឺចង្កោមអំណោយ៖ ថ្នាំងជាង 200 និងទិន្នន័យរាប់រយ TB ។ ប៉ុន្តែវាមិនមែនជាការផ្ទុកច្រើនបំផុតទេព្រោះវាត្រូវបានគ្របដណ្តប់ដោយឃ្លាំងសម្ងាត់ដែលបានចែកចាយ។ ចង្កោមដែលមមាញឹកបំផុតរបស់យើងគ្រប់គ្រងរាប់ម៉ឺន RPS សម្រាប់ការសរសេរ និងរាប់ពាន់ RPS សម្រាប់ការអាន។

- វ៉ោ​វ! តើមានអ្វីកើតឡើងញឹកញាប់ប៉ុណ្ណា?

បាទគ្រប់ពេលវេលា! សរុបមក យើងមានម៉ាស៊ីនមេជាង 6 ពាន់ ហើយរៀងរាល់សប្តាហ៍ ពីរបីម៉ាស៊ីនមេ និងថាសរាប់សិបត្រូវបានជំនួស (ដោយមិនគិតពីដំណើរការស្របគ្នានៃការធ្វើឱ្យប្រសើរឡើង និងការពង្រីកកងនាវាម៉ាស៊ីន) ។ សម្រាប់ប្រភេទនៃការបរាជ័យនីមួយៗ មានការណែនាំច្បាស់លាស់អំពីអ្វីដែលត្រូវធ្វើ និងតាមលំដាប់លំដោយ អ្វីគ្រប់យ៉ាងគឺដោយស្វ័យប្រវត្តិនៅពេលណាដែលអាចធ្វើទៅបាន ដូច្នេះការបរាជ័យគឺជាទម្លាប់ ហើយក្នុង 99% នៃករណីកើតឡើងដោយអ្នកប្រើប្រាស់មិនបានកត់សម្គាល់។

- តើអ្នកដោះស្រាយយ៉ាងណាចំពោះការបដិសេធបែបនេះ?

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

- ដូចដែលអ្នកបាននិយាយ មិនមានប្រព័ន្ធដែលអាចទុកចិត្តបានទាំងស្រុងនោះទេ។ តើ​បរាជ័យ​ប្រភេទ​ណា​ខ្លះ​ដែល​អ្នក​ត្រៀម​ខ្លួន​រួច​ហើយ​អាច​រស់​បាន?

ប្រសិនបើយើងនិយាយអំពីការដំឡើង Cassandra clusters របស់យើង អ្នកប្រើប្រាស់នឹងមិនកត់សម្គាល់អ្វីនោះទេ ប្រសិនបើយើងបាត់បង់ម៉ាស៊ីនជាច្រើននៅក្នុង DC មួយ ឬ DC ទាំងមូល (វាបានកើតឡើង)។ ជាមួយនឹងការកើនឡើងនៃចំនួន DCs យើងកំពុងគិតអំពីការចាប់ផ្តើមធានានូវប្រតិបត្តិការក្នុងករណីមានការបរាជ័យនៃ DCs ពីរ។

- តើអ្នកគិតថា Cassandra ខ្វះការអត់ឱនចំពោះកំហុសអ្វីខ្លះ?

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

Oleg សូម​អរគុណ​យ៉ាង​ខ្លាំង​ចំពោះ​ការ​ចំណាយ​ពេល​ដើម្បី​ឆ្លើយ​សំណួរ​!

យើងកំពុងរង់ចាំអ្នកគ្រប់គ្នាដែលចង់ទំនាក់ទំនងជាមួយអ្នកជំនាញក្នុងវិស័យប្រតិបត្តិការ Apache Cassandra នៅឯកិច្ចប្រជុំនៅថ្ងៃទី 12 ខែកញ្ញា នៅក្នុងការិយាល័យ St. Petersburg របស់យើង។

មក វានឹងគួរឱ្យចាប់អារម្មណ៍!

ចុះឈ្មោះសម្រាប់ព្រឹត្តិការណ៍។

ប្រភព: www.habr.com