Google Cloud Spanner៖ ល្អ អាក្រក់ និងអាក្រក់

ជំរាបសួរអ្នកស្រុក Khabrovsk ។ ជាធម្មតា យើងបន្តចែករំលែកសម្ភារៈដែលគួរឱ្យចាប់អារម្មណ៍ មុនពេលចាប់ផ្តើមវគ្គសិក្សាថ្មី។ ថ្ងៃនេះ ជាពិសេសសម្រាប់អ្នក យើងបានបោះពុម្ពអត្ថបទមួយអំពី Google Cloud Spanner ដើម្បីស្របពេលជាមួយនឹងការចាប់ផ្តើមវគ្គសិក្សា "AWS សម្រាប់អ្នកអភិវឌ្ឍន៍".

ដើមឡើយបានចុះផ្សាយក្នុង ប្លុក Lightspeed HQ.

ក្នុងនាមជាក្រុមហ៊ុនដែលផ្តល់ជូននូវដំណោះស្រាយម៉ាស៊ីនឆូតកាតដែលមានមូលដ្ឋានលើពពកជាច្រើនដល់អ្នកលក់រាយ ភោជនីយដ្ឋាន និងអ្នកលក់អនឡាញជុំវិញពិភពលោក Lightspeed ប្រើប្រាស់ប្រភេទផ្សេងគ្នានៃវេទិកាមូលដ្ឋានទិន្នន័យសម្រាប់ករណីប្រើប្រាស់ប្រតិបត្តិការ វិភាគ និងស្វែងរកផ្សេងៗគ្នា។ វេទិកាមូលដ្ឋានទិន្នន័យទាំងនេះនីមួយៗមានចំណុចខ្លាំង និងចំណុចខ្សោយរៀងៗខ្លួន។ ដូច្នេះហើយ នៅពេលដែល Google ណែនាំ Cloud Spanner ទៅកាន់ទីផ្សារ លក្ខណៈពិសេសដែលមិនអាចមើលឃើញនៅក្នុងពិភពនៃមូលដ្ឋានទិន្នន័យទំនាក់ទំនង ដូចជាការធ្វើមាត្រដ្ឋានផ្ដេកស្ទើរតែគ្មានដែនកំណត់ និងកិច្ចព្រមព្រៀងកម្រិតសេវាកម្ម 99,999% (SLA)។ - យើងមិនអាចខកខានឱកាសដើម្បីទទួលបានដៃរបស់យើង!

ដើម្បីផ្តល់នូវទិដ្ឋភាពទូទៅដ៏ទូលំទូលាយនៃបទពិសោធន៍របស់យើងជាមួយ Cloud Spanner ក៏ដូចជាលក្ខណៈវិនិច្ឆ័យវាយតម្លៃដែលយើងបានប្រើ យើងនឹងគ្របដណ្តប់លើប្រធានបទខាងក្រោម៖

1. លក្ខណៈវិនិច្ឆ័យវាយតម្លៃរបស់យើង។
2. Cloud Spanner និយាយដោយសង្ខេប
3. ការវាយតម្លៃរបស់យើង។
4. ការរកឃើញរបស់យើង

1. លក្ខណៈវិនិច្ឆ័យវាយតម្លៃរបស់យើង។

មុននឹងចូលទៅក្នុងភាពជាក់លាក់របស់ Cloud Spanner ភាពស្រដៀងគ្នា និងភាពខុសគ្នារបស់វាជាមួយនឹងដំណោះស្រាយផ្សេងទៀតនៅលើទីផ្សារ សូមនិយាយអំពីករណីប្រើប្រាស់សំខាន់ៗដែលយើងមាននៅក្នុងចិត្តនៅពេលពិចារណាកន្លែងដែលត្រូវដាក់ឱ្យប្រើប្រាស់ Cloud Spanner នៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធរបស់យើង៖

• ជាការជំនួសសម្រាប់ដំណោះស្រាយមូលដ្ឋានទិន្នន័យ SQL ប្រពៃណី (លេចធ្លោ)
• របៀបដោះស្រាយ OLTP ជាមួយនឹងការគាំទ្រ OLAP

ចំណាំ: សម្រាប់ភាពសាមញ្ញ និងភាពងាយស្រួលនៃការប្រៀបធៀប អត្ថបទនេះប្រៀបធៀប Cloud Spanner ជាមួយនឹងបំរែបំរួល MySQL នៃគ្រួសារដំណោះស្រាយ GCP Cloud SQL និង Amazon AWS RDS ។

ការប្រើប្រាស់ Cloud Spanner ជាការជំនួសសម្រាប់ដំណោះស្រាយមូលដ្ឋានទិន្នន័យ SQL ប្រពៃណី

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

ជាឧទាហរណ៍ ជំហានដំបូងដែលត្រូវអនុវត្តគឺត្រូវមើលប៉ារ៉ាម៉ែត្រមូលដ្ឋានទិន្នន័យដែលទាក់ទងនឹងការអនុវត្តផ្សេងៗ ហើយកែសម្រួលពួកវាឱ្យត្រូវគ្នានឹងគំរូករណីប្រើប្រាស់កម្មវិធីល្អបំផុត។ ប្រសិនបើវាមិនគ្រប់គ្រាន់ទេ អ្នកអាចជ្រើសរើសធ្វើមាត្រដ្ឋានមូលដ្ឋានទិន្នន័យបញ្ឈរ ឬផ្ដេក។

ការធ្វើមាត្រដ្ឋានបញ្ឈរកម្មវិធីរួមបញ្ចូលការធ្វើឱ្យប្រសើរឡើងនូវឧទាហរណ៍ម៉ាស៊ីនមេ ជាធម្មតាដោយការបន្ថែមប្រព័ន្ធដំណើរការ/ស្នូលបន្ថែម RAM កាន់តែច្រើន ការផ្ទុកលឿនជាងមុន។ ប្រព័ន្ធមូលដ្ឋានទិន្នន័យទំនាក់ទំនង (ដែលប្រើវិធីសាស្រ្តពហុខ្សែ) ដូចជាមាត្រដ្ឋាន MySQL ល្អបញ្ឈរ។

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

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

ម៉្យាងវិញទៀត ដោយសារធម្មជាតិរបស់វា Cloud Spanner អាចធ្វើមាត្រដ្ឋានផ្ដេកបានយ៉ាងងាយស្រួលដោយមានអន្តរាគមន៍តិចតួចបំផុត។

លក្ខណៈពិសេសពេញលេញ DBMS ជាសេវាកម្ម ត្រូវតែវាយតម្លៃពីមុំផ្សេងៗគ្នា។ ជាមូលដ្ឋាន យើងបានយក DBMS ដែលពេញនិយមបំផុតនៅក្នុងពពក - សម្រាប់ Google, GCP Cloud SQL និងសម្រាប់ Amazon, AWS RDS ។ នៅក្នុងការវាយតម្លៃរបស់យើង យើងបានផ្តោតលើប្រភេទដូចខាងក្រោមៈ

• ការគូសផែនទីលក្ខណៈពិសេស៖ វិសាលភាព SQL, DDL, DML; បណ្ណាល័យការតភ្ជាប់/ឧបករណ៍ភ្ជាប់ ការគាំទ្រប្រតិបត្តិការ និងដូច្នេះនៅលើ។
• ការគាំទ្រការអភិវឌ្ឍន៍៖ ការអភិវឌ្ឍន៍ និងការធ្វើតេស្តងាយស្រួល។
• ការគាំទ្រផ្នែករដ្ឋបាល៖ ការគ្រប់គ្រងវត្ថុ - ឧទាហរណ៍ ការធ្វើមាត្រដ្ឋានឡើងលើ/ចុះក្រោម និងការធ្វើឱ្យប្រសើរឡើងនូវករណី។ SLA ការបម្រុងទុកនិងការងើបឡើងវិញ; ការគ្រប់គ្រងសុវត្ថិភាព / ការចូលប្រើ។

ការប្រើប្រាស់ Cloud Spanner ជាដំណោះស្រាយ OLTP ដែលបានបើកដំណើរការ OLAP

ខណៈពេលដែល Google មិនបានអះអាងយ៉ាងច្បាស់ថា Cloud Spanner ត្រូវបានរចនាឡើងសម្រាប់ដំណើរការវិភាគ វាចែករំលែកលក្ខណៈមួយចំនួនជាមួយម៉ាស៊ីនផ្សេងទៀតដូចជា Apache Impala & Kudu និង YugaByte ដែលត្រូវបានរចនាឡើងសម្រាប់បន្ទុកការងាររបស់ OLAP ។

ទោះបីជាមានឱកាសតិចតួចដែល Cloud Spanner រួមបញ្ចូលម៉ាស៊ីន HTAP (ដំណើរការប្រតិបត្តិការ/ការវិភាគកូនកាត់) ជាមួយនឹងសំណុំមុខងារ OLAP ដែលអាចប្រើបាន (ច្រើន ឬតិចជាងនេះ) យើងគិតថាវាសមនឹងទទួលបានការយកចិត្តទុកដាក់របស់យើង។

ជាមួយនឹងគំនិតនេះ យើងបានពិនិត្យមើលប្រភេទដូចខាងក្រោមៈ

• ការផ្ទុកទិន្នន័យ លិបិក្រម និងការគាំទ្រការបែងចែក
• ការអនុវត្តសំណួរ និង DML

2. Cloud Spanner សង្ខេប

Google Spanner គឺជាប្រព័ន្ធគ្រប់គ្រងមូលដ្ឋានទិន្នន័យដែលមានទំនាក់ទំនងជាក្រុម (RDBMS) ដែល Google ប្រើប្រាស់សម្រាប់សេវាកម្មផ្ទាល់ខ្លួនមួយចំនួន។ Google បានធ្វើឱ្យវាអាចប្រើបានជាទូទៅសម្រាប់អ្នកប្រើប្រាស់ Google Cloud Platform នៅដើមឆ្នាំ 2017 ។

នេះគឺជាលក្ខណៈមួយចំនួននៃ Cloud Spanner៖

• ចង្កោម RDBMS ដែលអាចធ្វើមាត្រដ្ឋានបានខ្ពស់៖ ប្រើការធ្វើសមកាលកម្មពេលវេលាផ្នែករឹង ដើម្បីធានាបាននូវភាពស៊ីសង្វាក់គ្នានៃទិន្នន័យ។
• ការគាំទ្រប្រតិបត្តិការឆ្លងតារាង៖ ប្រតិបត្តិការអាចលាតសន្ធឹងតារាងច្រើន - មិនចាំបាច់កំណត់ចំពោះតារាងតែមួយទេ (មិនដូច Apache HBase ឬ Apache Kudu)។
• តារាងដែលមានមូលដ្ឋានលើកូនសោចម្បង៖ តារាងទាំងអស់ត្រូវតែមានសោបឋមដែលបានប្រកាស (PC) ដែលអាចមានជួរឈរជាច្រើននៅក្នុងតារាង។ ទិន្នន័យតារាងត្រូវបានរក្សាទុកក្នុងលំដាប់កុំព្យូទ័រ ដែលធ្វើឱ្យវាមានប្រសិទ្ធភាព និងរហ័សសម្រាប់ការស្វែងរកកុំព្យូទ័រ។ ដូចប្រព័ន្ធដែលមានមូលដ្ឋានលើកុំព្យូទ័រផ្សេងទៀត ការអនុវត្តត្រូវតែយកគំរូតាមករណីប្រើប្រាស់ដែលបានរចនាជាមុនក្នុងចិត្តដើម្បីសម្រេចបាន។ ដំណើរការល្អបំផុត.
• តារាងឆ្នូត៖ តារាងអាចមានភាពអាស្រ័យទៅលើគ្នាទៅវិញទៅមក។ ជួរ​ដេក​ក្នុង​តារាង​កូន​អាច​ត្រូវ​បាន​ផ្គូផ្គង​នឹង​ជួរ​ដេក​ក្នុង​តារាង​មេ។ វិធីសាស្រ្តនេះបង្កើនល្បឿននៃការស្វែងរកទំនាក់ទំនងដែលអាចត្រូវបានកំណត់អត្តសញ្ញាណក្នុងដំណាក់កាលគំរូទិន្នន័យ ដូចជាការស្វែងរកអតិថិជនរួមគ្នា និងវិក្កយបត្ររបស់ពួកគេ។
• សន្ទស្សន៍៖ Cloud Spanner គាំទ្រសន្ទស្សន៍បន្ទាប់បន្សំ។ លិបិក្រមមានជួរឈរដែលបានធ្វើលិបិក្រម និងជួរឈរកុំព្យូទ័រទាំងអស់។ ប្រសិនបើចង់បាន លិបិក្រមក៏អាចមានជួរឈរដែលមិនមានលិបិក្រមផ្សេងទៀតផងដែរ។ លិបិក្រមអាចត្រូវបានជ្រៀតជ្រែកជាមួយតារាងមេ ដើម្បីបង្កើនល្បឿនសំណួរ។ ការរឹតបន្តឹងជាច្រើនអនុវត្តចំពោះលិបិក្រម ដូចជាចំនួនអតិបរមានៃជួរឈរបន្ថែមដែលរក្សាទុកក្នុងលិបិក្រម។ ដូចគ្នានេះផងដែរ សំណួរតាមរយៈលិបិក្រមអាចមិនត្រង់ដូចនៅក្នុង RDBMSs ផ្សេងទៀត។

“Cloud Spanner ជ្រើសរើសសន្ទស្សន៍ដោយស្វ័យប្រវត្តិតែក្នុងករណីកម្រប៉ុណ្ណោះ។ ជាពិសេស Cloud Spanner មិនជ្រើសរើសសន្ទស្សន៍បន្ទាប់បន្សំដោយស្វ័យប្រវត្តិទេ ប្រសិនបើសំណួរស្នើសុំជួរឈរណាមួយដែលមិនត្រូវបានរក្សាទុកនៅក្នុង សន្ទស្សន៍ "។

• កិច្ចព្រមព្រៀងកម្រិតសេវាកម្ម (SLA): ការដាក់ពង្រាយនៅក្នុងតំបន់មួយជាមួយនឹង SLA នៃ 99,99%; ការដាក់ពង្រាយពហុតំបន់ជាមួយនឹង 99,999% SLA ។ ខណៈពេលដែល SLA ខ្លួនវាគ្រាន់តែជាកិច្ចព្រមព្រៀងមួយ និងមិនមែនជាការធានានៃប្រភេទណាមួយនោះទេ ខ្ញុំជឿថាមនុស្សនៅ Google មានទិន្នន័យពិបាកមួយចំនួនដើម្បីធ្វើការទាមទារខ្លាំងបែបនេះ។ (សម្រាប់ជាឯកសារយោង 99,999% មានន័យថា 26,3 វិនាទីនៃភាពមិនមានសេវាកម្មក្នុងមួយខែ។ )
• ច្រើនទៀត៖ https://cloud.google.com/spanner/

ចំណាំ: គម្រោង Apache Tephra បន្ថែមការគាំទ្រប្រតិបត្តិការប្រសើរឡើងដល់ Apache HBase (ឥឡូវនេះក៏ត្រូវបានអនុវត្តនៅក្នុង Apache Phoenix ជាបេតា)។

3. ការវាយតម្លៃរបស់យើង។

ដូច្នេះ យើងទាំងអស់គ្នាបានអានការអះអាងរបស់ Google អំពីអត្ថប្រយោជន៍នៃ Cloud Spanner - ការធ្វើមាត្រដ្ឋានផ្ដេកស្ទើរតែគ្មានដែនកំណត់ ខណៈពេលដែលរក្សាបាននូវភាពស៊ីសង្វាក់គ្នាខ្ពស់ និង SLA ខ្ពស់ណាស់។ ទោះបីជាតម្រូវការទាំងនេះស្ថិតក្នុងកាលៈទេសៈណាក៏ដោយ ការលំបាកក្នុងការសម្រេចបាន គោលដៅរបស់យើងគឺមិនមែនដើម្បីបដិសេធពួកគេនោះទេ។ ផ្ទុយទៅវិញ ចូរយើងផ្តោតលើរឿងផ្សេងទៀតដែលអ្នកប្រើប្រាស់មូលដ្ឋានទិន្នន័យភាគច្រើនយកចិត្តទុកដាក់៖ ភាពស្មើគ្នា និងលទ្ធភាពប្រើប្រាស់។

យើងបានវាយតម្លៃ Cloud Spanner ជាការជំនួសសម្រាប់ Sharded MySQL

Google Cloud SQL និង Amazon AWS RDS ដែលជា OLTP DBMSs ដ៏ពេញនិយមបំផុតពីរនៅក្នុងទីផ្សារពពក មានសំណុំលក្ខណៈពិសេសច្រើន។ ទោះយ៉ាងណាក៏ដោយ ដើម្បីធ្វើមាត្រដ្ឋានមូលដ្ឋានទិន្នន័យទាំងនេះលើសពីទំហំនៃថ្នាំងតែមួយ អ្នកត្រូវអនុវត្តការបែងចែកកម្មវិធី។ វិធីសាស្រ្តនេះបង្កើតភាពស្មុគស្មាញបន្ថែមសម្រាប់ទាំងកម្មវិធី និងការគ្រប់គ្រង។ យើងបានក្រឡេកមើលពីរបៀបដែល Spanner សមនឹងចូលទៅក្នុងសេណារីយ៉ូនៃការបញ្ចូលគ្នានូវ shards ជាច្រើនចូលទៅក្នុង instance តែមួយ និងអ្វីដែលលក្ខណៈពិសេស (ប្រសិនបើមាន) អាចនឹងត្រូវលះបង់។

ការគាំទ្រ SQL, DML និង DDL ក៏ដូចជាឧបករណ៍ភ្ជាប់ និងបណ្ណាល័យ?

ជាដំបូង នៅពេលចាប់ផ្តើមជាមួយមូលដ្ឋានទិន្នន័យណាមួយ អ្នកត្រូវបង្កើតគំរូទិន្នន័យ។ ប្រសិនបើអ្នកគិតថាអ្នកអាចភ្ជាប់ JDBC Spanner ទៅឧបករណ៍ SQL ដែលអ្នកចូលចិត្ត អ្នកនឹងឃើញថាអ្នកអាចសួរទិន្នន័យរបស់អ្នកជាមួយវាបាន ប៉ុន្តែអ្នកមិនអាចប្រើវាដើម្បីបង្កើតតារាង ឬកែប្រែ (DDL) ឬការបញ្ចូល/ធ្វើបច្ចុប្បន្នភាព/លុបណាមួយឡើយ។ ប្រតិបត្តិការ (DML) ។ JDBC ផ្លូវការរបស់ Google មិនគាំទ្រទាំងពីរនេះទេ។

msgstr "កម្មវិធី​បញ្ជា​បច្ចុប្បន្ន​មិន​គាំទ្រ​សេចក្តីថ្លែងការណ៍ DML ឬ DDL ។"
ឯកសារ Spanner

ស្ថានភាពមិនប្រសើរជាងជាមួយកុងសូល GCP ទេ - អ្នកអាចផ្ញើបានតែសំណួរ SELECT ប៉ុណ្ណោះ។ សំណាងល្អមានកម្មវិធីបញ្ជា JDBC ដែលមានការគាំទ្រសម្រាប់ DML និង DDL ពីសហគមន៍ រួមទាំងប្រតិបត្តិការផងដែរ។ github.com/olavloite/spanner-jdbc. ខណៈ​ពេល​ដែល​កម្មវិធី​បញ្ជា​នេះ​មាន​ប្រយោជន៍​ខ្លាំង កង្វះ​កម្មវិធី​បញ្ជា JDBC ផ្ទាល់​របស់ Google គឺ​គួរ​ឱ្យ​ភ្ញាក់​ផ្អើល។ ជាសំណាងល្អ Google ផ្តល់នូវការគាំទ្រយ៉ាងទូលំទូលាយសម្រាប់បណ្ណាល័យអតិថិជន (ផ្អែកលើ gRPC): C#, Go, Java, node.js, PHP, Python និង Ruby ។

ការប្រើប្រាស់ស្ទើរតែចាំបាច់នៃ APIs ផ្ទាល់ខ្លួនរបស់ Cloud Spanner (ដោយសារតែកង្វះ DDL និង DML នៅក្នុង JDBC) បណ្តាលឱ្យមានដែនកំណត់មួយចំនួនសម្រាប់ផ្នែកកូដដែលពាក់ព័ន្ធដូចជា បណ្តុំការតភ្ជាប់ ឬក្របខ័ណ្ឌចងមូលដ្ឋានទិន្នន័យ (ឧ. Spring MVC) ។ ជាធម្មតា នៅពេលប្រើ JDBC អ្នកមានសេរីភាពក្នុងការជ្រើសរើសក្រុមតភ្ជាប់ដែលអ្នកចូលចិត្ត (ឧ. HikariCP, DBCP, C3PO ។ល។) ដែលត្រូវបានសាកល្បង និងដំណើរការល្អ។ ក្នុងករណី Spanner APIs ផ្ទាល់ខ្លួន យើងត្រូវពឹងផ្អែកលើ frameworks/binding pools/sessions ដែលយើងបានបង្កើតខ្លួនឯង។

ការរចនាស្នូលសំខាន់ (PC) អនុញ្ញាតឱ្យ Cloud Spanner មានល្បឿនលឿននៅពេលចូលប្រើទិន្នន័យតាមរយៈកុំព្យូទ័រ ប៉ុន្តែក៏ណែនាំបញ្ហាសំណួរមួយចំនួនផងដែរ។

• អ្នកមិនអាចធ្វើបច្ចុប្បន្នភាពតម្លៃសោចម្បងបានទេ។ ដំបូងអ្នកត្រូវតែលុបធាតុចេញពីកុំព្យូទ័រដើម ហើយបញ្ចូលវាឡើងវិញជាមួយនឹងតម្លៃថ្មី។ (វា​ស្រដៀង​ទៅ​នឹង​ម៉ាស៊ីន​មូលដ្ឋាន​ទិន្នន័យ/ម៉ាស៊ីន​ផ្ទុក​ដែល​តម្រង់​ទិស​កុំព្យូទ័រ​ផ្សេង​ទៀត​។ )
• រាល់ UPDATE និង DELETE statements ត្រូវតែបញ្ជាក់ PC នៅក្នុង WHERE ដូច្នេះវាមិនអាចទទេបានទេ DELETE all statements - វាត្រូវតែមាន subquery ជានិច្ច ឧទាហរណ៍៖ UPDATE xxx WHERE id IN (SELECT id ពី table1)
• កង្វះជម្រើសបង្កើនដោយស្វ័យប្រវត្តិ ឬអ្វីស្រដៀងគ្នាដែលកំណត់លំដាប់សម្រាប់វាលកុំព្យូទ័រ។ ដើម្បីឱ្យវាដំណើរការ តម្លៃដែលត្រូវគ្នាត្រូវតែបង្កើតនៅផ្នែកខាងកម្មវិធី។

សន្ទស្សន៍បន្ទាប់បន្សំ?

Google Cloud Spanner មានការគាំទ្រដែលភ្ជាប់មកជាមួយសម្រាប់សន្ទស្សន៍បន្ទាប់បន្សំ។ នេះ​គឺ​ជា​មុខងារ​ដ៏​ល្អ​មួយ​ដែល​មិន​តែងតែ​មាន​នៅ​ក្នុង​បច្ចេកវិទ្យា​ផ្សេង​ទៀត​ទេ។ បច្ចុប្បន្ន Apache Kudu មិនគាំទ្រលិបិក្រមបន្ទាប់បន្សំទាល់តែសោះ ហើយ Apache HBase មិនគាំទ្រលិបិក្រមដោយផ្ទាល់ទេ ប៉ុន្តែអាចបន្ថែមពួកវាតាមរយៈ Apache Phoenix ។

លិបិក្រមនៅក្នុង Kudu និង HBase អាចត្រូវបានយកគំរូតាមតារាងដាច់ដោយឡែកមួយដែលមានសមាសភាពផ្សេងគ្នានៃសោចម្បង ប៉ុន្តែអាតូមិកនៃប្រតិបត្តិការដែលបានអនុវត្តនៅលើតារាងមេ និងតារាងលិបិក្រមដែលពាក់ព័ន្ធត្រូវតែធ្វើឡើងនៅកម្រិតកម្មវិធី ហើយមិនសំខាន់ក្នុងការអនុវត្តត្រឹមត្រូវ។

ដូចដែលបានរៀបរាប់នៅក្នុងការពិនិត្យឡើងវិញ Cloud Spanner សន្ទស្សន៍របស់វាអាចខុសពីសន្ទស្សន៍ MySQL ។ ដូច្នេះ ការយកចិត្តទុកដាក់ពិសេសគួរតែត្រូវបានគេយកនៅពេលបង្កើតសំណួរ និងទម្រង់ដើម្បីធានាថាសន្ទស្សន៍ត្រឹមត្រូវត្រូវបានប្រើនៅកន្លែងដែលត្រូវការ។

តំណាង?

វត្ថុដ៏ពេញនិយម និងមានប្រយោជន៍នៅក្នុងមូលដ្ឋានទិន្នន័យគឺទិដ្ឋភាព។ ពួកគេអាចមានប្រយោជន៍សម្រាប់ករណីប្រើប្រាស់មួយចំនួនធំ; ចំណូលចិត្តពីររបស់ខ្ញុំគឺស្រទាប់អរូបីតក្កវិជ្ជា និងស្រទាប់សុវត្ថិភាព។ ជាអកុសល Cloud Spanner មិនគាំទ្រការមើលទេ។ ទោះជាយ៉ាងណាក៏ដោយ នេះកំណត់យើងតែផ្នែកខ្លះប៉ុណ្ណោះ ពីព្រោះមិនមានព័ត៌មានលម្អិតសម្រាប់ការអនុញ្ញាតចូលប្រើនៅកម្រិតជួរឈរ ដែលការមើលអាចជាដំណោះស្រាយដែលអាចសម្រេចបាន។

សូមមើលឯកសារ Cloud Spanner សម្រាប់ផ្នែកដែលលម្អិតអំពីកូតា និងការរឹតបន្តឹង (spanner / កូតា) មានលក្ខណៈពិសេសមួយដែលអាចមានបញ្ហាសម្រាប់កម្មវិធីមួយចំនួន៖ Cloud Spanner ចេញពីប្រអប់មានដែនកំណត់អតិបរមា 100 មូលដ្ឋានទិន្នន័យក្នុងមួយឧទាហរណ៍។ ជាក់ស្តែង នេះអាចជាឧបសគ្គដ៏សំខាន់សម្រាប់មូលដ្ឋានទិន្នន័យដែលត្រូវបានរចនាឡើងដើម្បីធ្វើមាត្រដ្ឋានដល់ជាង 100 មូលដ្ឋានទិន្នន័យ។ ជាសំណាងល្អ បន្ទាប់ពីបាននិយាយជាមួយអ្នកតំណាងបច្ចេកទេស Google របស់យើង យើងបានរកឃើញថាដែនកំណត់នេះអាចត្រូវបានកើនឡើងដល់ស្ទើរតែគ្រប់តម្លៃតាមរយៈ Google Support។

គាំទ្រការអភិវឌ្ឍន៍?

Cloud Spanner ផ្តល់នូវការគាំទ្រភាសាសរសេរកម្មវិធីសមរម្យសម្រាប់ធ្វើការជាមួយ API របស់វា។ បណ្ណាល័យដែលគាំទ្រជាផ្លូវការគឺស្ថិតនៅក្នុងផ្នែកនៃ C#, Go, Java, node.js, PHP, Python និង Ruby ។ ឯកសារនេះគឺលម្អិតណាស់ ប៉ុន្តែដូចទៅនឹងបច្ចេកវិទ្យាទំនើបផ្សេងទៀតដែរ សហគមន៍គឺតូចណាស់បើប្រៀបធៀបទៅនឹងបច្ចេកវិទ្យាមូលដ្ឋានទិន្នន័យដ៏ពេញនិយមបំផុត ដែលអាចនាំឱ្យចំណាយពេលវេលាច្រើនក្នុងការដោះស្រាយបញ្ហា ឬបញ្ហានៃការប្រើប្រាស់ធម្មតា។

ចុះ​ចំណែក​ការ​គាំទ្រ​ដល់​ការ​អភិវឌ្ឍ​មូលដ្ឋាន​វិញ?

យើង​មិន​បាន​រក​ឃើញ​វិធី​ក្នុង​ការ​បង្កើត Cloud Spanner instance នៅ​ក្នុង​បរិវេណ​នោះ​ទេ។ អ្វីដែលជិតបំផុតដែលយើងទទួលបានគឺរូបភាព Docker ។ កន្លាតDBដែលមានលក្ខណៈស្រដៀងគ្នាក្នុងគោលការណ៍ ប៉ុន្តែខុសគ្នាខ្លាំងនៅក្នុងការអនុវត្ត។ ឧទាហរណ៍ CockroachDB អាចប្រើ PostgreSQL JDBC ។ ដោយសារបរិយាកាសអភិវឌ្ឍន៍គួរតែនៅជិតបរិយាកាសផលិតកម្មតាមដែលអាចធ្វើទៅបាន Cloud Spanner គឺមិនសមស្របទេព្រោះវាត្រូវតែពឹងផ្អែកលើឧទាហរណ៍ Spanner ពេញលេញ។ ដើម្បីសន្សំការចំណាយ អ្នកអាចជ្រើសរើសឧទាហរណ៍តំបន់តែមួយ។

ការគាំទ្រផ្នែករដ្ឋបាល?

ការបង្កើតឧទាហរណ៍ Cloud Spanner គឺសាមញ្ញណាស់។ អ្នកគ្រាន់តែត្រូវជ្រើសរើសរវាងការបង្កើតពហុតំបន់ ឬឧទាហរណ៍តំបន់តែមួយ បញ្ជាក់តំបន់ និងចំនួនថ្នាំង។ ក្នុងរយៈពេលតិចជាងមួយនាទី គំរូរបស់អ្នកនឹងដំណើរការ។

រង្វាស់ជាមូលដ្ឋានជាច្រើនអាចចូលប្រើដោយផ្ទាល់ពីទំព័រ Spanner នៅក្នុង Google Console ។ ទិដ្ឋភាពលម្អិតបន្ថែមទៀតអាចរកបានតាមរយៈ Stackdriver ដែលអ្នកក៏អាចកំណត់កម្រិតម៉ែត្រ និងគោលការណ៍ជូនដំណឹងផងដែរ។

ចូលប្រើធនធាន?

MySQL ផ្តល់នូវការកំណត់យ៉ាងទូលំទូលាយ និងលម្អិតសម្រាប់ការអនុញ្ញាត/តួនាទីរបស់អ្នកប្រើប្រាស់។ អ្នក​អាច​កំណត់​រចនាសម្ព័ន្ធ​ចូល​ប្រើ​តារាង​ជាក់លាក់​បាន​យ៉ាង​ងាយ​ស្រួល ឬ​សូម្បី​តែ​សំណុំ​រង​នៃ​ជួរ​ឈរ​របស់​វា​ប៉ុណ្ណោះ។ Cloud Spanner ប្រើប្រាស់ឧបករណ៍ Identity & Access Management (IAM) របស់ Google ដែលអនុញ្ញាតឱ្យអ្នកកំណត់គោលការណ៍ និងការអនុញ្ញាតក្នុងកម្រិតខ្ពស់បំផុត។ ជម្រើសលម្អិតបំផុតគឺដំណោះស្រាយកម្រិតមូលដ្ឋានទិន្នន័យ ដែលមិនសមនឹងករណីប្រើប្រាស់ផលិតកម្មភាគច្រើន។ ការកំណត់នេះបង្ខំអ្នកឱ្យបន្ថែមវិធានការសុវត្ថិភាពបន្ថែមទៅក្នុងកូដ ហេដ្ឋារចនាសម្ព័ន្ធ ឬទាំងពីរដើម្បីការពារការប្រើប្រាស់ធនធាន Spanner ដោយគ្មានការអនុញ្ញាត។

បម្រុងទុក?

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

ដំណើរការសំណួរ?

យើងបានប្រើ Yahoo! ដើម្បីផ្ទុកទិន្នន័យ និងសំណួរសាកល្បង។ Cloud Serving Benchmark។ តារាងខាងក្រោមបង្ហាញពីបន្ទុកការងារ YCSB B ជាមួយនឹងសមាមាត្រសរសេរ 95% ទៅ 5% ។

* ការធ្វើតេស្តផ្ទុកត្រូវបានដំណើរការនៅលើ n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB memory) ហើយការសាកល្បងនេះមិនដែលមានបញ្ហាក្នុងការសាកល្បងនោះទេ។
** ចំនួនអតិបរិមានៃខ្សែស្រឡាយក្នុងឧទាហរណ៍ YCSB តែមួយគឺ 400។ ការធ្វើតេស្ត YCSB សរុបចំនួនប្រាំមួយត្រូវតែដំណើរការដើម្បីទទួលបានសរុបចំនួន 2400 ខ្សែស្រឡាយ។

ក្រឡេកមើលលទ្ធផលគោល ជាពិសេសការរួមផ្សំនៃការផ្ទុក CPU និង TPS យើងអាចមើលឃើញយ៉ាងច្បាស់ថា Cloud Spanner ធ្វើមាត្រដ្ឋានបានយ៉ាងល្អ។ បន្ទុកធ្ងន់ដែលបង្កើតឡើងដោយចំនួនដ៏ច្រើននៃខ្សែស្រឡាយត្រូវបានទូទាត់ដោយចំនួនដ៏ច្រើននៃថ្នាំងនៅក្នុងចង្កោម Cloud Spanner ។ ខណៈពេលដែលភាពយឺតយ៉ាវមើលទៅខ្ពស់ណាស់ ជាពិសេសនៅពេលដំណើរការជាមួយ 2400 threads ការធ្វើតេស្តម្តងទៀតជាមួយនឹង 6 ករណីតូចៗនៃម៉ាស៊ីនគណនាប្រហែលជាចាំបាច់ដើម្បីទទួលបានលេខត្រឹមត្រូវជាងមុន។ វត្ថុនីមួយៗនឹងដំណើរការការធ្វើតេស្ត YCSB មួយជំនួសឱ្យវត្ថុ CE ដ៏ធំមួយដែលមានការធ្វើតេស្តប៉ារ៉ាឡែលចំនួន 6 ។ វិធីនេះ វានឹងកាន់តែងាយស្រួលក្នុងការបែងចែករវាងភាពយឺតយ៉ាវនៃសំណើរបស់ Cloud Spanner និងភាពយឺតយ៉ាវដែលត្រូវបានបន្ថែមដោយការភ្ជាប់បណ្តាញរវាង Cloud Spanner និង CE instance ដែលដំណើរការសាកល្បង។

តើ Cloud Spanner ដំណើរការជា OLAP យ៉ាងដូចម្តេច?

ការបែងចែក?

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

Cloud Spanner មិនគាំទ្រភាគថាសបែបនេះទេ។ វាបែងចែកទិន្នន័យខាងក្នុងទៅជាអ្វីដែលគេហៅថា បំបែក-s ផ្អែកលើជួរគន្លឹះចម្បង។ ការបែងចែកត្រូវបានអនុវត្តដោយស្វ័យប្រវត្តិដើម្បីធ្វើឱ្យមានតុល្យភាពបន្ទុកនៅក្នុងចង្កោម Cloud Spanner ។ មុខងារដ៏មានប្រយោជន៍របស់ Cloud Spanner គឺការបំបែកបន្ទុកមូលដ្ឋានរបស់តារាងមេ (តារាងដែលមិនមានការជ្រៀតជ្រែកជាមួយផ្សេងទៀត)។ Spanner រកឃើញដោយស្វ័យប្រវត្តិថាតើវាមាន បំបែក ទិន្នន័យដែលត្រូវបានអានញឹកញាប់ជាងទិន្នន័យនៅក្នុងអ្នកដទៃ បំបែក-ah, ហើយអាចសម្រេចចិត្តលើការបំបែកបន្ថែមទៀត។ វិធីនេះ ថ្នាំងកាន់តែច្រើនអាចពាក់ព័ន្ធនឹងការស្នើសុំ ដែលបង្កើនប្រសិទ្ធភាពផងដែរ។

កំពុងផ្ទុកទិន្នន័យ?

វិធីសាស្ត្រ Cloud Spanner សម្រាប់ទិន្នន័យភាគច្រើនគឺដូចគ្នាទៅនឹងការផ្ទុកធម្មតា។ ដើម្បីសម្រេចបាននូវការអនុវត្តអតិបរមា អ្នកត្រូវអនុវត្តតាមការណែនាំមួយចំនួន រួមមានៈ

• តម្រៀបទិន្នន័យរបស់អ្នកតាមគន្លឹះចម្បង។
• ចែកពួកវាដោយ 10 *ចំនួនថ្នាំង ផ្នែកដាច់ដោយឡែក។
• បង្កើតសំណុំនៃកិច្ចការការងារដែលផ្ទុកទិន្នន័យស្របគ្នា។

ការផ្ទុកទិន្នន័យនេះប្រើប្រាស់ថ្នាំង Cloud Spanner ទាំងអស់។

យើងបានប្រើបន្ទុកការងារ YCSB A ដើម្បីបង្កើតសំណុំទិន្នន័យ 10M ជួរ។

* ការធ្វើតេស្តផ្ទុកត្រូវបានដំណើរការលើម៉ាស៊ីនគណនា n1-standard-32 (32 vCPU, អង្គចងចាំ 120 GB) ហើយការសាកល្បងគឺមិនដែលមានបញ្ហានៅក្នុងការធ្វើតេស្តនោះទេ។
** ការដំឡើងថ្នាំងតែមួយមិនត្រូវបានណែនាំសម្រាប់បន្ទុកផលិតកម្មណាមួយឡើយ។

ដូចដែលបានរៀបរាប់ខាងលើ Cloud Spanner ដំណើរការការបំបែកដោយស្វ័យប្រវត្តិដោយផ្អែកលើបន្ទុករបស់ពួកគេ ដូច្នេះលទ្ធផលនឹងប្រសើរឡើងបន្ទាប់ពីការធ្វើតេស្តម្តងហើយម្តងទៀតជាបន្តបន្ទាប់។ លទ្ធផលដែលបានបង្ហាញនៅទីនេះ គឺជាលទ្ធផលដ៏ល្អបំផុតដែលយើងទទួលបាន។ ក្រឡេកមើលលេខខាងលើ យើងអាចមើលឃើញពីរបៀបដែល Cloud Spanner ធ្វើមាត្រដ្ឋាន (ល្អ) នៅពេលដែលចំនួនថ្នាំងនៅក្នុងចង្កោមកើនឡើង។ លេខដែលលេចធ្លោគឺ latencies ជាមធ្យមទាបបំផុត ដែលផ្ទុយពីលទ្ធផលសម្រាប់បន្ទុកការងារចម្រុះ (95% អាន និង 5% សរសេរ) ដូចដែលបានពិពណ៌នានៅក្នុងផ្នែកខាងលើ។

ធ្វើមាត្រដ្ឋាន?

ការបង្កើន និងបន្ថយចំនួនថ្នាំង Cloud Spanner គឺជាកិច្ចការដោយចុចតែម្តង។ ប្រសិនបើ​អ្នក​ចង់​ផ្ទុក​ទិន្នន័យ​បាន​លឿន អ្នក​អាច​នឹង​ពិចារណា​ពី​ការ​បង្កើន​ឧទាហរណ៍​របស់អ្នក​ដល់​អតិបរមា (ក្នុងករណី​របស់យើង​វា​មាន 25 nodes នៅក្នុងតំបន់ US-EAST) ហើយ​បន្ទាប់មក​កាត់បន្ថយ​ចំនួន​ថ្នាំង​ដែល​មាន​សិទ្ធិ​សម្រាប់​ការផ្ទុក​ធម្មតា​របស់អ្នក​នៅពេលដែល​ទិន្នន័យ​ទាំងអស់​ចូល។ មូលដ្ឋានទិន្នន័យ ដោយយោងទៅលើដែនកំណត់ 2TB/node ។

យើង​ត្រូវ​បាន​គេ​រំលឹក​ពី​កម្រិត​នេះ​សូម្បី​តែ​ជាមួយ​នឹង​មូលដ្ឋាន​ទិន្នន័យ​តូច​ជាង​នេះ​។ បន្ទាប់ពីដំណើរការសាកល្បងជាច្រើនដង មូលដ្ឋានទិន្នន័យរបស់យើងមានទំហំប្រហែល 155 GB ហើយនៅពេលដែលបានបន្ថយទំហំទៅ 1 node instance យើងបានទទួលកំហុសដូចខាងក្រោម៖

យើងអាចធ្វើមាត្រដ្ឋានចុះពី 25 ទៅ 2 ករណី ប៉ុន្តែយើងបានជាប់គាំងនៅថ្នាំងពីរ។

ការបង្កើន និងបន្ថយចំនួនថ្នាំងនៅក្នុងចង្កោម Cloud Spanner អាចត្រូវបានដោយស្វ័យប្រវត្តិដោយប្រើ REST API ។ វាអាចមានប្រយោជន៍ជាពិសេសសម្រាប់កាត់បន្ថយការផ្ទុកប្រព័ន្ធកើនឡើងក្នុងអំឡុងពេលម៉ោងការងារដ៏មមាញឹក។

ការអនុវត្តសំណួរ OLAP?

ដើមឡើយ យើងមានគម្រោងចំណាយពេលវេលាច្រើនក្នុងការវាយតម្លៃ Spanner របស់យើងលើផ្នែកនេះ។ បន្ទាប់ពី SELECT COUNTs ជាច្រើន យើងដឹងភ្លាមៗថាការធ្វើតេស្តនឹងមានរយៈពេលខ្លី ហើយ Spanner នឹងមិនមែនជាម៉ាស៊ីនដែលសមរម្យសម្រាប់ OLAP នោះទេ។ ដោយមិនគិតពីចំនួនថ្នាំងនៅក្នុងចង្កោម ការគ្រាន់តែជ្រើសរើសចំនួនជួរដេកក្នុងតារាងជួរ 10M ចំណាយពេលពី 55 ទៅ 60 វិនាទី។ លើសពីនេះទៀត រាល់សំណួរដែលទាមទារអង្គចងចាំបន្ថែមដើម្បីរក្សាទុកលទ្ធផលកម្រិតមធ្យមបានបរាជ័យជាមួយនឹងកំហុស OOM ។

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

លេខមួយចំនួនសម្រាប់សំណួរ TPC-H អាចរកបាននៅក្នុងអត្ថបទរបស់ Todd Lipcon Nosql-kudu-spanner-slides.html, ស្លាយ 42 និង 43. លេខទាំងនេះគឺស្របនឹងលទ្ធផលរបស់យើងផ្ទាល់ (ជាអកុសល)។

4. ការសន្និដ្ឋានរបស់យើង។

ដោយគិតពីស្ថានភាពបច្ចុប្បន្ននៃលក្ខណៈពិសេសរបស់ Cloud Spanner វាពិបាកក្នុងការស្រមៃថាវាជាការជំនួសដ៏សាមញ្ញសម្រាប់ដំណោះស្រាយ OLTP ដែលមានស្រាប់របស់អ្នក ជាពិសេសនៅពេលដែលតម្រូវការរបស់អ្នកលើសពីវា។ ពេលវេលាដ៏សំខាន់មួយនឹងត្រូវចំណាយក្នុងការកសាងដំណោះស្រាយជុំវិញចំណុចខ្វះខាតរបស់ Cloud Spanner ។

នៅពេលយើងចាប់ផ្តើមវាយតម្លៃ Cloud Spanner យើងរំពឹងថាមុខងារគ្រប់គ្រងរបស់វាមានលក្ខណៈដូចគ្នា ឬយ៉ាងហោចណាស់មិនឆ្ងាយពីដំណោះស្រាយ Google SQL ផ្សេងទៀត។ ប៉ុន្តែ​យើង​មាន​ការ​ភ្ញាក់​ផ្អើល​ដោយ​សារ​កង្វះ​ការ​បម្រុង​ទុក​ពេញលេញ និង​ការ​គ្រប់​គ្រង​កម្រិត​ខ្លាំង​លើ​ការ​ចូល​ប្រើប្រាស់​ធនធាន។ មិននិយាយពីទស្សនៈ គ្មានបរិយាកាសអភិវឌ្ឍន៍ក្នុងស្រុក លំដាប់ដែលមិនគាំទ្រ JDBC ដោយគ្មានការគាំទ្រ DML និង DDL ហើយដូច្នេះនៅលើ។

ដូច្នេះ តើ​អ្នក​ដែល​ត្រូវ​ធ្វើ​មាត្រដ្ឋាន​ទិន្នន័យ​ប្រតិបត្តិការ​ទៅ​ណា? វាហាក់ដូចជាមិនមានដំណោះស្រាយតែមួយនៅលើទីផ្សារដែលសមនឹងករណីប្រើប្រាស់ទាំងអស់។ មានដំណោះស្រាយប្រភពបិទ និងប្រភពបើកចំហជាច្រើន (មួយចំនួនដែលត្រូវបានលើកឡើងនៅក្នុងអត្ថបទនេះ) ដែលនីមួយៗមានភាពខ្លាំង និងចំណុចខ្សោយរបស់ពួកគេ ប៉ុន្តែគ្មាននរណាម្នាក់ក្នុងចំណោមពួកគេផ្តល់ SaaS ជាមួយនឹង 99,999% SLA និងភាពស៊ីសង្វាក់គ្នាខ្ពស់។ ប្រសិនបើ SLA ខ្ពស់គឺជាគោលដៅចម្បងរបស់អ្នក ហើយអ្នកមិនមានទំនោរចង់បង្កើតដំណោះស្រាយពហុពពកផ្ទាល់ខ្លួនទេ Cloud Spanner អាចជាដំណោះស្រាយដែលអ្នកកំពុងស្វែងរក។ ប៉ុន្តែអ្នកគួរតែដឹងពីដែនកំណត់របស់វា។

ដើម្បីឱ្យមានភាពយុត្តិធម៌ Cloud Spanner ទើបតែត្រូវបានចេញផ្សាយជាសាធារណៈនៅនិទាឃរដូវឆ្នាំ 2017 ដូច្នេះវាសមហេតុផលក្នុងការរំពឹងថាការខ្វះខាតបច្ចុប្បន្នមួយចំនួនរបស់វាអាចនឹងបាត់ទៅវិញ (សង្ឃឹមថា) ហើយនៅពេលដែលពួកគេធ្វើ វាអាចជាអ្នកផ្លាស់ប្តូរហ្គេម។ យ៉ាងណាមិញ Cloud Spanner មិនមែនគ្រាន់តែជាគម្រោងចំហៀងសម្រាប់ Google នោះទេ។ Google ប្រើវាជាមូលដ្ឋានសម្រាប់ផលិតផល Google ផ្សេងទៀត។ ហើយនៅពេលដែលថ្មីៗនេះ Google បានជំនួស Megastore នៅក្នុង Google Cloud Storage ជាមួយ Cloud Spanner វាអនុញ្ញាតឱ្យ Google Cloud Storage មានភាពស៊ីសង្វាក់គ្នាយ៉ាងខ្លាំងសម្រាប់បញ្ជីវត្ថុនៅលើមាត្រដ្ឋានសកល (ដែលនៅតែមិនមែនជាករណីសម្រាប់ របស់ក្រុមហ៊ុន Amazon ។ S3).

ដូច្នេះ នៅតែមានសង្ឃឹម... យើងសង្ឃឹម។

អស់ហើយ។ ដូច​អ្នក​និពន្ធ​អត្ថបទ យើង​ក៏​បន្ត​សង្ឃឹម​ដែរ ប៉ុន្តែ​តើ​អ្នក​យល់​យ៉ាង​ណា​ចំពោះ​រឿង​នេះ? សរសេរនៅក្នុងមតិយោបល់

យើងសូមអញ្ជើញអ្នកទាំងអស់គ្នាមកទស្សនារបស់យើង។ webinar ឥតគិតថ្លៃ នៅក្នុងនោះយើងនឹងប្រាប់អ្នកយ៉ាងលម្អិតអំពីវគ្គសិក្សា "AWS សម្រាប់អ្នកអភិវឌ្ឍន៍" ពី OTUS ។

ប្រភព: www.habr.com