មូលដ្ឋានគ្រឹះនៃការរចនាមូលដ្ឋានទិន្នន័យ - ការប្រៀបធៀប PostgreSQL, Cassandra និង MongoDB

ជំរាបសួរមិត្តភក្តិ។ មុនពេលចាកចេញសម្រាប់ផ្នែកទីពីរនៃថ្ងៃឈប់សម្រាកខែឧសភា យើងចែករំលែកជាមួយអ្នកនូវសម្ភារៈដែលយើងបានបកប្រែដោយរំពឹងថានឹងចាប់ផ្តើមការផ្សាយថ្មីនៅលើវគ្គសិក្សា "ទំនាក់ទំនង DBMS".

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

គោលបំណងនៃអត្ថបទនេះគឺដើម្បីជួយអ្នកបង្កើតកម្មវិធីធ្វើការជ្រើសរើសត្រឹមត្រូវរវាង SQL និង NoSQL នៅក្នុងបរិបទនៃគំរូទិន្នន័យកម្មវិធី។ យើងនឹងពិនិត្យមើលមូលដ្ឋានទិន្នន័យ SQL មួយគឺ PostgreSQL និងមូលដ្ឋានទិន្នន័យ NoSQL ពីរគឺ Cassandra និង MongoDB ដើម្បីគ្របដណ្តប់មូលដ្ឋានគ្រឹះនៃការរចនាមូលដ្ឋានទិន្នន័យ ដូចជាការបង្កើតតារាង ការបញ្ចូលពួកវា អានទិន្នន័យពីតារាង និងលុបវា។ នៅក្នុងអត្ថបទបន្ទាប់ យើងនឹងប្រាកដថាមើលសន្ទស្សន៍ ប្រតិបត្តិការ ចូលរួម ការណែនាំ TTL និងការរចនាមូលដ្ឋានទិន្នន័យផ្អែកលើ JSON ។

តើអ្វីជាភាពខុសគ្នារវាង SQL និង NoSQL?

មូលដ្ឋានទិន្នន័យ SQL បង្កើនភាពបត់បែននៃកម្មវិធីតាមរយៈការធានាប្រតិបត្តិការ ACID ក៏ដូចជាសមត្ថភាពរបស់ពួកគេក្នុងការសាកសួរទិន្នន័យដោយប្រើ JOINs នៅក្នុងវិធីដែលមិនរំពឹងទុកនៅលើកំពូលនៃគំរូមូលដ្ឋានទិន្នន័យទំនាក់ទំនងធម្មតាដែលមានស្រាប់។

ដោយសារស្ថាបត្យកម្ម monolithic/single-node របស់ពួកគេ និងការប្រើប្រាស់គំរូចម្លងមេ-ទាសករសម្រាប់ការប្រើឡើងវិញ មូលដ្ឋានទិន្នន័យ SQL ប្រពៃណីខ្វះលក្ខណៈពិសេសសំខាន់ពីរ - លទ្ធភាពសរសេរលីនេអ៊ែរ (ឧទាហរណ៍ការបែងចែកដោយស្វ័យប្រវត្តិឆ្លងកាត់ថ្នាំងច្រើន) និងការបាត់បង់ទិន្នន័យដោយស្វ័យប្រវត្តិ/សូន្យ។ នេះមានន័យថាចំនួនទិន្នន័យដែលទទួលបានមិនអាចលើសពីការសរសេរអតិបរមានៃ node តែមួយទេ។ លើសពីនេះ ការបាត់បង់ទិន្នន័យបណ្ដោះអាសន្នមួយចំនួនត្រូវតែយកមកពិចារណាក្នុងការអត់ឱនចំពោះកំហុស (នៅក្នុងស្ថាបត្យកម្មគ្មានការចែករំលែក)។ នៅទីនេះអ្នកត្រូវចងចាំថាការប្តេជ្ញាចិត្តនាពេលថ្មីៗនេះមិនទាន់ត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងច្បាប់ចម្លងទាសករទេ។ ការធ្វើបច្ចុប្បន្នភាពដែលមិនមានពេលទំនេរក៏ពិបាកក្នុងការសម្រេចបាននៅក្នុងមូលដ្ឋានទិន្នន័យ SQL ។

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

NoSQL ផ្តោតលើការសម្រេចបាននូវការអនុវត្តខ្ពស់នៅក្នុងចង្កោមដែលបានចែកចាយ ហើយនេះគឺជាហេតុផលមូលដ្ឋានសម្រាប់ការដោះដូរការរចនាមូលដ្ឋានទិន្នន័យជាច្រើនដែលរួមមានការបាត់បង់ប្រតិបត្តិការ ACID ចូលរួម និងសន្ទស្សន៍បន្ទាប់បន្សំជាសកល។

មានអំណះអំណាងមួយដែលថា ខណៈពេលដែលមូលដ្ឋានទិន្នន័យ NoSQL ផ្តល់នូវការសរសេរជាលីនេអ៊ែរ និងការអត់ធ្មត់លើកំហុសខ្ពស់ ការបាត់បង់ការធានាប្រតិបត្តិការធ្វើឱ្យពួកគេមិនស័ក្តិសមសម្រាប់ទិន្នន័យសំខាន់នៃបេសកកម្ម។

តារាងខាងក្រោមបង្ហាញពីរបៀបដែលគំរូទិន្នន័យនៅក្នុង NoSQL ខុសពី SQL ។

SQL និង NoSQL៖ ហេតុអ្វីចាំបាច់ទាំងពីរ?

កម្មវិធីពិភពពិតដែលមានអ្នកប្រើប្រាស់មួយចំនួនធំដូចជា Amazon.com, Netflix, Uber, និង Airbnb ត្រូវបានផ្តល់ភារកិច្ចក្នុងការអនុវត្តកិច្ចការស្មុគស្មាញ និងច្រើនមុខ។ ឧទាហរណ៍ កម្មវិធី e-commerce ដូចជា Amazon.com ត្រូវការរក្សាទុកទម្ងន់ស្រាល ទិន្នន័យសំខាន់ៗដូចជា ព័ត៌មានអ្នកប្រើប្រាស់ ផលិតផល ការបញ្ជាទិញ វិក្កយបត្រ រួមជាមួយនឹងទិន្នន័យធ្ងន់ និងមិនសូវរសើប ដូចជាការវាយតម្លៃផលិតផល សារគាំទ្រ សកម្មភាពអ្នកប្រើប្រាស់។ ការពិនិត្យ និងការណែនាំរបស់អ្នកប្រើប្រាស់។ តាមធម្មជាតិ កម្មវិធីទាំងនេះពឹងផ្អែកលើមូលដ្ឋានទិន្នន័យ SQL យ៉ាងហោចណាស់មួយ រួមជាមួយមូលដ្ឋានទិន្នន័យ NoSQL យ៉ាងតិចមួយ។ នៅក្នុងប្រព័ន្ធឆ្លងតំបន់ និងសកល មូលដ្ឋានទិន្នន័យ NoSQL ដំណើរការជាឃ្លាំងសម្ងាត់ចែកចាយតាមភូមិសាស្ត្រសម្រាប់ទិន្នន័យដែលរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ SQL ប្រភពដែលអាចទុកចិត្តបានដែលកំពុងដំណើរការនៅក្នុងតំបន់ជាក់លាក់មួយ។

តើ YugaByte DB រួមបញ្ចូលគ្នា SQL និង NoSQL យ៉ាងដូចម្តេច?

បង្កើតឡើងនៅលើម៉ាស៊ីនផ្ទុកចម្រុះដែលតម្រង់ទិសកំណត់ហេតុ ការបំបែកដោយស្វ័យប្រវត្តិ ការចម្លងការយល់ស្របដែលបានចែកចាយដោយ sharded និងប្រតិបត្តិការចែកចាយ ACID (បំផុសគំនិតដោយ Google Spanner) YugaByte DB គឺជាមូលដ្ឋានទិន្នន័យប្រភពបើកចំហដំបូងគេរបស់ពិភពលោកដែលអាចប្រើបានក្នុងពេលដំណាលគ្នាជាមួយ NoSQL (Cassandra & Redis) និង SQL (PostgreSQL) ។ ដូចដែលបានបង្ហាញក្នុងតារាងខាងក្រោម YCQL ដែលជា YugaByte DB API ឆបគ្នាជាមួយ Cassandra បន្ថែមគោលគំនិតនៃប្រតិបត្តិការ ACID តែមួយ និងពហុគន្លឹះ និងសន្ទស្សន៍បន្ទាប់បន្សំជាសកលទៅ NoSQL API ដោយហេតុនេះនាំឱ្យឈានចូលយុគសម័យនៃប្រតិបត្តិការមូលដ្ឋានទិន្នន័យ NoSQL ។ លើសពីនេះ YCQL ដែលជា YugaByte DB API ដែលត្រូវគ្នាជាមួយ PostgreSQL បន្ថែមគោលគំនិតនៃមាត្រដ្ឋានសរសេរលីនេអ៊ែរ និងការអត់ធ្មត់កំហុសដោយស្វ័យប្រវត្តិទៅ SQL API ដោយនាំយកមូលដ្ឋានទិន្នន័យ SQL ចែកចាយទៅកាន់ពិភពលោក។ ដោយសារតែ YugaByte DB គឺជាប្រតិបត្តិការនៅក្នុងធម្មជាតិ ដូច្នេះ NoSQL API ឥឡូវនេះអាចត្រូវបានប្រើនៅក្នុងបរិបទនៃទិន្នន័យសំខាន់នៃបេសកកម្ម។

ដូចដែលបានបញ្ជាក់ពីមុននៅក្នុងអត្ថបទ "ការណែនាំ YSQL: PostgreSQL Compatible Distributed SQL API សម្រាប់ YugaByte DB"ជម្រើសរវាង SQL ឬ NoSQL ក្នុង YugaByte DB អាស្រ័យទាំងស្រុងលើលក្ខណៈនៃបន្ទុកការងារ៖

• ប្រសិនបើបន្ទុកការងារចម្បងរបស់អ្នកគឺជាប្រតិបត្តិការ JOIN ច្រើនគ្រាប់ បន្ទាប់មកនៅពេលជ្រើសរើស YSQL សូមយល់ថាកូនសោរបស់អ្នកអាចត្រូវបានចែកចាយតាមថ្នាំងច្រើន ដែលបណ្តាលឱ្យមានភាពយឺតយ៉ាវខ្ពស់ និង/ឬបញ្ជូនចរន្តទាបជាង NoSQL ។
• បើមិនដូច្នោះទេ សូមជ្រើសរើស NoSQL APIs ណាមួយក្នុងចំនោម NoSQL APIs ទាំងពីរ ដោយចងចាំថាអ្នកនឹងទទួលបានដំណើរការកាន់តែប្រសើរឡើងជាលទ្ធផលនៃសំណួរដែលបានបម្រើពីថ្នាំងមួយក្នុងពេលតែមួយ។ YugaByte DB អាច​បម្រើ​ជា​មូលដ្ឋាន​ទិន្នន័យ​ប្រតិបត្តិការ​តែ​មួយ​សម្រាប់​ពិភព​ពិត​ជា​កម្មវិធី​ស្មុគស្មាញ​ដែល​ត្រូវ​ការ​គ្រប់គ្រង​បន្ទុក​ការងារ​ច្រើន​ក្នុង​ពេល​ដំណាល​គ្នា។

មន្ទីរពិសោធន៍គំរូទិន្នន័យនៅក្នុងផ្នែកបន្ទាប់គឺផ្អែកលើមូលដ្ឋានទិន្នន័យ PostgreSQL និង Cassandra API ដែលត្រូវគ្នានឹង YugaByte DB ដែលផ្ទុយពីមូលដ្ឋានទិន្នន័យដើម។ វិធីសាស្រ្តនេះសង្កត់ធ្ងន់លើភាពងាយស្រួលនៃការធ្វើអន្តរកម្មជាមួយ APIs ពីរផ្សេងគ្នា (នៅលើច្រកពីរផ្សេងគ្នា) នៃ cluster មូលដ្ឋានទិន្នន័យដូចគ្នា ផ្ទុយពីការប្រើ clusters ឯករាជ្យទាំងស្រុងនៃ databases ពីរផ្សេងគ្នា។
នៅក្នុងផ្នែកខាងក្រោម យើងនឹងពិនិត្យមើលមន្ទីរពិសោធន៍គំរូទិន្នន័យ ដើម្បីបង្ហាញពីភាពខុសគ្នា និងភាពសាមញ្ញមួយចំនួននៃមូលដ្ឋានទិន្នន័យដែលគ្របដណ្តប់។

មន្ទីរពិសោធន៍គំរូទិន្នន័យ

ការដំឡើងមូលដ្ឋានទិន្នន័យ

ដោយមានការសង្កត់ធ្ងន់លើការរចនាគំរូទិន្នន័យ (ជាជាងស្ថាបត្យកម្មនៃការដាក់ពង្រាយស្មុគស្មាញ) យើងនឹងដំឡើងមូលដ្ឋានទិន្នន័យនៅក្នុង Docker containers នៅលើម៉ាស៊ីនមូលដ្ឋាន ហើយបន្ទាប់មកធ្វើអន្តរកម្មជាមួយពួកវាដោយប្រើសែលបន្ទាត់ពាក្យបញ្ជារៀងៗខ្លួន។

មូលដ្ឋានទិន្នន័យរបស់ PostgreSQL & Cassandra ដែលត្រូវគ្នានឹង YugaByte DB

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB

docker run --name my-mongo -d mongo:latest

ការចូលប្រើបន្ទាត់ពាក្យបញ្ជា

ចូរភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យដោយប្រើសែលបន្ទាត់ពាក្យបញ្ជាសម្រាប់ APIs ដែលត្រូវគ្នា។

PostgreSQL

psql គឺជាសែលបន្ទាត់ពាក្យបញ្ជាសម្រាប់ធ្វើអន្តរកម្មជាមួយ PostgreSQL ។ ដើម្បីងាយស្រួលប្រើ YugaByte DB ភ្ជាប់មកជាមួយ psql ខាងស្តាំនៅក្នុងថតឯកសារ។

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

Cassandra

cqlsh គឺជាសែលបន្ទាត់ពាក្យបញ្ជាសម្រាប់ធ្វើអន្តរកម្មជាមួយ Cassandra និងមូលដ្ឋានទិន្នន័យដែលត្រូវគ្នារបស់វាតាមរយៈ CQL (ភាសា Cassandra Query) ។ សម្រាប់ភាពងាយស្រួលនៃការប្រើប្រាស់ YugaByte DB ភ្ជាប់មកជាមួយ cqlsh នៅក្នុងកាតាឡុក bin.
ចំណាំថា CQL ត្រូវបានបំផុសគំនិតដោយ SQL និងមានគោលគំនិតស្រដៀងគ្នានៃតារាង ជួរដេក ជួរឈរ និងលិបិក្រម។ ទោះយ៉ាងណាក៏ដោយ ជាភាសា NoSQL វាបន្ថែមការកំណត់ជាក់លាក់មួយ ដែលភាគច្រើនយើងនឹងរៀបរាប់នៅក្នុងអត្ថបទផ្សេងទៀតផងដែរ។

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

MongoDB

mongo គឺជាសែលបន្ទាត់ពាក្យបញ្ជាសម្រាប់ធ្វើអន្តរកម្មជាមួយ MongoDB ។ វាអាចត្រូវបានរកឃើញនៅក្នុង bin directory នៃការដំឡើង MongoDB ។

docker exec -it my-mongo bash 
cd bin
mongo

ការបង្កើតតារាង

ឥឡូវនេះយើងអាចធ្វើអន្តរកម្មជាមួយមូលដ្ឋានទិន្នន័យដើម្បីអនុវត្តប្រតិបត្តិការផ្សេងៗដោយប្រើបន្ទាត់ពាក្យបញ្ជា។ ចូរចាប់ផ្តើមដោយបង្កើតតារាងដែលរក្សាទុកព័ត៌មានអំពីបទចម្រៀងដែលនិពន្ធដោយសិល្បករផ្សេងៗគ្នា។ បទចម្រៀងទាំងនេះអាចជាផ្នែកមួយនៃអាល់ប៊ុម។ គុណលក្ខណៈជាជម្រើសសម្រាប់បទចម្រៀងមួយគឺឆ្នាំនៃការចេញផ្សាយ តម្លៃ ប្រភេទ និងការវាយតម្លៃ។ យើងត្រូវគិតគូរអំពីគុណលក្ខណៈបន្ថែមដែលអាចត្រូវការនាពេលអនាគតតាមរយៈវាល "ស្លាក" ។ វាអាចរក្សាទុកទិន្នន័យពាក់កណ្តាលរចនាសម្ព័ន្ធក្នុងទម្រង់ជាគូតម្លៃគន្លឹះ។

PostgreSQL

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);	

Cassandra

ការបង្កើតតារាងនៅក្នុង Cassandra គឺស្រដៀងទៅនឹង PostgreSQL ។ ភាពខុសប្លែកគ្នាដ៏សំខាន់មួយគឺការខ្វះការរឹតត្បិតភាពសុចរិត (ឧ. មិនមែន NULL) ប៉ុន្តែនេះគឺជាទំនួលខុសត្រូវរបស់កម្មវិធី មិនមែនជាមូលដ្ឋានទិន្នន័យ NoSQL ទេ។. សោចម្បងមានសោភាគថាស (ជួរឈរសិល្បករក្នុងឧទាហរណ៍ខាងក្រោម) និងសំណុំនៃជួរឈរចង្កោម (ជួរឈរ SongTitle ក្នុងឧទាហរណ៍ខាងក្រោម)។ គ្រាប់ចុចភាគថាសកំណត់ថាតើភាគថាស/ភាគថាសមួយណាគួរតែដាក់ជួរដេកចូល ហើយជួរឈរចង្កោមបង្ហាញពីរបៀបដែលទិន្នន័យគួរតែត្រូវបានរៀបចំនៅក្នុង shard បច្ចុប្បន្ន។

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

MongoDB

MongoDB រៀបចំទិន្នន័យចូលទៅក្នុងមូលដ្ឋានទិន្នន័យ (Database) (ស្រដៀងទៅនឹង Keyspace នៅក្នុង Cassandra) ដែលនៅទីនោះមានបណ្តុំ (ស្រដៀងនឹងតារាង) ដែលមានឯកសារ (ស្រដៀងនឹងជួរដេកក្នុងតារាង)។ នៅក្នុង MongoDB ជាមូលដ្ឋានមិនចាំបាច់កំណត់គ្រោងការណ៍ដំបូងទេ។ ក្រុម "ប្រើមូលដ្ឋានទិន្នន័យ"បង្ហាញខាងក្រោម ធ្វើឱ្យមូលដ្ឋានទិន្នន័យភ្លាមៗនៅលើការហៅទូរសព្ទលើកដំបូង និងផ្លាស់ប្តូរបរិបទសម្រាប់មូលដ្ឋានទិន្នន័យដែលបានបង្កើតថ្មី។ សូម្បីតែបណ្តុំក៏មិនចាំបាច់បង្កើតឱ្យច្បាស់លាស់ដែរ វាត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិ នៅពេលអ្នកបន្ថែមឯកសារដំបូងទៅបណ្តុំថ្មី។ ចំណាំថា MongoDB ប្រើមូលដ្ឋានទិន្នន័យសាកល្បងតាមលំនាំដើម ដូច្នេះប្រតិបត្តិការកម្រិតប្រមូលណាមួយដោយមិនបញ្ជាក់មូលដ្ឋានទិន្នន័យជាក់លាក់នឹងដំណើរការលើវាតាមលំនាំដើម។

use myNewDatabase;

ទទួលបានព័ត៌មានអំពីតារាង
PostgreSQL

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

Cassandra

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

MongoDB

use myNewDatabase;
show collections;

ការបញ្ចូលទិន្នន័យទៅក្នុងតារាង
PostgreSQL

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

Cassandra

ការបញ្ចេញមតិរួម INSERT នៅក្នុង Cassandra មើលទៅស្រដៀងនឹងវានៅក្នុង PostgreSQL ។ ទោះយ៉ាងណាក៏ដោយ មានភាពខុសប្លែកគ្នាដ៏ធំមួយនៅក្នុងន័យវិទ្យា។ នៅ Cassandra INSERT តាមពិតគឺជាប្រតិបត្តិការមួយ។ UPSERTដែលជាកន្លែងដែលតម្លៃចុងក្រោយត្រូវបានបន្ថែមទៅជួរដេកប្រសិនបើជួរដេកមានរួចហើយ។

ការបញ្ចូលទិន្នន័យគឺស្រដៀងនឹង PostgreSQL INSERT ខ្ពស់ជាងនេះ

.

MongoDB

ទោះបីជា MongoDB គឺជាមូលដ្ឋានទិន្នន័យ NoSQL ដូច Cassandra ក៏ដោយ ប្រតិបត្តិការនៃការបញ្ចូលរបស់វាមិនមានអ្វីដូចគ្នាជាមួយនឹងអាកប្បកិរិយា semantic របស់ Cassandra ។ នៅ MongoDB បញ្ចូល () មិនមានឱកាសទេ។ UPSERTដែលធ្វើឱ្យវាស្រដៀងទៅនឹង PostgreSQL ។ ការបន្ថែមទិន្នន័យលំនាំដើមដោយគ្មាន _idspecified នឹងធ្វើឱ្យឯកសារថ្មីត្រូវបានបន្ថែមទៅបណ្តុំ។

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

សំណួរតារាង

ប្រហែលជាភាពខុសគ្នាដ៏សំខាន់បំផុតរវាង SQL និង NoSQL នៅក្នុងលក្ខខណ្ឌនៃការសាងសង់សំណួរគឺជាភាសាដែលបានប្រើ FROM и WHERE. SQL អនុញ្ញាតបន្ទាប់ពីការបញ្ចេញមតិ FROM ជ្រើសរើសតារាងច្រើន និងកន្សោមជាមួយ WHERE អាចមានភាពស្មុគស្មាញណាមួយ (រួមទាំងប្រតិបត្តិការ JOIN រវាងតុ) ។ ទោះយ៉ាងណាក៏ដោយ NoSQL មានទំនោរនឹងដាក់កម្រិតធ្ងន់ធ្ងរ FROMនិងធ្វើការតែជាមួយតារាងដែលបានបញ្ជាក់មួយ និងនៅក្នុង WHEREកូនសោចម្បងត្រូវតែបញ្ជាក់ជានិច្ច។ នេះភ្ជាប់ទៅនឹងការជំរុញការអនុវត្ត NoSQL ដែលយើងបាននិយាយពីមុន។ បំណងប្រាថ្នានេះនាំទៅរកការកាត់បន្ថយដែលអាចកើតមាននៅក្នុងអន្តរកម្មឆ្លងតារាង និងគន្លឹះឆ្លង។ វាអាចណែនាំការពន្យាពេលដ៏ធំមួយក្នុងការទំនាក់ទំនងអន្តរថ្នាំង នៅពេលឆ្លើយតបនឹងសំណើ ហើយដូច្នេះជាទូទៅជៀសវាងបានល្អបំផុត។ ឧទាហរណ៍ Cassandra តម្រូវឱ្យសំណួរត្រូវបានកំណត់ចំពោះប្រតិបត្តិករជាក់លាក់ (សម្រាប់តែ =, IN, <, >, =>, <=) នៅលើសោភាគថាស លើកលែងតែពេលស្នើសុំលិបិក្រមបន្ទាប់បន្សំ (មានតែប្រតិបត្តិករ = ត្រូវបានអនុញ្ញាតនៅទីនេះ)។

PostgreSQL

ខាងក្រោមនេះជាឧទាហរណ៍បីនៃសំណួរដែលអាចត្រូវបានប្រតិបត្តិយ៉ាងងាយស្រួលដោយមូលដ្ឋានទិន្នន័យ SQL ។

• បង្ហាញបទចម្រៀងទាំងអស់ដោយសិល្បករ;
• បង្ហាញបទចម្រៀងទាំងអស់ដោយសិល្បករដែលត្រូវនឹងផ្នែកដំបូងនៃចំណងជើង។
• បង្ហាញបទចម្រៀងទាំងអស់ដោយសិល្បករដែលមានពាក្យជាក់លាក់នៅក្នុងចំណងជើង និងមានតម្លៃតិចជាង 1.00។

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

Cassandra

ក្នុងចំណោមសំណួរ PostgreSQL ដែលបានរាយខាងលើ មានតែសំណួរទីមួយប៉ុណ្ណោះដែលនឹងដំណើរការមិនផ្លាស់ប្តូរនៅក្នុង Cassandra ចាប់តាំងពីប្រតិបត្តិករ LIKE មិន​អាច​ត្រូវ​បាន​អនុវត្ត​ទៅ​នឹង​ជួរ​ឈរ​ជា​ក្រុម​ដូច​ជា SongTitle. ក្នុងករណីនេះមានតែប្រតិបត្តិករប៉ុណ្ណោះដែលត្រូវបានអនុញ្ញាត = и IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

MongoDB

ដូចដែលបានបង្ហាញនៅក្នុងឧទាហរណ៍មុន វិធីសាស្ត្រសំខាន់សម្រាប់បង្កើតសំណួរនៅក្នុង MongoDB គឺ db.collection.find(). វិធីសាស្រ្តនេះមានឈ្មោះនៃបណ្តុំ (music ក្នុងឧទាហរណ៍ខាងក្រោម) ដូច្នេះការសាកសួរបណ្តុំច្រើនត្រូវបានហាមឃាត់។

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

ការអានជួរទាំងអស់នៃតារាង

ការអានជួរទាំងអស់គ្រាន់តែជាករណីពិសេសនៃគំរូសំណួរដែលយើងបានមើលពីមុន។

PostgreSQL

SELECT * 
FROM Music;

Cassandra

ស្រដៀងទៅនឹងឧទាហរណ៍ PostgreSQL ខាងលើ។

MongoDB

db.music.find( {} );

ការកែសម្រួលទិន្នន័យក្នុងតារាង

PostgreSQL

PostgreSQL ផ្តល់ការណែនាំ UPDATE ដើម្បីផ្លាស់ប្តូរទិន្នន័យ។ នាងគ្មានឱកាសទេ។ UPSERTដូច្នេះសេចក្តីថ្លែងការណ៍នេះនឹងបរាជ័យ ប្រសិនបើជួរដេកលែងនៅក្នុងមូលដ្ឋានទិន្នន័យ។

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

Cassandra

Cassandra មាន UPDATE ស្រដៀងទៅនឹង PostgreSQL ។ UPDATE មានអត្ថន័យដូចគ្នា។ UPSERT, ស្រដៀងគ្នា INSERT.

ស្រដៀងទៅនឹងឧទាហរណ៍ PostgreSQL ខាងលើ។

MongoDB
ប្រតិបត្តិការ ធ្វើបច្ចុប្បន្នភាព () នៅក្នុង MongoDB អាចធ្វើបច្ចុប្បន្នភាពទាំងស្រុងនូវឯកសារដែលមានស្រាប់ ឬធ្វើបច្ចុប្បន្នភាពតែវាលជាក់លាក់ប៉ុណ្ណោះ។ តាមលំនាំដើម វាធ្វើបច្ចុប្បន្នភាពតែឯកសារមួយប៉ុណ្ណោះ ជាមួយនឹងការបិទការយល់ឃើញ UPSERT. ការធ្វើបច្ចុប្បន្នភាពឯកសារជាច្រើន និងឥរិយាបថស្រដៀងគ្នា UPSERT អាចត្រូវបានអនុវត្តដោយការកំណត់ទង់បន្ថែមសម្រាប់ប្រតិបត្តិការ។ ជាឧទាហរណ៍ ក្នុងឧទាហរណ៍ខាងក្រោម ប្រភេទនៃសិល្បករជាក់លាក់មួយត្រូវបានធ្វើបច្ចុប្បន្នភាពដោយផ្អែកលើបទចម្រៀងរបស់គាត់។

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

ការដកទិន្នន័យចេញពីតារាង

PostgreSQL

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

Cassandra

ស្រដៀងទៅនឹងឧទាហរណ៍ PostgreSQL ខាងលើ។

MongoDB

MongoDB មានប្រតិបត្តិការពីរប្រភេទដើម្បីលុបឯកសារ − លុបមួយ() /deleteMany() и យក (). ប្រភេទទាំងពីរលុបឯកសារ ប៉ុន្តែផ្តល់លទ្ធផលខុសគ្នា។

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

ការលុបតារាង

PostgreSQL

DROP TABLE Music;

Cassandra

ស្រដៀងទៅនឹងឧទាហរណ៍ PostgreSQL ខាងលើ។

MongoDB

db.music.drop();

សេចក្តីសន្និដ្ឋាន

ការជជែកវែកញែកអំពីការជ្រើសរើសរវាង SQL និង NoSQL បានផ្ទុះឡើងអស់រយៈពេលជាង 10 ឆ្នាំមកហើយ។ មានទិដ្ឋភាពសំខាន់ពីរចំពោះការជជែកដេញដោលនេះ៖ ស្ថាបត្យកម្មម៉ាស៊ីនមូលដ្ឋានទិន្នន័យ (monolithic, ប្រតិបត្តិការ SQL ទល់នឹងការចែកចាយ, NoSQL ដែលមិនមានប្រតិបត្តិការ) និងវិធីសាស្រ្តរចនាមូលដ្ឋានទិន្នន័យ (ការធ្វើគំរូទិន្នន័យរបស់អ្នកនៅក្នុង SQL ធៀបនឹងការធ្វើគំរូសំណួររបស់អ្នកនៅក្នុង NoSQL) ។

ជាមួយនឹងមូលដ្ឋានទិន្នន័យប្រតិបត្តិការដែលបានចែកចាយដូចជា YugaByte DB ការពិភាក្សាអំពីស្ថាបត្យកម្មមូលដ្ឋានទិន្នន័យអាចត្រូវបានសម្រាកយ៉ាងងាយស្រួល។ ដោយសារទំហំទិន្នន័យធំជាងអ្វីដែលអាចត្រូវបានសរសេរទៅថ្នាំងតែមួយ ស្ថាបត្យកម្មដែលបានចែកចាយពេញលេញដែលគាំទ្រលទ្ធភាពនៃការសរសេរលីនេអ៊ែរជាមួយនឹងការបំបែក/ការធ្វើឱ្យមានតុល្យភាពដោយស្វ័យប្រវត្តិក្លាយជាចាំបាច់។

លើសពីនេះ ដូចមានចែងក្នុងអត្ថបទមួយ។ Google Cloud ស្ថាបត្យកម្ម​ដែល​មាន​ប្រតិបត្តិការ​ស្រប​គ្នា​ខ្លាំង​ឥឡូវ​នេះ​គឺ​ត្រូវ​បាន​ប្រើ​ច្រើន​ដើម្បី​ផ្តល់​ភាព​រហ័ស​រហួន​ក្នុង​ការ​អភិវឌ្ឍ​ជា​ជាង​ស្ថាបត្យកម្ម​ដែល​មិន​ធ្វើ​ប្រតិបត្តិការ​ ហើយ​នៅ​ទីបំផុត​ស្ថាបត្យកម្ម​ស្រប​គ្នា។

ត្រលប់មកការពិភាក្សាការរចនាមូលដ្ឋានទិន្នន័យវិញ វាជាការត្រឹមត្រូវក្នុងការនិយាយថាវិធីសាស្រ្តរចនាទាំងពីរ (SQL និង NoSQL) គឺចាំបាច់សម្រាប់កម្មវិធីពិភពពិតដ៏ស្មុគស្មាញណាមួយ។ វិធីសាស្រ្ត "គំរូទិន្នន័យ" របស់ SQL អនុញ្ញាតឱ្យអ្នកអភិវឌ្ឍន៍កាន់តែងាយស្រួលបំពេញតាមតម្រូវការអាជីវកម្មដែលផ្លាស់ប្តូរ ខណៈពេលដែល NoSQL "គំរូសំណួរ" អនុញ្ញាតឱ្យអ្នកអភិវឌ្ឍន៍ដូចគ្នាធ្វើប្រតិបត្តិការលើបរិមាណដ៏ធំនៃទិន្នន័យដែលមានភាពយឺតយ៉ាវទាប និងចរន្តខ្ពស់។ វាគឺសម្រាប់ហេតុផលនេះដែល YugaByte DB ផ្តល់នូវ SQL និង NoSQL APIs នៅក្នុងស្នូលទូទៅ ជាជាងការលើកកម្ពស់វិធីសាស្រ្តមួយ។ លើសពីនេះទៀតដោយការផ្តល់នូវភាពឆបគ្នាជាមួយភាសាមូលដ្ឋានទិន្នន័យពេញនិយមរួមទាំង PostgreSQL និង Cassandra YugaByte DB ធានាថាអ្នកអភិវឌ្ឍន៍មិនចាំបាច់រៀនភាសាផ្សេងទៀតដើម្បីធ្វើការជាមួយម៉ាស៊ីនមូលដ្ឋានទិន្នន័យដែលចែកចាយ និងស្របគ្នាខ្ពស់។

នៅក្នុងអត្ថបទនេះ យើងបានមើលពីរបៀបដែលមូលដ្ឋានគ្រឹះនៃការរចនាមូលដ្ឋានទិន្នន័យខុសគ្នារវាង PostgreSQL, Cassandra និង MongoDB។ នៅក្នុងអត្ថបទនាពេលអនាគត យើងនឹងចូលទៅក្នុងគំនិតរចនាកម្រិតខ្ពស់ដូចជា លិបិក្រម ប្រតិបត្តិការ ចូលរួម ការណែនាំ TTL និងឯកសារ JSON ។

យើងសូមជូនពរឱ្យអ្នកសម្រាកដ៏អស្ចារ្យនៅចុងសប្តាហ៍ហើយអញ្ជើញអ្នកឱ្យទៅ webinar ឥតគិតថ្លៃដែលនឹងប្រព្រឹត្តទៅនៅថ្ងៃទី ១៤ ខែឧសភា។

ប្រភព: www.habr.com