នៅលើផ្លូវទៅកាន់មូលដ្ឋានទិន្នន័យដែលគ្មានម៉ាស៊ីនមេ - របៀបនិងមូលហេតុ

សួស្តី​អ្នក​ទាំងអស់គ្នា! ខ្ញុំឈ្មោះ Golov Nikolay ។ ពីមុនខ្ញុំបានធ្វើការនៅ Avito និងគ្រប់គ្រង Data Platform អស់រយៈពេលប្រាំមួយឆ្នាំ ពោលគឺខ្ញុំបានធ្វើការលើ databases ទាំងអស់៖ analytical (Vertica, ClickHouse), streaming និង OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL)។ ក្នុងអំឡុងពេលនេះ ខ្ញុំបានដោះស្រាយជាមួយនឹងមូលដ្ឋានទិន្នន័យមួយចំនួនធំ - ខុសគ្នាខ្លាំង និងមិនធម្មតា ហើយជាមួយនឹងករណីមិនស្តង់ដារនៃការប្រើប្រាស់របស់វា។

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

នៅក្នុងអត្ថបទនេះ ផ្អែកលើរបាយការណ៍របស់ខ្ញុំនៅ ពិធីបុណ្យអនឡាញ RIT++ 2020ខ្ញុំនឹងឆ្លើយសំណួរនេះ។ កំណែវីដេអូនៃរបាយការណ៍មាននៅ YouTube.

មូលដ្ឋានទិន្នន័យដែលគេស្គាល់ជាទូទៅ 2020

វាជាឆ្នាំ 2020 ខ្ញុំបានក្រឡេកមើលជុំវិញ ហើយឃើញមូលដ្ឋានទិន្នន័យបីប្រភេទ។

ប្រភេទទីមួយ - មូលដ្ឋានទិន្នន័យ OLTP បុរាណ៖ PostgreSQL, SQL Server, Oracle, MySQL ។ ពួកគេត្រូវបានសរសេរតាំងពីយូរយារណាស់មកហើយ ប៉ុន្តែនៅតែពាក់ព័ន្ធ ព្រោះវាស៊ាំជាមួយសហគមន៍អ្នកអភិវឌ្ឍន៍។

ប្រភេទទីពីរគឺ មូលដ្ឋានពី "សូន្យ". ពួកគេបានព្យាយាមផ្លាស់ទីឆ្ងាយពីគំរូបុរាណដោយបោះបង់ចោល SQL រចនាសម្ព័ន្ធប្រពៃណី និង ACID ដោយបន្ថែមការបំបែកដែលភ្ជាប់មកជាមួយ និងលក្ខណៈពិសេសដ៏ទាក់ទាញផ្សេងទៀត។ ឧទាហរណ៍នេះគឺជា Cassandra, MongoDB, Redis ឬ Tarantool ។ ដំណោះស្រាយទាំងអស់នេះចង់ផ្តល់ជូនទីផ្សារនូវអ្វីដែលថ្មីជាមូលដ្ឋាន និងបានកាន់កាប់ទីផ្សារពិសេសរបស់ពួកគេ ព្រោះវាប្រែទៅជាងាយស្រួលបំផុតសម្រាប់កិច្ចការជាក់លាក់។ ខ្ញុំនឹងសម្គាល់មូលដ្ឋានទិន្នន័យទាំងនេះដោយប្រើពាក្យឆ័ត្រ NOSQL ។

"សូន្យ" ចប់ហើយ យើងធ្លាប់ប្រើមូលដ្ឋានទិន្នន័យ NOSQL ហើយពិភពលោក តាមទស្សនៈរបស់ខ្ញុំបានបោះជំហានបន្ទាប់ - ទៅ មូលដ្ឋានទិន្នន័យដែលបានគ្រប់គ្រង. មូលដ្ឋានទិន្នន័យទាំងនេះមានស្នូលដូចគ្នានឹងមូលដ្ឋានទិន្នន័យ OLTP បុរាណ ឬ NoSQL ថ្មី។ ប៉ុន្តែពួកគេមិនត្រូវការ DBA និង DevOps ហើយដំណើរការលើផ្នែករឹងដែលបានគ្រប់គ្រងនៅក្នុងពពក។ សម្រាប់អ្នកអភិវឌ្ឍន៍ នេះគ្រាន់តែជា "មូលដ្ឋាន" ដែលដំណើរការនៅកន្លែងណាមួយ ប៉ុន្តែគ្មាននរណាម្នាក់ខ្វល់ពីរបៀបដែលវាត្រូវបានដំឡើងនៅលើម៉ាស៊ីនមេ អ្នកណាកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ និងអ្នកណាធ្វើបច្ចុប្បន្នភាពវា។

ឧទាហរណ៍នៃមូលដ្ឋានទិន្នន័យបែបនេះ៖

• AWS RDS គឺជាកញ្ចប់ដែលគ្រប់គ្រងសម្រាប់ PostgreSQL/MySQL ។
• DynamoDB គឺជា analogue AWS នៃមូលដ្ឋានទិន្នន័យដែលមានមូលដ្ឋានលើឯកសារ ស្រដៀងទៅនឹង Redis និង MongoDB ។
• Amazon Redshift គឺជាមូលដ្ឋានទិន្នន័យវិភាគដែលបានគ្រប់គ្រង។

ទាំងនេះគឺជាមូលដ្ឋានទិន្នន័យចាស់ ប៉ុន្តែត្រូវបានលើកឡើងនៅក្នុងបរិយាកាសដែលបានគ្រប់គ្រង ដោយមិនចាំបាច់ធ្វើការជាមួយផ្នែករឹង។

ចំណាំ។ ឧទាហរណ៍ត្រូវបានយកសម្រាប់បរិស្ថាន AWS ប៉ុន្តែ analogues របស់ពួកគេក៏មាននៅក្នុង Microsoft Azure, Google Cloud ឬ Yandex.Cloud ផងដែរ។

តើមានអ្វីថ្មីអំពីរឿងនេះ? នៅឆ្នាំ 2020 មិនមានអ្វីទាំងអស់។

គំនិតគ្មានម៉ាស៊ីនមេ

អ្វីដែលថ្មីនៅលើទីផ្សារក្នុងឆ្នាំ 2020 គឺដំណោះស្រាយ serverless ឬ serverless។

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

តើមានវិធីផ្សេងទៀតទេ? ជាមួយនឹងសេវាកម្មគ្មានម៉ាស៊ីនមេ អ្នកអាចធ្វើបាន។

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

ខ្ញុំនឹងព្យាយាមបង្ហាញវិធីសាស្រ្តនេះជាមួយរូបភាព។


ការដាក់ពង្រាយបុរាណ. យើងមានសេវាកម្មមួយដែលមានបន្ទុកជាក់លាក់។ យើងលើកឧទាហរណ៍ពីរ៖ ម៉ាស៊ីនមេរាងកាយ ឬឧទាហរណ៍ក្នុង AWS ។ សំណើខាងក្រៅត្រូវបានផ្ញើទៅកាន់ករណីទាំងនេះ ហើយដំណើរការនៅទីនោះ។

ដូចដែលអ្នកអាចឃើញនៅក្នុងរូបភាព ម៉ាស៊ីនមេមិនត្រូវបានគេបោះចោលស្មើគ្នាទេ។ មួយត្រូវបានប្រើប្រាស់ 100% មានសំណើពីរ ហើយមួយទៀតគឺត្រឹមតែ 50% ប៉ុណ្ណោះ - ទំនេរមួយផ្នែក។ ប្រសិនបើសំណើចំនួនបីបានមកដល់ ប៉ុន្តែ 30 នោះប្រព័ន្ធទាំងមូលនឹងមិនអាចទប់ទល់នឹងបន្ទុកបានទេ ហើយនឹងចាប់ផ្តើមថយចុះ។

ការដាក់ឱ្យប្រើប្រាស់ដោយគ្មានម៉ាស៊ីនមេ. នៅក្នុងបរិយាកាសដែលគ្មានម៉ាស៊ីនមេ សេវាកម្មបែបនេះមិនមានឧទាហរណ៍ ឬម៉ាស៊ីនមេទេ។ មានធនធានកំដៅជាក់លាក់មួយ - ធុង Docker តូចៗដែលបានរៀបចំជាមួយកូដមុខងារដែលបានដាក់ឱ្យប្រើប្រាស់។ ប្រព័ន្ធទទួលសំណើពីខាងក្រៅ ហើយសម្រាប់ពួកវានីមួយៗ ក្របខណ្ឌដែលគ្មានម៉ាស៊ីនមេបង្កើនកុងតឺន័រតូចមួយដែលមានលេខកូដ៖ វាដំណើរការសំណើពិសេសនេះ ហើយសម្លាប់កុងតឺន័រ។

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

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

តើអ្វីជាដែនកំណត់ទូទៅនៃមូលដ្ឋានទិន្នន័យទាំងអស់នេះ? ទាំងនេះគឺជាការចំណាយរបស់ម៉ាស៊ីនមេ cloud ឬ hardware ដែលប្រើឥតឈប់ឈរ (ឬម៉ាស៊ីនមេជាច្រើន)។ វាមិនមានបញ្ហាថាតើយើងប្រើមូលដ្ឋានទិន្នន័យបុរាណ ឬគ្រប់គ្រងនោះទេ ថាតើយើងមាន Devops និងអ្នកគ្រប់គ្រងឬអត់ យើងនៅតែបង់ប្រាក់សម្រាប់ការជួលផ្នែករឹង អគ្គិសនី និងមជ្ឈមណ្ឌលទិន្នន័យ 24/7 ។ បើ​យើង​មាន​មូលដ្ឋាន​បុរាណ យើង​ចំណាយ​សម្រាប់​ចៅហ្វាយ និង​ទាសករ។ ប្រសិនបើវាជាមូលដ្ឋានទិន្នន័យ sharded ផ្ទុកខ្ពស់ យើងចំណាយសម្រាប់ 10, 20 ឬ 30 servers ហើយយើងបង់ប្រាក់ឥតឈប់ឈរ។

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

មូលដ្ឋានទិន្នន័យគ្មានម៉ាស៊ីនមេ - ទ្រឹស្តី

សំណួរឆ្នាំ 2020៖ តើវាអាចទៅរួចទេក្នុងការធ្វើឱ្យ database serverless ផងដែរ? អ្នកទាំងអស់គ្នាធ្លាប់លឺអំពី serverless backend... តោះព្យាយាមធ្វើអោយ database serverless?

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

ម៉្យាងវិញទៀត ស្ទើរតែគ្រប់មូលដ្ឋានទិន្នន័យទំនើបទាំងអស់មានតក្កវិជ្ជា និងសមាសធាតុមួយចំនួនធំ៖ ប្រតិបត្តិការ ការសម្របសម្រួលសុចរិតភាព នីតិវិធី ភាពអាស្រ័យនៃទំនាក់ទំនង និងតក្កវិជ្ជាជាច្រើន។ សម្រាប់តក្កវិជ្ជាមូលដ្ឋានទិន្នន័យច្រើន រដ្ឋតូចមួយគឺគ្រប់គ្រាន់ហើយ។ Gigabytes និង Terabytes ត្រូវបានប្រើប្រាស់ដោយផ្ទាល់ដោយផ្នែកតូចមួយនៃតក្កវិជ្ជាមូលដ្ឋានទិន្នន័យដែលពាក់ព័ន្ធនឹងការប្រតិបត្តិសំណួរដោយផ្ទាល់។

ដូច្នោះហើយ គំនិតគឺ៖ ប្រសិនបើផ្នែកនៃតក្កវិជ្ជាអនុញ្ញាតឲ្យប្រតិបត្តិដោយគ្មានរដ្ឋ ហេតុអ្វីមិនបំបែកមូលដ្ឋានទៅជាផ្នែកដែលមានរដ្ឋ និងគ្មានរដ្ឋ។

Serverless សម្រាប់ដំណោះស្រាយ OLAP

តោះមើលថាតើការកាត់ Database ទៅជាផ្នែក Stateful និង Stateless មើលទៅដូចការប្រើប្រាស់ឧទាហរណ៍ជាក់ស្តែង។

ឧទាហរណ៍ យើងមានមូលដ្ឋានទិន្នន័យវិភាគ៖ ទិន្នន័យខាងក្រៅ (ស៊ីឡាំងក្រហមនៅខាងឆ្វេង) ដំណើរការ ETL ដែលផ្ទុកទិន្នន័យទៅក្នុងមូលដ្ឋានទិន្នន័យ និងជាអ្នកវិភាគដែលផ្ញើសំណួរ SQL ទៅមូលដ្ឋានទិន្នន័យ។ នេះគឺជាគ្រោងការណ៍ប្រតិបត្តិការឃ្លាំងទិន្នន័យបុរាណ។

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

សូមក្រឡេកមើលវិធីសាស្រ្តជំនួសដែលត្រូវបានអនុវត្តនៅក្នុង AWS Athena Serverless ។ មិនមានផ្នែករឹងដែលកំណត់ជាអចិន្ត្រៃយ៍ដែលទិន្នន័យដែលបានទាញយកត្រូវបានរក្សាទុកទេ។ ជំនួសឱ្យនេះ:

• អ្នកប្រើប្រាស់បញ្ជូនសំណួរ SQL ទៅ Athena ។ កម្មវិធីបង្កើនប្រសិទ្ធភាព Athena វិភាគសំណួរ SQL និងស្វែងរកឃ្លាំងទិន្នន័យមេតា (Metadata) សម្រាប់ទិន្នន័យជាក់លាក់ដែលត្រូវការដើម្បីប្រតិបត្តិសំណួរ។
• កម្មវិធីបង្កើនប្រសិទ្ធភាពដោយផ្អែកលើទិន្នន័យដែលប្រមូលបានទាញយកទិន្នន័យចាំបាច់ពីប្រភពខាងក្រៅទៅក្នុងកន្លែងផ្ទុកបណ្តោះអាសន្ន (មូលដ្ឋានទិន្នន័យបណ្តោះអាសន្ន)។
• សំណួរ SQL ពីអ្នកប្រើប្រាស់ត្រូវបានប្រតិបត្តិក្នុងការផ្ទុកបណ្តោះអាសន្ន ហើយលទ្ធផលត្រូវបានប្រគល់ជូនអ្នកប្រើប្រាស់វិញ។
• ការផ្ទុកបណ្តោះអាសន្នត្រូវបានសម្អាត ហើយធនធានត្រូវបានបញ្ចេញ។

ក្នុង​ស្ថាបត្យកម្ម​នេះ យើង​ចំណាយ​តែ​សម្រាប់​ដំណើរ​ការ​នៃ​ការ​អនុវត្ត​សំណើ​ប៉ុណ្ណោះ។ គ្មានសំណើ - គ្មានការចំណាយ។

នេះគឺជាវិធីសាស្រ្តធ្វើការ ហើយត្រូវបានអនុវត្តមិនត្រឹមតែនៅក្នុង Athena Serverless ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មាននៅក្នុង Redshift Spectrum (នៅក្នុង AWS) ផងដែរ។

ឧទាហរណ៍ Athena បង្ហាញថាមូលដ្ឋានទិន្នន័យ Serverless ដំណើរការលើសំណួរពិតដែលមានទិន្នន័យរាប់សិប និងរាប់រយ Terabytes ។ រាប់រយ Terabytes នឹងត្រូវការម៉ាស៊ីនមេរាប់រយ ប៉ុន្តែយើងមិនចាំបាច់បង់ប្រាក់សម្រាប់ពួកគេទេ - យើងបង់ប្រាក់សម្រាប់សំណើ។ ល្បឿននៃសំណើនីមួយៗគឺទាប (ខ្លាំងណាស់) បើប្រៀបធៀបទៅនឹងមូលដ្ឋានទិន្នន័យវិភាគឯកទេសដូចជា Vertica ប៉ុន្តែយើងមិនបង់ប្រាក់សម្រាប់រយៈពេលរង់ចាំនោះទេ។

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

Serverless សម្រាប់ដំណោះស្រាយ OLTP

ឧទាហរណ៍មុនបានមើលលើកិច្ចការ OLAP (វិភាគ) ។ ឥឡូវនេះសូមក្រឡេកមើលភារកិច្ច OLTP ។

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

គំនិតនេះត្រូវបានអនុវត្តនៅក្នុងមូលដ្ឋានទិន្នន័យដែលមានឈ្មោះថា Aurora Serverless AWS ។ គោលការណ៍គឺសាមញ្ញ៖ សំណើពីកម្មវិធីខាងក្រៅត្រូវបានទទួលយកដោយកងនាវាប្រូកស៊ី។ ដោយមើលឃើញការកើនឡើងនៃបន្ទុក វាបែងចែកធនធានកុំព្យូទ័រពីករណីតិចតួចបំផុតដែលបានកំដៅមុន - ការតភ្ជាប់ត្រូវបានធ្វើឱ្យលឿនតាមដែលអាចធ្វើទៅបាន។ ការបិទករណីកើតឡើងតាមរបៀបដូចគ្នា។

នៅក្នុង Aurora មានគំនិតនៃអង្គភាពសមត្ថភាព Aurora, ACU ។ នេះគឺជា (តាមលក្ខខណ្ឌ) ជាឧទាហរណ៍ (ម៉ាស៊ីនមេ) ។ ACU ជាក់លាក់នីមួយៗអាចជាមេ ឬទាសករ។ ឯកតាសមត្ថភាពនីមួយៗមាន RAM ខួរក្បាល និងឌីសតិចតួចផ្ទាល់ខ្លួន។ ដូច្នោះហើយ ម្នាក់ជាមេ នៅសល់គឺត្រូវអានតែការចម្លងប៉ុណ្ណោះ។

ចំនួននៃអង្គភាពសមត្ថភាព Aurora ទាំងនេះដែលកំពុងដំណើរការគឺជាប៉ារ៉ាម៉ែត្រដែលអាចកំណត់រចនាសម្ព័ន្ធបាន។ បរិមាណអប្បបរមាអាចជាលេខមួយ ឬសូន្យ (ក្នុងករណីនេះ មូលដ្ឋានទិន្នន័យមិនដំណើរការទេ ប្រសិនបើគ្មានសំណើ)។

នៅពេលដែលមូលដ្ឋានទទួលបានសំណើ កងនាវាប្រូកស៊ីបង្កើន Aurora CapacityUnits ដោយបង្កើនធនធានដំណើរការរបស់ប្រព័ន្ធ។ សមត្ថភាពក្នុងការបង្កើន និងបន្ថយធនធានអនុញ្ញាតឱ្យប្រព័ន្ធ "លេងសើច" ធនធាន៖ បង្ហាញ ACUs នីមួយៗដោយស្វ័យប្រវត្តិ (ជំនួសពួកវាដោយរបស់ថ្មី) និងដាក់ចេញនូវបច្ចុប្បន្នភាពបច្ចុប្បន្នទាំងអស់ចំពោះធនធានដែលបានដក។

មូលដ្ឋាន Aurora Serverless អាចធ្វើមាត្រដ្ឋានបន្ទុកអាន។ ប៉ុន្តែ​ឯកសារ​មិន​និយាយ​ត្រង់​នេះ​ទេ។ វាអាចមានអារម្មណ៍ថាពួកគេអាចលើកមេច្រើន។ មិនមានវេទមន្តទេ។

មូលដ្ឋានទិន្នន័យនេះគឺសមល្អដើម្បីជៀសវាងការចំណាយប្រាក់យ៉ាងច្រើនលើប្រព័ន្ធដែលមានការចូលប្រើដែលមិនអាចទាយទុកជាមុនបាន។ ឧទាហរណ៍ នៅពេលបង្កើត MVP ឬគេហទំព័រកាតអាជីវកម្មទីផ្សារ ជាធម្មតាយើងមិនរំពឹងថានឹងមានបន្ទុកថេរនោះទេ។ ដូច្នោះហើយ ប្រសិនបើមិនមានការចូលប្រើទេ យើងមិនបង់ប្រាក់សម្រាប់ឧទាហរណ៍ទេ។ នៅពេលដែលការផ្ទុកដែលមិនរំពឹងទុកកើតឡើង ឧទាហរណ៍បន្ទាប់ពីសន្និសីទ ឬយុទ្ធនាការផ្សាយពាណិជ្ជកម្ម ហ្វូងមនុស្សចូលមើលគេហទំព័រ ហើយការផ្ទុកកើនឡើងយ៉ាងខ្លាំង Aurora Serverless ទទួលយកបន្ទុកនេះដោយស្វ័យប្រវត្តិ ហើយភ្ជាប់ធនធានដែលបាត់ (ACU) យ៉ាងរហ័ស។ បន្ទាប់មកសន្និសិទបានកន្លងផុតទៅ មនុស្សគ្រប់គ្នាភ្លេចអំពីគំរូដើម ម៉ាស៊ីនមេ (ACU) ងងឹត ហើយការចំណាយធ្លាក់ចុះដល់សូន្យ - ងាយស្រួល។

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

មិនមានវេទមន្តទេ - វាជា PostgreSQL ធម្មតា។ ប៉ុន្តែដំណើរការនៃការបន្ថែមម៉ាស៊ីន និងផ្តាច់ពួកវាគឺស្វ័យប្រវត្តិដោយផ្នែក។

គ្មានម៉ាស៊ីនមេតាមការរចនា

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

មូលដ្ឋាននេះត្រូវបានគេហៅថា Snowflake ។ វាមានប្លុកគន្លឹះបី។

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

ប្លុកទីពីរគឺជាសំណុំនៃចង្កោមកុំព្យូទ័រនិម្មិតសម្រាប់ការគណនា (ក្នុងរូបភាពមានសំណុំនៃរង្វង់ពណ៌ខៀវ)។

ប្លុកទីបីគឺជាប្រព័ន្ធផ្ទុកទិន្នន័យដែលមានមូលដ្ឋានលើ S3 ។ S3 គឺ​ជា​កន្លែង​ផ្ទុក​វត្ថុ​គ្មាន​វិមាត្រ​ក្នុង AWS ដែល​មាន​លក្ខណៈ​ដូច​ជា Dropbox គ្មាន​វិមាត្រ​សម្រាប់​អាជីវកម្ម។

តោះមើលពីរបៀបដែល Snowflake ដំណើរការដោយសន្មត់ថាការចាប់ផ្តើមត្រជាក់។ នោះគឺមានមូលដ្ឋានទិន្នន័យទិន្នន័យត្រូវបានផ្ទុកទៅក្នុងវាមិនមានសំណួរដែលកំពុងដំណើរការទេ។ ដូច្នោះហើយ ប្រសិនបើមិនមានសំណើទៅកាន់មូលដ្ឋានទិន្នន័យទេ នោះយើងបានលើកឡើងនូវសេវាទិន្នន័យមេតាដែលមានល្បឿនលឿនក្នុងអង្គចងចាំ (ប្លុកទីមួយ)។ ហើយយើងមានកន្លែងផ្ទុក S3 ដែលទិន្នន័យតារាងត្រូវបានរក្សាទុក បែងចែកទៅជា micropartitions ដែលគេហៅថា។ សម្រាប់ភាពសាមញ្ញ៖ ប្រសិនបើតារាងមានប្រតិបត្តិការ នោះ micropartitions គឺជាថ្ងៃនៃប្រតិបត្តិការ។ ជារៀងរាល់ថ្ងៃគឺជា micropartition ដាច់ដោយឡែកឯកសារដាច់ដោយឡែក។ ហើយនៅពេលដែលមូលដ្ឋានទិន្នន័យដំណើរការក្នុងរបៀបនេះ អ្នកគ្រាន់តែចំណាយសម្រាប់ចន្លោះដែលកាន់កាប់ដោយទិន្នន័យប៉ុណ្ណោះ។ លើសពីនេះទៅទៀតអត្រាក្នុងមួយអាសនៈគឺទាបណាស់ (ជាពិសេសដោយគិតគូរពីការបង្ហាប់យ៉ាងសំខាន់) ។ សេវាកម្មទិន្នន័យមេតាក៏ដំណើរការឥតឈប់ឈរដែរ ប៉ុន្តែអ្នកមិនត្រូវការធនធានច្រើនដើម្បីបង្កើនប្រសិទ្ធភាពសំណួរទេ ហើយសេវាកម្មនេះអាចត្រូវបានចាត់ទុកថាជាឧបករណ៍ចែករំលែក។

ឥឡូវ​យើង​ស្រមៃ​ថា​អ្នក​ប្រើ​ម្នាក់​បាន​ចូល​មក​មូលដ្ឋាន​ទិន្នន័យ​របស់​យើង ហើយ​បាន​ផ្ញើ​សំណួរ SQL ។ សំណួរ SQL ត្រូវបានផ្ញើភ្លាមៗទៅកាន់សេវាកម្ម Metadata សម្រាប់ដំណើរការ។ អាស្រ័យហេតុនេះ នៅពេលទទួលបានសំណើ សេវាកម្មនេះវិភាគសំណើ ទិន្នន័យដែលមាន ការអនុញ្ញាតពីអ្នកប្រើប្រាស់ ហើយប្រសិនបើអ្វីៗទាំងអស់គឺល្អ រៀបចំផែនការសម្រាប់ដំណើរការសំណើ។

បន្ទាប់មក សេវាកម្មចាប់ផ្តើមបើកដំណើរការនៃចង្កោមកុំព្យូទ័រ។ ចង្កោមកុំព្យូទ័រគឺជាចង្កោមនៃម៉ាស៊ីនមេដែលធ្វើការគណនា។ នោះគឺជាចង្កោមដែលអាចផ្ទុក 1 ម៉ាស៊ីនមេ 2 ម៉ាស៊ីនមេ 4, 8, 16, 32 - ច្រើនតាមដែលអ្នកចង់បាន។ អ្នកបោះសំណើមួយ ហើយការចាប់ផ្តើមនៃចង្កោមនេះចាប់ផ្តើមភ្លាមៗ។ វាពិតជាចំណាយពេលប៉ុន្មានវិនាទី។

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

សំណួរ SQL នីមួយៗមិនត្រឹមតែអាចអានសរុបពីទិន្នន័យដែលបានផ្ទុកពីមុនប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងផ្ទុក/បង្កើតទិន្នន័យថ្មីនៅក្នុងមូលដ្ឋានទិន្នន័យផងដែរ។ នោះគឺវាអាចជាសំណួរដែលឧទាហរណ៍ បញ្ចូលកំណត់ត្រាថ្មីទៅក្នុងតារាងមួយផ្សេងទៀត ដែលនាំទៅដល់ការលេចចេញនូវភាគថាសថ្មីនៅលើចង្កោមកុំព្យូទ័រ ដែលវាត្រូវបានរក្សាទុកដោយស្វ័យប្រវត្តិនៅក្នុងកន្លែងផ្ទុក S3 តែមួយ។

សេណារីយ៉ូដែលបានពិពណ៌នាខាងលើ ចាប់ពីការមកដល់របស់អ្នកប្រើប្រាស់ រហូតដល់ការបង្កើនចង្កោម ការផ្ទុកទិន្នន័យ ការប្រតិបត្តិសំណួរ ការទទួលបានលទ្ធផលត្រូវបានបង់ក្នុងអត្រាសម្រាប់នាទីនៃការប្រើប្រាស់ចង្កោមកុំព្យូទ័រនិម្មិតដែលបានលើកឡើង ឃ្លាំងនិម្មិត។ អត្រាប្រែប្រួលអាស្រ័យលើតំបន់ AWS និងទំហំចង្កោម ប៉ុន្តែជាមធ្យមវាគឺពីរបីដុល្លារក្នុងមួយម៉ោង។ ម៉ាស៊ីន​មួយ​ចង្កោម​មាន​ម៉ាស៊ីន​បួន​មាន​តម្លៃ​ថ្លៃ​ជាង​ម៉ាស៊ីន​ពីរ​ចង្កោម ហើយ​ចង្កោម​ម៉ាស៊ីន​ប្រាំបី​នៅតែ​ថ្លៃ​ជាង​ពីរ​ដង។ ជម្រើសនៃម៉ាស៊ីន 16, 32 អាចរកបាន អាស្រ័យលើភាពស្មុគស្មាញនៃសំណើ។ ប៉ុន្តែអ្នកចំណាយសម្រាប់តែនាទីទាំងនោះនៅពេលដែលចង្កោមកំពុងដំណើរការពិតប្រាកដ ពីព្រោះនៅពេលដែលគ្មានសំណើ អ្នកពិតជាដកដៃចេញ ហើយបន្ទាប់ពី 5-10 នាទីនៃការរង់ចាំ (ប៉ារ៉ាម៉ែត្រកំណត់) វានឹងរលត់ទៅដោយឯកឯង។ បង្កើនធនធាន និងក្លាយជាឥតគិតថ្លៃ។

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

សេណារីយ៉ូទីមួយដែលបានពិពណ៌នាដោយប្រើ Snowflake នៅក្នុងការកំណត់អ្នកប្រើតែមួយ។ ឥឡូវនេះសូមស្រមៃថាមានអ្នកប្រើប្រាស់ជាច្រើនដែលកាន់តែខិតទៅជិតសេណារីយ៉ូពិតប្រាកដ។

ចូរនិយាយថាយើងមានអ្នកវិភាគជាច្រើន និងរបាយការណ៍ Tableau ដែលវាយប្រហារមូលដ្ឋានទិន្នន័យរបស់យើងជាបន្តបន្ទាប់ជាមួយនឹងសំណួរ SQL វិភាគសាមញ្ញមួយចំនួនធំ។

លើសពីនេះ ឧបមាថាយើងមាន Data Scientists ដែលមានគំនិតច្នៃប្រឌិត ដែលព្យាយាមធ្វើរឿងដ៏អស្ចារ្យជាមួយទិន្នន័យ ប្រតិបត្តិការជាមួយរាប់សិប Terabytes វិភាគទិន្នន័យរាប់ពាន់លាន និងពាន់លានជួរ។

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

សម្រាប់សំណួរពន្លឺមួយចំនួនធំ អ្នកអាចលើកចង្កោមតូចៗ 2-3 ប្រហែល 2 ម៉ាស៊ីននីមួយៗ។ ឥរិយាបថនេះអាចត្រូវបានអនុវត្តក្នុងចំណោមរបស់ផ្សេងទៀតដោយប្រើការកំណត់ដោយស្វ័យប្រវត្តិ។ ដូច្នេះអ្នកនិយាយថា “Snowflake ចូរលើកចង្កោមតូចមួយ។ ប្រសិនបើការផ្ទុកនៅលើវាកើនឡើងលើសពីប៉ារ៉ាម៉ែត្រជាក់លាក់មួយ លើកទីពីរស្រដៀងគ្នា ទីបី។ នៅពេលដែលបន្ទុកចាប់ផ្តើមថយចុះ ចូរពន្លត់ការលើស។ ដូច្នេះ មិនថាអ្នកវិភាគប៉ុន្មាននាក់មក ហើយចាប់ផ្តើមមើលរបាយការណ៍នោះទេ មនុស្សគ្រប់រូបមានធនធានគ្រប់គ្រាន់។

ក្នុងពេលជាមួយគ្នានេះ ប្រសិនបើអ្នកវិភាគកំពុងដេកលក់ ហើយគ្មាននរណាម្នាក់មើលរបាយការណ៍នោះ ចង្កោមអាចនឹងងងឹតទាំងស្រុង ហើយអ្នកឈប់បង់ប្រាក់សម្រាប់ពួកគេ។

ក្នុងពេលជាមួយគ្នានេះ សម្រាប់សំណួរធ្ងន់ៗ (ពីអ្នកវិទ្យាសាស្ត្រទិន្នន័យ) អ្នកអាចលើកចង្កោមធំមួយសម្រាប់ម៉ាស៊ីន 32 ។ ចង្កោមនេះក៏នឹងត្រូវបានបង់សម្រាប់តែនាទី និងម៉ោងទាំងនោះ នៅពេលដែលសំណើដ៏ធំរបស់អ្នកកំពុងដំណើរការនៅទីនោះ។

ឱកាសដែលបានពិពណ៌នាខាងលើអនុញ្ញាតឱ្យអ្នកបែងចែកមិនត្រឹមតែ 2 ប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងប្រភេទនៃបន្ទុកការងារជាច្រើនទៀតទៅជាចង្កោម (ETL, ការត្រួតពិនិត្យ, របាយការណ៍សម្ភារៈ, ... ) ។

ចូរយើងសង្ខេប Snowflake ។ មូលដ្ឋានរួមបញ្ចូលគ្នានូវគំនិតដ៏ស្រស់ស្អាត និងការអនុវត្តដែលអាចដំណើរការបាន។ នៅ ManyChat យើងប្រើ Snowflake ដើម្បីវិភាគទិន្នន័យទាំងអស់ដែលយើងមាន។ យើង​មិន​មាន​ចង្កោម​បី​ដូច​ក្នុង​ឧទាហរណ៍​ទេ ប៉ុន្តែ​ពី 5 ទៅ 9 ដែល​មាន​ទំហំ​ខុស​គ្នា។ យើងមានម៉ាស៊ីន 16 ធម្មតា ម៉ាស៊ីន 2 និងម៉ាស៊ីន 1 តូចទំនើបសម្រាប់ការងារមួយចំនួន។ ពួកគេចែកចាយបន្ទុកដោយជោគជ័យ និងអនុញ្ញាតឱ្យយើងសន្សំបានច្រើន។

មូលដ្ឋានទិន្នន័យធ្វើមាត្រដ្ឋានការអាន និងសរសេរដោយជោគជ័យ។ នេះ​គឺ​ជា​ភាព​ខុស​គ្នា​ដ៏​ធំ​មួយ និង​ការ​ទម្លាយ​ដ៏​ធំ​មួយ​បើ​ធៀប​នឹង "Aurora" ដែល​មាន​តែ​ការ​អាន​ប៉ុណ្ណោះ។ Snowflake អនុញ្ញាតឱ្យអ្នកធ្វើមាត្រដ្ឋានការងារសរសេររបស់អ្នកជាមួយនឹងចង្កោមកុំព្យូទ័រទាំងនេះ។ នោះហើយជាដូចដែលខ្ញុំបានលើកឡើង យើងប្រើចង្កោមជាច្រើននៅក្នុង ManyChat ចង្កោមតូច និងតូចត្រូវបានប្រើជាចម្បងសម្រាប់ ETL សម្រាប់ផ្ទុកទិន្នន័យ។ ហើយអ្នកវិភាគបានរស់នៅលើចង្កោមមធ្យមរួចហើយ ដែលពិតជាមិនត្រូវបានប៉ះពាល់ដោយបន្ទុក ETL ដូច្នេះពួកគេធ្វើការយ៉ាងលឿន។

ដូច្នោះហើយ មូលដ្ឋានទិន្នន័យគឺសមល្អសម្រាប់កិច្ចការ OLAP ។ ទោះជាយ៉ាងណាក៏ដោយ ជាអកុសល វាមិនទាន់អាចអនុវត្តបានសម្រាប់បន្ទុកការងារ OLTP នៅឡើយទេ។ ទីមួយ មូលដ្ឋានទិន្នន័យនេះគឺជា columnar ជាមួយនឹងផលវិបាកបន្ទាប់បន្សំទាំងអស់។ ទីពីរ វិធីសាស្រ្តខ្លួនវា នៅពេលដែលសំណើនីមួយៗ ប្រសិនបើចាំបាច់ អ្នកលើកចង្កោមកុំព្យូទ័រ ហើយជន់លិចវាជាមួយនឹងទិន្នន័យ ជាអកុសល មិនទាន់លឿនគ្រប់គ្រាន់សម្រាប់ការផ្ទុក OLTP នៅឡើយទេ។ ការរង់ចាំវិនាទីសម្រាប់កិច្ចការ OLAP គឺជារឿងធម្មតា ប៉ុន្តែសម្រាប់កិច្ចការ OLTP វាមិនអាចទទួលយកបានទេ 100 ms នឹងប្រសើរជាងនេះ ឬ 10 ms នឹងប្រសើរជាងនេះ។

លទ្ធផល

មូលដ្ឋានទិន្នន័យគ្មានម៉ាស៊ីនគឺអាចធ្វើទៅបានដោយការបែងចែកមូលដ្ឋានទិន្នន័យទៅជាផ្នែកគ្មានរដ្ឋ និងផ្នែករដ្ឋ។ អ្នកប្រហែលជាបានកត់សម្គាល់ថានៅក្នុងឧទាហរណ៍ខាងលើទាំងអស់ ផ្នែក Stateful គឺនិយាយដោយទាក់ទងគ្នា ការរក្សាទុក micro-partitions នៅក្នុង S3 ហើយ Stateless គឺជាកម្មវិធីបង្កើនប្រសិទ្ធភាព ធ្វើការជាមួយទិន្នន័យមេតា ដោះស្រាយបញ្ហាសុវត្ថិភាពដែលអាចត្រូវបានលើកឡើងជាសេវាកម្ម Stateless ទម្ងន់ស្រាលឯករាជ្យ។

ការប្រតិបត្តិសំណួរ SQL ក៏អាចត្រូវបានគេយល់ថាជាសេវាកម្មរដ្ឋពន្លឺដែលអាចលេចឡើងក្នុងរបៀបគ្មានម៉ាស៊ីនមេ ដូចជាក្រុមកុំព្យូទ័រ Snowflake ទាញយកតែទិន្នន័យចាំបាច់ ប្រតិបត្តិសំណួរ និង "ចេញទៅក្រៅ" ។

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

ខ្ញុំសង្ឃឹមថាអ្នកបានរកឃើញវាគួរឱ្យចាប់អារម្មណ៍។ Serverless គឺជាអនាគត :)

ប្រភព: www.habr.com