NewSQL = NoSQL+ACID

រហូតមកដល់ពេលថ្មីៗនេះ Odnoklassniki បានរក្សាទុកទិន្នន័យប្រហែល 50 TB ដែលដំណើរការក្នុងពេលវេលាជាក់ស្តែងនៅក្នុង SQL Server ។ សម្រាប់កម្រិតសំឡេងបែបនេះ វាស្ទើរតែមិនអាចទៅរួចទេក្នុងការផ្តល់នូវល្បឿនលឿន និងអាចទុកចិត្តបាន ហើយសូម្បីតែការចូលដំណើរការដែលមិនដំណើរការដោយមជ្ឈមណ្ឌលទិន្នន័យដោយប្រើ SQL DBMS ។ ជាធម្មតា ក្នុងករណីបែបនេះ កន្លែងផ្ទុក NoSQL មួយត្រូវបានប្រើប្រាស់ ប៉ុន្តែមិនមែនអ្វីៗទាំងអស់អាចត្រូវបានផ្ទេរទៅ NoSQL ទេ៖ អង្គភាពមួយចំនួនទាមទារការធានាប្រតិបត្តិការ ACID ។

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

របៀបដែលវាដំណើរការនិងអ្វីដែលបានកើតឡើង - អាននៅក្រោមការកាត់។

សព្វថ្ងៃនេះ ទស្សនិកជនប្រចាំខែរបស់ Odnoklassniki គឺច្រើនជាង 70 លានអ្នកទស្សនាតែមួយគត់។ យើង យើងស្ថិតនៅក្នុងកំពូលទាំងប្រាំ បណ្តាញសង្គមដ៏ធំបំផុតនៅលើពិភពលោក និងក្នុងចំណោមគេហទំព័រចំនួន 8000 ដែលអ្នកប្រើប្រាស់ចំណាយពេលច្រើនបំផុត។ ហេដ្ឋារចនាសម្ព័ន្ធ OK គ្រប់គ្រងបន្ទុកខ្ពស់៖ សំណើ HTTP ច្រើនជាងមួយលានដងក្នុងមួយវិនាទី។ ផ្នែកនៃកងនាវាម៉ាស៊ីនមេជាង 1 បំណែកមានទីតាំងនៅជិតគ្នា - នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យទីក្រុងម៉ូស្គូចំនួន XNUMX ដែលធ្វើឱ្យវាអាចធានាបាននូវភាពយឺតនៃបណ្តាញតិចជាង XNUMX ms រវាងពួកវា។

យើងបានប្រើប្រាស់ Cassandra តាំងពីឆ្នាំ 2010 ដោយចាប់ផ្តើមជាមួយនឹងកំណែ 0.6។ សព្វ​ថ្ងៃ​នេះ​មាន​ចង្កោម​ជាច្រើន​កំពុង​ដំណើរការ។ ចង្កោមលឿនបំផុតដំណើរការច្រើនជាង 4 លានប្រតិបត្តិការក្នុងមួយវិនាទី ហើយកន្លែងផ្ទុកធំបំផុត 260 TB ។

ទោះយ៉ាងណាក៏ដោយ ទាំងនេះគឺជាចង្កោម NoSQL ធម្មតាទាំងអស់ដែលប្រើសម្រាប់ការផ្ទុក សម្របសម្រួលខ្សោយ ទិន្នន័យ។ យើងចង់ជំនួសកន្លែងផ្ទុកជាប់លាប់សំខាន់ Microsoft SQL Server ដែលត្រូវបានប្រើចាប់តាំងពីការបង្កើត Odnoklassniki ។ ការផ្ទុកមានម៉ាស៊ីន SQL Server Standard Edition ច្រើនជាង 300 ដែលមានផ្ទុកទិន្នន័យ 50 TB - អង្គភាពអាជីវកម្ម។ ទិន្នន័យនេះត្រូវបានកែប្រែជាផ្នែកនៃប្រតិបត្តិការ ACID និងទាមទារ ភាពជាប់លាប់ខ្ពស់។.

ដើម្បីចែកចាយទិន្នន័យឆ្លងកាត់ថ្នាំង SQL Server យើងបានប្រើទាំងបញ្ឈរ និងផ្ដេក ការបែងចែក (ការបំបែក) ។ ជាប្រវត្តិសាស្ត្រ យើងបានប្រើគ្រោងការណ៍បំបែកទិន្នន័យសាមញ្ញ៖ អង្គភាពនីមួយៗត្រូវបានភ្ជាប់ជាមួយសញ្ញាសម្ងាត់ - មុខងារនៃលេខសម្គាល់អង្គភាព។ អង្គភាពដែលមានសញ្ញាសម្ងាត់ដូចគ្នាត្រូវបានដាក់នៅលើម៉ាស៊ីនមេ SQL ដូចគ្នា។ ទំនាក់ទំនងលម្អិតមេត្រូវបានអនុវត្ត ដូច្នេះសញ្ញាសម្ងាត់នៃកំណត់ត្រាសំខាន់ និងកូនតែងតែត្រូវគ្នា ហើយមានទីតាំងនៅលើម៉ាស៊ីនមេតែមួយ។ នៅក្នុងបណ្តាញសង្គម កំណត់ត្រាស្ទើរតែទាំងអស់ត្រូវបានបង្កើតក្នុងនាមអ្នកប្រើប្រាស់ ដែលមានន័យថាទិន្នន័យអ្នកប្រើប្រាស់ទាំងអស់នៅក្នុងប្រព័ន្ធរងមុខងារមួយត្រូវបានរក្សាទុកនៅលើម៉ាស៊ីនមេមួយ។ នោះគឺប្រតិបត្តិការអាជីវកម្មស្ទើរតែតែងតែជាប់ពាក់ព័ន្ធតារាងពីម៉ាស៊ីនមេ SQL មួយ ដែលធ្វើឱ្យវាអាចធានាបាននូវភាពស៊ីសង្វាក់គ្នានៃទិន្នន័យដោយប្រើប្រតិបត្តិការ ACID ក្នុងតំបន់ ដោយមិនចាំបាច់ប្រើ។ យឺតនិងមិនគួរឱ្យទុកចិត្ត ប្រតិបត្តិការ ACID ចែកចាយ។

សូមអរគុណចំពោះការ sharding និងបង្កើនល្បឿន SQL:

• យើង​មិន​ប្រើ​ឧបសគ្គ​សោបរទេស​ទេ ព្រោះ​ពេល​បំបែក​លេខ​សម្គាល់​អង្គភាព​អាច​មាន​ទីតាំង​នៅ​លើ​ម៉ាស៊ីន​មេ​ផ្សេង។
• យើងមិនប្រើនីតិវិធីដែលបានរក្សាទុក និងការកេះដោយសារតែការផ្ទុកបន្ថែមនៅលើស៊ីភីយូ DBMS ។
• យើងមិនប្រើ JOINs ទេ ដោយសារតែទាំងអស់ខាងលើ និងការអានចៃដន្យជាច្រើនពីថាស។
• នៅខាងក្រៅប្រតិបត្តិការមួយ យើងប្រើកម្រិតភាពឯកោរបស់ Read Uncommitted ដើម្បីកាត់បន្ថយការជាប់គាំង។
• យើងអនុវត្តតែប្រតិបត្តិការខ្លីប៉ុណ្ណោះ (ជាមធ្យមខ្លីជាង 100 ms) ។
• យើងមិនប្រើ UPDATE និង DELETE ច្រើនជួរទេ ដោយសារចំនួនជាប់គាំងច្រើន - យើងធ្វើបច្ចុប្បន្នភាពតែមួយកំណត់ត្រាក្នុងពេលតែមួយ។
• យើងតែងតែអនុវត្តសំណួរតែលើលិបិក្រមប៉ុណ្ណោះ - សំណួរដែលមានផែនការស្កេនតារាងពេញសម្រាប់យើងមានន័យថាផ្ទុកទិន្នន័យលើសទម្ងន់ ហើយបណ្តាលឱ្យវាបរាជ័យ។

ជំហានទាំងនេះបានអនុញ្ញាតឱ្យយើងច្របាច់ដំណើរការស្ទើរតែអតិបរមាចេញពីម៉ាស៊ីនមេ SQL ។ ទោះយ៉ាងណាក៏ដោយ បញ្ហាកាន់តែច្រើនឡើងៗ។ សូមក្រឡេកមើលពួកគេ។

បញ្ហាជាមួយ SQL

• ដោយសារ​យើង​ប្រើ​ការ​សរសេរ​ដោយ​ខ្លួន​ឯង ការ​បន្ថែម​ការ​បំបែក​ថ្មី​ត្រូវ​បាន​ធ្វើ​ដោយ​ដៃ​ដោយ​អ្នក​គ្រប់គ្រង។ គ្រប់ពេលវេលានេះ ការចម្លងទិន្នន័យដែលអាចធ្វើមាត្រដ្ឋានបានមិនផ្តល់សេវាសំណើទេ។
• នៅពេលដែលចំនួនកំណត់ត្រាក្នុងតារាងកើនឡើង ល្បឿននៃការបញ្ចូល និងការកែប្រែថយចុះ នៅពេលបន្ថែមលិបិក្រមទៅក្នុងតារាងដែលមានស្រាប់ ល្បឿនធ្លាក់ចុះដោយសារកត្តាបង្កើត និងការបង្កើតឡើងវិញនៃលិបិក្រមកើតឡើង។
• ការមាន Windows តិចតួចសម្រាប់ SQL Server ក្នុងការផលិតធ្វើឱ្យការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធមានការលំបាក

ប៉ុន្តែបញ្ហាចម្បងគឺ

ការអត់ធ្មត់កំហុស

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

តើត្រូវធ្វើអ្វីដើម្បីកែលម្អភាពអត់ធ្មត់នៃកំហុសរបស់ម៉ាស៊ីនមេ SQL? វិគីភីឌាអញ្ជើញយើងឱ្យសាងសង់ ចង្កោមដែលអាចប្រើបានខ្ពស់។៖ ក្នុងករណីដែលការបរាជ័យនៃសមាសធាតុណាមួយ មានការបម្រុងទុកមួយ។

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

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

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

បញ្ហាទាំងអស់នេះទាមទារដំណោះស្រាយរ៉ាឌីកាល់ ហើយយើងបានចាប់ផ្តើមវិភាគពួកវាយ៉ាងលម្អិត។ នៅទីនេះយើងត្រូវស្គាល់ពីអ្វីដែល SQL Server ធ្វើជាចម្បង - ប្រតិបត្តិការ។

ប្រតិបត្តិការសាមញ្ញ

ចូរយើងពិចារណាអំពីប្រតិបត្តិការដ៏សាមញ្ញបំផុត ពីទស្សនៈរបស់អ្នកសរសេរកម្មវិធី SQL ដែលបានអនុវត្ត៖ ការបន្ថែមរូបថតទៅអាល់ប៊ុម។ អាល់ប៊ុម និងរូបថតត្រូវបានរក្សាទុកក្នុងចានផ្សេងៗគ្នា។ អាល់ប៊ុមនេះមានបញ្ជររូបថតសាធារណៈ។ បន្ទាប់មកប្រតិបត្តិការបែបនេះត្រូវបានបែងចែកជាជំហានដូចខាងក្រោមៈ

1. យើងចាក់សោអាល់ប៊ុមដោយគន្លឹះ។
2. បង្កើតធាតុនៅក្នុងតារាងរូបថត។
3. ប្រសិនបើរូបថតមានស្ថានភាពសាធារណៈ បន្ទាប់មកបន្ថែមរូបថតសាធារណៈទៅក្នុងអាល់ប៊ុម ធ្វើបច្ចុប្បន្នភាពកំណត់ត្រា និងធ្វើប្រតិបត្តិការ។

ឬនៅក្នុង pseudocode៖

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

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

នៅពេលដំណើរការប្រតិបត្តិការ ការកែប្រែទិន្នន័យដូចគ្នាពីប្រព័ន្ធមួយផ្សេងទៀតអាចនឹងកើតឡើង។ ជាឧទាហរណ៍ Antispam អាចសម្រេចចិត្តថាអ្នកប្រើប្រាស់មានការសង្ស័យ ហើយដូច្នេះរូបថតរបស់អ្នកប្រើប្រាស់ទាំងអស់មិនគួរបង្ហាញជាសាធារណៈទៀតទេ ពួកគេត្រូវផ្ញើសម្រាប់ការសម្របសម្រួល ដែលមានន័យថាផ្លាស់ប្តូរ photo.status ទៅតម្លៃផ្សេងទៀត ហើយបិទបញ្ជរដែលត្រូវគ្នា។ ជាក់ស្តែង ប្រសិនបើប្រតិបត្តិការនេះកើតឡើងដោយគ្មានការធានាអំពីអាតូមិកនៃការអនុវត្ត និងឯកោនៃការកែប្រែប្រកួតប្រជែង ដូចនៅក្នុង ទឹកអាស៊ីដបន្ទាប់មកលទ្ធផលនឹងមិនមែនជាអ្វីដែលត្រូវការទេ - ទាំងបញ្ជររូបថតនឹងបង្ហាញតម្លៃខុស ឬមិនមែនរូបថតទាំងអស់នឹងត្រូវបានផ្ញើសម្រាប់ការសម្របសម្រួល។

កូដស្រដៀងគ្នាជាច្រើនដែលរៀបចំអង្គភាពអាជីវកម្មផ្សេងៗក្នុងប្រតិបត្តិការតែមួយត្រូវបានសរសេរពេញមួយអត្ថិភាពនៃ Odnoklassniki ។ ផ្អែកលើបទពិសោធន៍នៃការធ្វើចំណាកស្រុកទៅ NoSQL ពី ភាពស៊ីសង្វាក់គ្នាជាយថាហេតុ យើងដឹងថាបញ្ហាប្រឈមដ៏ធំបំផុត (និងការវិនិយោគពេលវេលា) បានមកពីការបង្កើតកូដដើម្បីរក្សាភាពស៊ីសង្វាក់គ្នានៃទិន្នន័យ។ ដូច្នេះហើយ យើងបានចាត់ទុកតម្រូវការចម្បងសម្រាប់ទំហំផ្ទុកថ្មី គឺជាការផ្តល់ជូនសម្រាប់ប្រតិបត្តិការ ACID ពិតប្រាកដសម្រាប់តក្កវិជ្ជាកម្មវិធី។

តម្រូវការផ្សេងទៀត មិនសំខាន់តិចទេ គឺ៖

• ប្រសិនបើមជ្ឈមណ្ឌលទិន្នន័យបរាជ័យ ទាំងការអាន និងការសរសេរទៅកាន់កន្លែងផ្ទុកថ្មីត្រូវតែមាន។
• រក្សាល្បឿននៃការអភិវឌ្ឍន៍បច្ចុប្បន្ន។ នោះគឺនៅពេលធ្វើការជាមួយឃ្លាំងថ្មី បរិមាណនៃកូដគួរតែមានប្រហែលដូចគ្នា មិនគួរបន្ថែមអ្វីទៅក្នុងឃ្លាំង បង្កើតក្បួនដោះស្រាយសម្រាប់ដោះស្រាយជម្លោះ រក្សាលិបិក្រមបន្ទាប់បន្សំ។ល។
• ល្បឿននៃការផ្ទុកថ្មីត្រូវតែខ្ពស់ណាស់ ទាំងពេលអានទិន្នន័យ និងពេលដំណើរការប្រតិបត្តិការ ដែលមានន័យយ៉ាងមានប្រសិទ្ធភាពថា ការសិក្សាមានភាពម៉ត់ចត់ជាសកល ប៉ុន្តែដំណោះស្រាយយឺត ដូចជាឧទាហរណ៍ មិនអាចអនុវត្តបានទេ ការប្តេជ្ញាចិត្តពីរដំណាក់កាល.
• ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ។
• ការប្រើប្រាស់ម៉ាស៊ីនមេថោកធម្មតាដោយមិនចាំបាច់ទិញផ្នែករឹងកម្រនិងអសកម្ម។
• លទ្ធភាពនៃការអភិវឌ្ឍន៍ការផ្ទុកដោយអ្នកអភិវឌ្ឍន៍ក្រុមហ៊ុន។ ម្យ៉ាងវិញទៀត អាទិភាពត្រូវបានផ្តល់ទៅឱ្យដំណោះស្រាយដែលមានកម្មសិទ្ធិ ឬប្រភពបើកចំហ និយមនៅក្នុង Java ។

ការសម្រេចចិត្ត, ការសម្រេចចិត្ត

ការវិភាគដំណោះស្រាយដែលអាចកើតមាន យើងបានមករកជម្រើសស្ថាបត្យកម្មដែលអាចមានពីរ៖

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

ជម្រើសទីពីរគឺយកកន្លែងផ្ទុក NoSQL ដែលត្រៀមរួចជាស្រេចជាមួយនឹងការធ្វើមាត្រដ្ឋានដែលបានអនុវត្ត ចង្កោមបរាជ័យ ការដោះស្រាយជម្លោះ និងអនុវត្តប្រតិបត្តិការ និង SQL ដោយខ្លួនឯង។ នៅ glance ដំបូងសូម្បីតែភារកិច្ចនៃការអនុវត្ត SQL ដែលមិននិយាយអំពីប្រតិបត្តិការ ACID មើលទៅដូចជាកិច្ចការដែលនឹងចំណាយពេលច្រើនឆ្នាំ។ ប៉ុន្តែបន្ទាប់មកយើងបានដឹងថាសំណុំលក្ខណៈពិសេស SQL ដែលយើងប្រើក្នុងការអនុវត្តគឺនៅឆ្ងាយពី ANSI SQL ដូច Cassandra CQL ឆ្ងាយពី ANSI SQL ។ ដោយក្រឡេកមើល CQL កាន់តែជិត យើងបានដឹងថាវាជិតដល់អ្វីដែលយើងត្រូវការ។

Cassandra និង CQL

ដូច្នេះ​តើ​ Cassandra មាន​សមត្ថភាព​អ្វី​គួរ​ឱ្យ​ចាប់​អារម្មណ៍?

ទីមួយ នៅទីនេះអ្នកអាចបង្កើតតារាងដែលគាំទ្រប្រភេទទិន្នន័យផ្សេងៗ អ្នកអាចធ្វើ SELECT ឬ UPDATE នៅលើសោចម្បង។

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

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

វិធីសាស្រ្តនៅពេលដែលយើងទាក់ទងថ្នាំងបីហើយទទួលបានការឆ្លើយតបពីពីរត្រូវបានគេហៅថា ការរំពឹងទុក៖ សំណើសម្រាប់ការចម្លងបន្ថែមត្រូវបានផ្ញើសូម្បីតែមុនពេលវា "ធ្លាក់"

អត្ថប្រយោជន៍មួយទៀតរបស់ Cassandra គឺ Batchlog ដែលជាយន្តការដែលធានាថាការផ្លាស់ប្ដូរមួយចំនួនដែលអ្នកបានធ្វើគឺត្រូវបានអនុវត្តទាំងស្រុង ឬមិនត្រូវបានអនុវត្តទាល់តែសោះ។ នេះអនុញ្ញាតឱ្យយើងដោះស្រាយ A ក្នុង ACID - អាតូមិចចេញពីប្រអប់។

អ្វី​ដែល​ជិត​បំផុត​ចំពោះ​ប្រតិបត្តិការ​នៅ Cassandra គឺ​គេ​ហៅ​ថា "ប្រតិបត្តិការស្រាល"។ ប៉ុន្តែពួកគេនៅឆ្ងាយពីប្រតិបត្តិការ ACID "ពិតប្រាកដ"៖ តាមពិតនេះគឺជាឱកាសដើម្បីធ្វើ CAS នៅលើទិន្នន័យពីកំណត់ត្រាតែមួយ ដោយប្រើការយល់ស្របដោយប្រើពិធីការ Paxos ទម្ងន់ធ្ងន់។ ដូច្នេះល្បឿននៃប្រតិបត្តិការបែបនេះមានកម្រិតទាប។

អ្វីដែលយើងបាត់នៅ Cassandra

ដូច្នេះ យើងត្រូវអនុវត្តប្រតិបត្តិការ ACID ពិតប្រាកដនៅក្នុង Cassandra ។ ការប្រើប្រាស់ដែលយើងអាចអនុវត្តបានយ៉ាងងាយស្រួលនូវមុខងារងាយស្រួលពីរផ្សេងទៀតនៃ DBMS បុរាណ៖ លិបិក្រមដែលមានល្បឿនលឿនស្របគ្នា ដែលនឹងអនុញ្ញាតឱ្យយើងធ្វើការជ្រើសរើសទិន្នន័យមិនត្រឹមតែដោយសោចម្បងប៉ុណ្ណោះទេ និងជាម៉ាស៊ីនបង្កើតធម្មតានៃលេខសម្គាល់ការបង្កើនស្វ័យប្រវត្តិ monotonic ។

កោណ

ដូច្នេះ DBMS ថ្មីបានកើត កោណ, មានបីប្រភេទនៃថ្នាំងម៉ាស៊ីនមេ:

• ការផ្ទុក - (ស្ទើរតែ) ម៉ាស៊ីនមេ Cassandra ស្តង់ដារដែលទទួលខុសត្រូវក្នុងការរក្សាទុកទិន្នន័យនៅលើថាសមូលដ្ឋាន។ នៅពេលដែលការផ្ទុក និងបរិមាណទិន្នន័យកើនឡើង បរិមាណរបស់ពួកគេអាចត្រូវបានធ្វើមាត្រដ្ឋានយ៉ាងងាយស្រួលដល់រាប់សិបទៅរាប់រយ។
• អ្នកសម្របសម្រួលប្រតិបត្តិការ - ធានានូវការអនុវត្តប្រតិបត្តិការ។
• អតិថិជនគឺជាម៉ាស៊ីនមេកម្មវិធីដែលអនុវត្តប្រតិបត្តិការអាជីវកម្ម និងផ្តួចផ្តើមប្រតិបត្តិការ។ វាអាចមានអតិថិជនរាប់ពាន់នាក់។

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

អតិថិជន

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

C*One Transaction Coordinator

អ្នកសម្របសម្រួលគឺជាអ្វីដែលយើងបានអនុវត្តសម្រាប់ C*One តាំងពីដំបូង។ វាទទួលខុសត្រូវក្នុងការគ្រប់គ្រងប្រតិបត្តិការ ការចាក់សោរ និងលំដាប់ដែលប្រតិបត្តិការត្រូវបានអនុវត្ត។

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

សោ

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

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

ដោយសារក្នុងករណីរបស់យើងទិន្នន័យត្រូវបានចែកចាយរួចហើយក្នុងចំណោមក្រុមនៃប្រតិបត្តិការក្នុងស្រុកនៅក្នុង SQL វាត្រូវបានគេសម្រេចចិត្តចាត់តាំងក្រុមប្រតិបត្តិការក្នុងតំបន់ទៅឱ្យអ្នកសម្របសម្រួល៖ អ្នកសម្របសម្រួលម្នាក់ធ្វើប្រតិបត្តិការទាំងអស់ជាមួយនឹងសញ្ញាសម្ងាត់ពី 0 ដល់ 9, ទីពីរ - ជាមួយសញ្ញាសម្ងាត់ពី 10 ដល់ 19, ល​ល។ ជាលទ្ធផល អ្នកសម្របសម្រួលនីមួយៗក្លាយជាម្ចាស់នៃក្រុមប្រតិបត្តិការ។

បន្ទាប់មកការចាក់សោអាចត្រូវបានអនុវត្តជាទម្រង់ banal HashMap នៅក្នុងការចងចាំរបស់អ្នកសម្របសម្រួល។

ការបរាជ័យរបស់អ្នកសម្របសម្រួល

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

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

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

សារចង្វាក់បេះដូងត្រូវបានផ្ញើជាមួយនឹងប្រេកង់ខ្ពស់ប្រហែល 20 ដងក្នុងមួយវិនាទីជាមួយនឹងរយៈពេល 50 ms ។ នៅក្នុង Java វាពិបាកក្នុងការធានាការឆ្លើយតបរបស់កម្មវិធីក្នុងរយៈពេល 50 ms ដោយសារតែរយៈពេលនៃការផ្អាកដែលអាចប្រៀបធៀបបានដែលបណ្តាលមកពីអ្នកប្រមូលសំរាម។ យើងអាចសម្រេចបាននូវពេលវេលាឆ្លើយតបនេះដោយប្រើឧបករណ៍ប្រមូលសំរាម G1 ដែលអនុញ្ញាតឱ្យយើងបញ្ជាក់គោលដៅសម្រាប់រយៈពេលនៃការផ្អាក GC ។ ទោះយ៉ាងណាក៏ដោយ ពេលខ្លះកម្រណាស់ អ្នកប្រមូលផ្អាកលើសពី 50 ms ដែលអាចនាំឱ្យមានការរកឃើញកំហុសមិនពិត។ ដើម្បីការពារកុំឱ្យវាកើតឡើង អ្នកសម្របសម្រួលមិនរាយការណ៍ពីការបរាជ័យនៃថ្នាំងពីចម្ងាយ នៅពេលដែលសារចង្វាក់បេះដូងដំបូងពីវាបាត់ លុះត្រាតែមនុស្សជាច្រើនបានបាត់ជាបន្តបន្ទាប់ នេះជារបៀបដែលយើងអាចរកឃើញការបរាជ័យនៃថ្នាំងអ្នកសម្របសម្រួលក្នុង 200 ms

ប៉ុន្តែវាមិនគ្រប់គ្រាន់ទេក្នុងការយល់យ៉ាងឆាប់រហ័សថាថ្នាំងណាបានឈប់ដំណើរការ។ យើងត្រូវធ្វើអ្វីមួយអំពីរឿងនេះ។

ការកក់ទុក

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

ឧបមាថាយើងចង់ប្រតិបត្តិប្រតិបត្តិការក្នុងក្រុមទី 50។ ចូរកំណត់ជាមុននូវគ្រោងការណ៍ជំនួស ពោលគឺថ្នាំងណានឹងប្រតិបត្តិប្រតិបត្តិការក្នុងក្រុម 50 ក្នុងករណីមានការបរាជ័យរបស់អ្នកសម្របសម្រួលសំខាន់។ គោលដៅរបស់យើងគឺដើម្បីរក្សាមុខងាររបស់ប្រព័ន្ធក្នុងករណីមានការបរាជ័យនៃមជ្ឈមណ្ឌលទិន្នន័យ។ ចូរកំណត់ថាទុនបម្រុងទីមួយនឹងជាថ្នាំងពីមជ្ឈមណ្ឌលទិន្នន័យមួយផ្សេងទៀត ហើយទុនបម្រុងទីពីរនឹងជាថ្នាំងពីទីបី។ គ្រោងការណ៍នេះត្រូវបានជ្រើសរើសម្តងហើយមិនផ្លាស់ប្តូរទេរហូតដល់ topology នៃ cluster ផ្លាស់ប្តូរ ពោលគឺរហូតដល់ថ្នាំងថ្មីបញ្ចូលវា (ដែលកើតឡើងកម្រណាស់)។ នីតិវិធីសម្រាប់ការជ្រើសរើសមេសកម្មថ្មី ប្រសិនបើចាស់បរាជ័យនឹងតែងតែមានដូចខាងក្រោម៖ ទុនបម្រុងទីមួយនឹងក្លាយជាមេសកម្ម ហើយប្រសិនបើវាឈប់ដំណើរការ ទុនបម្រុងទីពីរនឹងក្លាយជាមេសកម្ម។

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

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

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

របៀបដែលប្រតិបត្តិការដំណើរការ

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

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

នៅពេលដែលអតិថិជនស្នើសុំទិន្នន័យដែលបានផ្លាស់ប្តូររបស់ខ្លួនជាផ្នែកនៃប្រតិបត្តិការសកម្ម អ្នកសម្របសម្រួលធ្វើសកម្មភាពដូចខាងក្រោម៖

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

ដូច្នេះ អតិថិជនអាចអានការផ្លាស់ប្តូររបស់ខ្លួន ប៉ុន្តែអតិថិជនផ្សេងទៀតមិនឃើញការផ្លាស់ប្តូរទាំងនេះទេ ព្រោះពួកវាត្រូវបានរក្សាទុកតែនៅក្នុងសតិរបស់អ្នកសម្របសម្រួលប៉ុណ្ណោះ ពួកគេមិនទាន់មាននៅក្នុងថ្នាំង Cassandra ទេ។

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

ហើយដើម្បីវិលត្រឡប់មកវិញ អ្នកសម្របសម្រួលគ្រាន់តែត្រូវការដោះលែងអង្គចងចាំដែលកាន់កាប់ដោយស្ថានភាពប្រតិបត្តិការប៉ុណ្ណោះ។

ជាលទ្ធផលនៃការកែលម្អខាងលើ យើងបានអនុវត្តគោលការណ៍ ACID៖

• អាតូមិច. នេះគឺជាការធានាថាគ្មានប្រតិបត្តិការណាមួយនឹងត្រូវបានកត់ត្រាដោយផ្នែកនៅក្នុងប្រព័ន្ធ ទាំងប្រតិបត្តិការរងរបស់វាទាំងអស់នឹងត្រូវបានបញ្ចប់ ឬមិនមានណាមួយនឹងត្រូវបានបញ្ចប់។ យើងប្រកាន់ខ្ជាប់នូវគោលការណ៍នេះតាមរយៈក្រុមដែលបានកត់ត្រានៅក្នុង Cassandra ។
• ភាពជាប់លាប់. ប្រតិបត្តិការជោគជ័យនីមួយៗ តាមនិយមន័យ កត់ត្រាតែលទ្ធផលត្រឹមត្រូវប៉ុណ្ណោះ។ ប្រសិនបើបន្ទាប់ពីបើកប្រតិបត្តិការ និងអនុវត្តផ្នែកនៃប្រតិបត្តិការ វាត្រូវបានគេរកឃើញថាលទ្ធផលមិនត្រឹមត្រូវ ការវិលត្រឡប់មកវិញត្រូវបានអនុវត្ត។
• ការដាក់ឱ្យនៅដាច់ដោយឡែក. នៅពេលប្រតិបត្តិការត្រូវបានប្រតិបត្តិ ប្រតិបត្តិការដំណាលគ្នាមិនគួរប៉ះពាល់ដល់លទ្ធផលរបស់វាទេ។ ប្រតិបត្តិការប្រកួតប្រជែងគឺដាច់ដោយឡែកដោយប្រើសោទុទិដ្ឋិនិយមនៅលើអ្នកសម្របសម្រួល។ សម្រាប់ការអាននៅខាងក្រៅប្រតិបត្តិការ គោលការណ៍ឯកោត្រូវបានអង្កេតនៅកម្រិត Read Committed ។
• និរន្តរភាព. ដោយមិនគិតពីបញ្ហានៅកម្រិតទាប - ការដាច់ប្រព័ន្ធ ការបរាជ័យផ្នែករឹង - ការផ្លាស់ប្តូរដែលធ្វើឡើងដោយប្រតិបត្តិការដែលបានបញ្ចប់ដោយជោគជ័យគួរតែត្រូវបានរក្សាទុកនៅពេលដែលប្រតិបត្តិការបន្ត។

ការអានដោយសន្ទស្សន៍

តោះយកតារាងសាមញ្ញមួយ៖

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

វាមានលេខសម្គាល់ (កូនសោចម្បង) ម្ចាស់ និងកាលបរិច្ឆេទកែប្រែ។ អ្នកត្រូវធ្វើសំណើសាមញ្ញបំផុត - ជ្រើសរើសទិន្នន័យនៅលើម្ចាស់ជាមួយនឹងកាលបរិច្ឆេទផ្លាស់ប្តូរ "សម្រាប់ថ្ងៃចុងក្រោយ" ។

SELECT *
WHERE owner=?
AND modified>?

ដើម្បីឱ្យសំណួរបែបនេះត្រូវបានដំណើរការយ៉ាងឆាប់រហ័ស ក្នុង SQL DBMS បុរាណ អ្នកត្រូវបង្កើតលិបិក្រមដោយជួរឈរ (ម្ចាស់ កែប្រែ)។ យើង​អាច​ធ្វើ​វា​បាន​យ៉ាង​ងាយ ព្រោះ​ឥឡូវ​នេះ​យើង​មាន​ការ​ធានា​ពី ACID!

សន្ទស្សន៍ក្នុង C*One

មានតារាងប្រភពដែលមានរូបថតដែលលេខសម្គាល់កំណត់ត្រាគឺជាគន្លឹះចម្បង។

សម្រាប់សន្ទស្សន៍ C*One បង្កើតតារាងថ្មីមួយដែលជាច្បាប់ចម្លងនៃដើម។ សោគឺដូចគ្នាទៅនឹងកន្សោមលិបិក្រម ហើយវាក៏រួមបញ្ចូលសោចម្បងនៃកំណត់ត្រាពីតារាងប្រភពផងដែរ៖

ឥឡូវនេះសំណួរសម្រាប់ "ម្ចាស់សម្រាប់ថ្ងៃចុងក្រោយ" អាចត្រូវបានសរសេរឡើងវិញជាជម្រើសពីតារាងផ្សេងទៀត:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

ដោយប្រើ ACID យើងអាចអនុវត្តលិបិក្រមដូច SQL ។ ពួកវាមានភាពស៊ីសង្វាក់គ្នា អាចធ្វើមាត្រដ្ឋានបាន លឿន ផ្សំឡើង និងបានបង្កើតឡើងនៅក្នុងភាសាសំណួរ CQL ។ មិនចាំបាច់មានការផ្លាស់ប្តូរកូដកម្មវិធីដើម្បីគាំទ្រលិបិក្រមទេ។ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញដូចនៅក្នុង SQL ។ ហើយសំខាន់បំផុត លិបិក្រមមិនប៉ះពាល់ដល់ល្បឿនប្រតិបត្តិនៃការកែប្រែចំពោះតារាងប្រតិបត្តិការដើមទេ។

តើមានអ្វីកើតឡើង

យើងបានបង្កើត C*One កាលពីបីឆ្នាំមុន ហើយបានចាប់ផ្តើមវាទៅជាប្រតិបត្តិការពាណិជ្ជកម្ម។

តើយើងទទួលបានអ្វីនៅទីបញ្ចប់? ចូរយើងវាយតម្លៃវាដោយប្រើឧទាហរណ៍នៃប្រព័ន្ធរងដំណើរការរូបថត និងការផ្ទុក ដែលជាប្រភេទទិន្នន័យសំខាន់បំផុតមួយនៅក្នុងបណ្តាញសង្គម។ យើងមិននិយាយអំពីរូបធាតុនៃរូបថតខ្លួនឯងទេ ប៉ុន្តែអំពីព័ត៌មានមេតាគ្រប់ប្រភេទ។ ឥឡូវនេះ Odnoklassniki មានកំណត់ត្រាបែបនេះប្រហែល 20 ពាន់លាន ដែលប្រព័ន្ធដំណើរការសំណើអាន 80 ពាន់ក្នុងមួយវិនាទី រហូតដល់ 8 ពាន់ប្រតិបត្តិការ ACID ក្នុងមួយវិនាទីដែលទាក់ទងនឹងការកែប្រែទិន្នន័យ។

នៅពេលយើងប្រើ SQL ជាមួយកត្តាចម្លង = 1 (ប៉ុន្តែនៅក្នុង RAID 10) ទម្រង់រូបភាពត្រូវបានរក្សាទុកនៅលើចង្កោមដែលមានម៉ាស៊ីនចំនួន 32 ដែលដំណើរការដោយ Microsoft SQL Server (បូកនឹងការបម្រុងទុក 11) ។ ម៉ាស៊ីនមេចំនួន 10 ក៏ត្រូវបានបែងចែកសម្រាប់រក្សាទុកការបម្រុងទុកផងដែរ។ រថយន្ត​ថ្លៃ​ៗ​សរុប​ចំនួន​៥០​គ្រឿង​។ ក្នុងពេលជាមួយគ្នានេះ ប្រព័ន្ធដំណើរការនៅបន្ទុកដែលបានវាយតម្លៃ ដោយគ្មានទុនបម្រុង។

បន្ទាប់ពីធ្វើចំណាកស្រុកទៅប្រព័ន្ធថ្មី យើងបានទទួលកត្តាចម្លង = 3 - ច្បាប់ចម្លងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យនីមួយៗ។ ប្រព័ន្ធនេះមានឧបករណ៍ផ្ទុក Cassandra ចំនួន 63 និងម៉ាស៊ីនសម្របសម្រួលចំនួន 6 សម្រាប់ម៉ាស៊ីនមេសរុបចំនួន 69 ។ ប៉ុន្តែម៉ាស៊ីនទាំងនេះមានតម្លៃថោកជាង ការចំណាយសរុបរបស់ពួកគេគឺប្រហែល 30% នៃតម្លៃនៃប្រព័ន្ធ SQL ។ ក្នុងពេលជាមួយគ្នាការផ្ទុកត្រូវបានរក្សាទុកនៅ 30% ។

ជាមួយនឹងការណែនាំ C*One ភាពយឺតយ៉ាវក៏ថយចុះផងដែរ៖ នៅក្នុង SQL ប្រតិបត្តិការសរសេរបានចំណាយពេលប្រហែល 4,5 ms ។ នៅក្នុង C * One - ប្រហែល 1,6 ms ។ រយៈពេលប្រតិបត្តិការជាមធ្យមគឺតិចជាង 40 ms ការប្តេជ្ញាចិត្តត្រូវបានបញ្ចប់ក្នុង 2 ms រយៈពេលអាននិងសរសេរជាមធ្យម 2 ms ។ ភាគរយទី 99 - ត្រឹមតែ 3-3,1 ms ចំនួននៃការអស់ពេលបានថយចុះ 100 ដង - ទាំងអស់ដោយសារតែការប្រើប្រាស់រីករាលដាលនៃការរំពឹងទុក។

មកដល់ពេលនេះ ថ្នាំងម៉ាស៊ីនមេ SQL ភាគច្រើនត្រូវបានបញ្ឈប់ហើយ ផលិតផលថ្មីកំពុងត្រូវបានបង្កើតដោយប្រើ C*One ប៉ុណ្ណោះ។ យើងបានកែសម្រួល C*One ដើម្បីធ្វើការនៅក្នុងពពករបស់យើង។ ពពកតែមួយដែលធ្វើឱ្យវាអាចបង្កើនល្បឿននៃការដាក់ពង្រាយក្រុមថ្មី សម្រួលការកំណត់រចនាសម្ព័ន្ធ និងប្រតិបត្តិការដោយស្វ័យប្រវត្តិ។ បើ​គ្មាន​កូដ​ប្រភព​ទេ ការ​ធ្វើ​បែប​នេះ​នឹង​មាន​ការ​លំបាក និង​ពិបាក​ជាង។

ឥឡូវនេះយើងកំពុងធ្វើការលើការផ្ទេរកន្លែងផ្ទុកផ្សេងទៀតរបស់យើងទៅពពក ប៉ុន្តែនោះជារឿងខុសគ្នាទាំងស្រុង។

ប្រភព: www.habr.com