โปรโฮสต์ > บล็อก > การบริหาร > พื้นฐานการออกแบบฐานข้อมูล - การเปรียบเทียบ PostgreSQL, Cassandra และ MongoDB

พื้นฐานการออกแบบฐานข้อมูล - การเปรียบเทียบ PostgreSQL, Cassandra และ MongoDB

สวัสดีเพื่อน. ก่อนออกเดินทางในช่วงที่สองของวันหยุดเดือนพฤษภาคม เราจะแบ่งปันเนื้อหาที่เราแปลกับคุณโดยคาดว่าจะมีการเปิดตัวสตรีมใหม่ในหลักสูตร "DBMS เชิงสัมพันธ์".

พื้นฐานการออกแบบฐานข้อมูล - การเปรียบเทียบ PostgreSQL, Cassandra และ MongoDB

นักพัฒนาแอปพลิเคชันใช้เวลาส่วนใหญ่ในการเปรียบเทียบฐานข้อมูลการปฏิบัติงานหลายฐานข้อมูล เพื่อเลือกฐานข้อมูลที่เหมาะสมกับปริมาณงานที่ต้องการมากที่สุด ความต้องการอาจรวมถึงการสร้างแบบจำลองข้อมูลที่ง่ายขึ้น การรับประกันธุรกรรม ประสิทธิภาพการอ่าน/เขียน มาตราส่วนแนวนอน และความทนทานต่อข้อผิดพลาด โดยทั่วไป ตัวเลือกจะเริ่มต้นด้วยหมวดหมู่ฐานข้อมูล นั่นคือ SQL หรือ NoSQL เนื่องจากแต่ละหมวดหมู่มีข้อดีข้อเสียที่ชัดเจน โดยทั่วไปแล้ว ประสิทธิภาพสูงในแง่ของเวลาแฝงต่ำและปริมาณงานสูงนั้นถือเป็นข้อกำหนดที่ไม่ต้องมีการแลกเปลี่ยน และดังนั้นจึงจำเป็นสำหรับฐานข้อมูลตัวอย่างใดๆ

วัตถุประสงค์ของบทความนี้คือเพื่อช่วยให้นักพัฒนาแอปพลิเคชันตัดสินใจได้ถูกต้องระหว่าง SQL และ NoSQL ในบริบทของการสร้างแบบจำลองข้อมูลแอปพลิเคชัน เราจะดูฐานข้อมูล SQL หนึ่งฐานข้อมูล ได้แก่ PostgreSQL และฐานข้อมูล NoSQL สองฐานข้อมูล Cassandra และ MongoDB เพื่อครอบคลุมพื้นฐานของการออกแบบฐานข้อมูล เช่น การสร้างตาราง การเติมข้อมูลในตาราง การอ่านข้อมูลจากตาราง และการลบออก ในบทความถัดไป เราจะดูที่ดัชนี ธุรกรรม JOIN คำสั่ง TTL และการออกแบบฐานข้อมูลที่ใช้ JSON

ความแตกต่างระหว่าง SQL และ NoSQL คืออะไร?

ฐานข้อมูล SQL เพิ่มความยืดหยุ่นของแอปพลิเคชันผ่านการรับประกันธุรกรรมของ ACID เช่นเดียวกับความสามารถในการสืบค้นข้อมูลโดยใช้ JOIN ด้วยวิธีที่ไม่คาดคิด นอกเหนือจากโมเดลฐานข้อมูลเชิงสัมพันธ์มาตรฐานที่มีอยู่

ด้วยสถาปัตยกรรมแบบโมโนลิธิก/โหนดเดียว และการใช้แบบจำลองการจำลองแบบมาสเตอร์-สเลฟเพื่อความซ้ำซ้อน ฐานข้อมูล SQL แบบดั้งเดิมจึงขาดคุณสมบัติที่สำคัญสองประการ ได้แก่ ความสามารถในการปรับขนาดการเขียนเชิงเส้น (เช่น การแบ่งพาร์ติชันอัตโนมัติระหว่างหลายโหนด) และการสูญเสียข้อมูลอัตโนมัติ/เป็นศูนย์ ซึ่งหมายความว่าจำนวนข้อมูลที่ได้รับจะต้องไม่เกินปริมาณการประมวลผลการเขียนสูงสุดของโหนดเดียว นอกจากนี้ การสูญเสียข้อมูลชั่วคราวบางส่วนจะต้องนำมาพิจารณาในเรื่องความทนทานต่อข้อผิดพลาด (ในสถาปัตยกรรมที่ไม่มีการแบ่งปัน) ที่นี่คุณต้องจำไว้ว่าการคอมมิตล่าสุดยังไม่สะท้อนให้เห็นในสำเนาทาส การอัพเดตแบบไม่หยุดทำงานยังทำได้ยากในฐานข้อมูล SQL

ฐานข้อมูล NoSQL มักมีการกระจายตามธรรมชาติ เช่น ข้อมูลจะถูกแบ่งออกเป็นส่วนๆ และกระจายไปตามโหนดต่างๆ พวกเขาต้องการการทำให้เป็นปกติ ซึ่งหมายความว่าข้อมูลที่ป้อนจะต้องถูกคัดลอกหลายครั้งเพื่อตอบสนองต่อคำขอเฉพาะที่คุณส่ง เป้าหมายโดยรวมคือการได้รับประสิทธิภาพสูงโดยการลดจำนวนชาร์ดที่มีอยู่ระหว่างการอ่าน นี่หมายความว่า NoSQL ต้องการให้คุณสร้างโมเดลการสืบค้นของคุณ ในขณะที่ SQL ต้องการให้คุณสร้างโมเดลข้อมูลของคุณ

NoSQL มุ่งเน้นไปที่การบรรลุประสิทธิภาพสูงในคลัสเตอร์แบบกระจาย และนี่คือเหตุผลเบื้องหลังสำหรับการแลกเปลี่ยนการออกแบบฐานข้อมูลจำนวนมาก ซึ่งรวมถึงการสูญเสียธุรกรรม ACID, JOIN และดัชนีรองทั่วโลกที่สอดคล้องกัน

มีข้อโต้แย้งว่าในขณะที่ฐานข้อมูล NoSQL ให้ความสามารถในการปรับขนาดการเขียนเชิงเส้นและความทนทานต่อข้อผิดพลาดสูง การสูญเสียการรับประกันธุรกรรมทำให้ไม่เหมาะสมสำหรับข้อมูลที่มีความสำคัญต่อภารกิจ

ตารางต่อไปนี้แสดงให้เห็นว่าการสร้างแบบจำลองข้อมูลใน NoSQL แตกต่างจาก SQL อย่างไร

พื้นฐานการออกแบบฐานข้อมูล - การเปรียบเทียบ PostgreSQL, Cassandra และ MongoDB

SQL และ NoSQL: เหตุใดจึงจำเป็นทั้งสองอย่าง

แอปพลิเคชันในโลกแห่งความเป็นจริงที่มีผู้ใช้จำนวนมาก เช่น Amazon.com, Netflix, Uber และ Airbnb ได้รับมอบหมายให้ทำงานที่ซับซ้อนและหลากหลายแง่มุม ตัวอย่างเช่น แอปพลิเคชันอีคอมเมิร์ซอย่าง Amazon.com จำเป็นต้องจัดเก็บข้อมูลที่ไม่ซับซ้อนและมีความสำคัญสูง เช่น ข้อมูลผู้ใช้ ผลิตภัณฑ์ คำสั่งซื้อ ใบแจ้งหนี้ พร้อมด้วยข้อมูลที่มีความสำคัญและมีความสำคัญน้อยกว่า เช่น บทวิจารณ์ผลิตภัณฑ์ ข้อความสนับสนุน กิจกรรมของผู้ใช้ บทวิจารณ์และคำแนะนำของผู้ใช้ โดยปกติแล้ว แอปพลิเคชันเหล่านี้ต้องอาศัยฐานข้อมูล SQL อย่างน้อยหนึ่งฐานข้อมูลพร้อมกับฐานข้อมูล NoSQL อย่างน้อยหนึ่งฐานข้อมูล ในระบบข้ามภูมิภาคและระดับโลก ฐานข้อมูล NoSQL ทำงานเป็นแคชที่กระจายตามภูมิศาสตร์สำหรับข้อมูลที่จัดเก็บไว้ในฐานข้อมูล SQL ต้นทางที่เชื่อถือได้ซึ่งทำงานในภูมิภาคเดียว

YugaByte DB รวม SQL และ NoSQL อย่างไร

YugaByte DB สร้างขึ้นจากกลไกการจัดเก็บข้อมูลแบบผสมที่เน้นการบันทึก การแบ่งส่วนอัตโนมัติ การจำลองแบบฉันทามติแบบแบ่งส่วน และธุรกรรมแบบกระจาย 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 ในบริบทของข้อมูลที่มีความสำคัญต่อภารกิจได้

พื้นฐานการออกแบบฐานข้อมูล - การเปรียบเทียบ PostgreSQL, Cassandra และ MongoDB

ตามที่ระบุไว้ก่อนหน้านี้ในบทความ "ขอแนะนำ YSQL: API SQL แบบกระจายที่เข้ากันได้กับ PostgreSQL สำหรับ YugaByte DB"การเลือกระหว่าง SQL หรือ NoSQL ใน YugaByte DB ขึ้นอยู่กับลักษณะของปริมาณงานพื้นฐานทั้งหมด:

  • หากปริมาณงานหลักของคุณคือการดำเนินการ JOIN แบบหลายคีย์ เมื่อเลือก YSQL โปรดเข้าใจว่าคีย์ของคุณอาจถูกกระจายไปยังหลายโหนด ส่งผลให้เวลาแฝงสูงขึ้น และ/หรือปริมาณงานต่ำกว่า NoSQL
  • หรือเลือก NoSQL API อันใดอันหนึ่งจากทั้งสองอัน โปรดทราบว่าคุณจะได้รับประสิทธิภาพที่ดีขึ้นอันเป็นผลมาจากการสืบค้นที่เสิร์ฟจากโหนดเดียวในแต่ละครั้ง YugaByte DB สามารถทำหน้าที่เป็นฐานข้อมูลการดำเนินงานเดียวสำหรับแอปพลิเคชันที่ซับซ้อนในโลกแห่งความเป็นจริง ซึ่งจำเป็นต้องจัดการปริมาณงานหลายรายการพร้อมกัน

แล็บการสร้างแบบจำลองข้อมูลในส่วนถัดไปจะขึ้นอยู่กับฐานข้อมูล YugaByte DB ที่เข้ากันได้กับ PostgreSQL และ Cassandra API ซึ่งต่างจากฐานข้อมูลดั้งเดิม แนวทางนี้เน้นความง่ายในการโต้ตอบกับ API สองตัวที่แตกต่างกัน (บนพอร์ตที่แตกต่างกันสองพอร์ต) ของคลัสเตอร์ฐานข้อมูลเดียวกัน แทนที่จะใช้คลัสเตอร์ที่เป็นอิสระอย่างสมบูรณ์ของฐานข้อมูลสองฐานข้อมูลที่แตกต่างกัน
ในส่วนต่อไปนี้ เราจะดูแล็บการสร้างแบบจำลองข้อมูลเพื่ออธิบายความแตกต่างและความเหมือนกันบางประการของฐานข้อมูลที่ครอบคลุม

ห้องปฏิบัติการการสร้างแบบจำลองข้อมูล

การติดตั้งฐานข้อมูล

ด้วยการเน้นที่การออกแบบโมเดลข้อมูล (แทนที่จะเป็นสถาปัตยกรรมการปรับใช้ที่ซับซ้อน) เราจะติดตั้งฐานข้อมูลในคอนเทนเนอร์ Docker บนเครื่องท้องถิ่น จากนั้นโต้ตอบกับฐานข้อมูลเหล่านั้นโดยใช้เชลล์บรรทัดคำสั่งที่เกี่ยวข้อง

ฐานข้อมูล YugaByte DB ที่เข้ากันได้กับ PostgreSQL และ Cassandra

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

การเข้าถึงบรรทัดคำสั่ง

มาเชื่อมต่อกับฐานข้อมูลโดยใช้เชลล์บรรทัดคำสั่งสำหรับ API ที่เกี่ยวข้อง

PostgreSQL

psql เป็นเชลล์บรรทัดคำสั่งสำหรับการโต้ตอบกับ PostgreSQL เพื่อความสะดวกในการใช้งาน YugaByte DB จะมาพร้อมกับ psql ในโฟลเดอร์ bin

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

คาสซานดรา

cqlsh เป็นเชลล์บรรทัดคำสั่งสำหรับการโต้ตอบกับ Cassandra และฐานข้อมูลที่เข้ากันได้ผ่าน CQL (Cassandra Query Language) เพื่อความสะดวกในการใช้งาน YugaByte DB มาพร้อม cqlsh ในแคตตาล็อก bin.
โปรดทราบว่า CQL ได้รับแรงบันดาลใจจาก SQL และมีแนวคิดเกี่ยวกับตาราง แถว คอลัมน์ และดัชนีที่คล้ายกัน อย่างไรก็ตาม เนื่องจากเป็นภาษา NoSQL จึงได้เพิ่มข้อจำกัดบางประการ ซึ่งส่วนใหญ่จะกล่าวถึงในบทความอื่นๆ ด้วย

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

MongoDB

Mongo เป็นเชลล์บรรทัดคำสั่งสำหรับการโต้ตอบกับ MongoDB สามารถพบได้ในไดเร็กทอรี bin ของการติดตั้ง 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 นั้นคล้ายกับ PostgreSQL มาก ความแตกต่างหลักประการหนึ่งคือการไม่มีข้อจำกัดด้านความสมบูรณ์ (เช่น ไม่เป็นโมฆะ) แต่นี่เป็นความรับผิดชอบของแอปพลิเคชัน ไม่ใช่ฐานข้อมูล NoSQL. คีย์หลักประกอบด้วยคีย์พาร์ติชัน (คอลัมน์ศิลปินในตัวอย่างด้านล่าง) และชุดของคอลัมน์การจัดกลุ่ม (คอลัมน์ SongTitle ในตัวอย่างด้านล่าง) คีย์พาร์ติชั่นจะกำหนดพาร์ติชั่น/ส่วนแบ่งข้อมูลที่ควรวางแถวไว้ และคอลัมน์การจัดกลุ่มจะระบุวิธีการจัดระเบียบข้อมูลภายในส่วนแบ่งข้อมูลปัจจุบัน

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 จัดระเบียบข้อมูลลงในฐานข้อมูล (ฐานข้อมูล) (คล้ายกับ 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)

คาสซานดรา 

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}'
);

คาสซานดรา

การแสดงออกโดยรวม INSERT ใน Cassandra ดูคล้ายกับใน PostgreSQL มาก อย่างไรก็ตาม มีความแตกต่างใหญ่ประการหนึ่งในด้านความหมาย ในคาสซานดรา INSERT จริงๆ แล้วเป็นการผ่าตัด UPSERTโดยที่ค่าสุดท้ายจะถูกเพิ่มลงในแถวหากมีแถวอยู่แล้ว

การป้อนข้อมูลจะคล้ายกับ PostgreSQL INSERT เหนือ

.

MongoDB

แม้ว่า MongoDB จะเป็นฐานข้อมูล NoSQL เช่น Cassandra แต่การดำเนินการแทรกไม่มีอะไรที่เหมือนกันกับพฤติกรรมเชิงความหมายของ 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;

คาสซานดรา

จากการสืบค้น 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;

คาสซานดรา

คล้ายกับตัวอย่าง PostgreSQL ด้านบน

MongoDB

db.music.find( {} );

การแก้ไขข้อมูลในตาราง

PostgreSQL

PostgreSQL ให้คำแนะนำ UPDATE เพื่อเปลี่ยนข้อมูล เธอไม่มีโอกาส UPSERTดังนั้นคำสั่งนี้จะล้มเหลวหากแถวไม่อยู่ในฐานข้อมูลอีกต่อไป

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

คาสซานดรา

แคสแซนดราก็มี 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';

คาสซานดรา

คล้ายกับตัวอย่าง PostgreSQL ด้านบน

MongoDB

MongoDB มีการดำเนินการสองประเภทในการลบเอกสาร - ลบหนึ่ง() /ลบหลาย() и ลบ (). ทั้งสองประเภทจะลบเอกสาร แต่ให้ผลลัพธ์ต่างกัน 

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

การลบตาราง

PostgreSQL

DROP TABLE Music;

คาสซานดรา

คล้ายกับตัวอย่าง PostgreSQL ด้านบน

MongoDB

db.music.drop();

ข้อสรุป

การถกเถียงเกี่ยวกับการเลือกระหว่าง SQL และ NoSQL เกิดขึ้นมานานกว่า 10 ปีแล้ว การอภิปรายนี้มีสองประเด็นหลัก: สถาปัตยกรรมกลไกฐานข้อมูล (เสาหิน, SQL ธุรกรรมเทียบกับการกระจาย, NoSQL ที่ไม่ใช่ธุรกรรม) และวิธีการออกแบบฐานข้อมูล (การสร้างแบบจำลองข้อมูลของคุณใน SQL เทียบกับการสร้างแบบจำลองการสืบค้นของคุณใน NoSQL)

ด้วยฐานข้อมูลธุรกรรมแบบกระจายเช่น YugaByte DB การถกเถียงเกี่ยวกับสถาปัตยกรรมฐานข้อมูลจึงสามารถยุติได้ง่าย เนื่องจากปริมาณข้อมูลมีขนาดใหญ่เกินกว่าที่สามารถเขียนลงในโหนดเดียวได้ สถาปัตยกรรมแบบกระจายเต็มรูปแบบที่รองรับความสามารถในการปรับขนาดการเขียนเชิงเส้นด้วยการแบ่งส่วน/การปรับสมดุลอัตโนมัติจึงกลายเป็นสิ่งจำเป็น

นอกจากนี้ตามที่ระบุไว้ในบทความหนึ่ง Google Cloud,สถาปัตยกรรมทางธุรกรรมที่มีความสอดคล้องอย่างยิ่งในปัจจุบันถูกนำมาใช้เพื่อให้เกิดความคล่องตัวในการพัฒนาที่ดีกว่าสถาปัตยกรรมที่ไม่เกี่ยวกับการทำธุรกรรม และในที่สุดสถาปัตยกรรมก็จะมีความสอดคล้องกัน

กลับมาที่การอภิปรายเกี่ยวกับการออกแบบฐานข้อมูล มีความยุติธรรมที่จะกล่าวว่าแนวทางการออกแบบทั้งสอง (SQL และ NoSQL) จำเป็นสำหรับแอปพลิเคชันที่ซับซ้อนในโลกแห่งความเป็นจริง แนวทาง "การสร้างแบบจำลองข้อมูล" ของ SQL ช่วยให้นักพัฒนาสามารถตอบสนองความต้องการทางธุรกิจที่เปลี่ยนแปลงได้ง่ายขึ้น ในขณะที่แนวทาง "การสร้างแบบจำลองแบบสอบถาม" ของ NoSQL ช่วยให้นักพัฒนาคนเดียวกันสามารถทำงานกับข้อมูลปริมาณมากโดยมีความหน่วงต่ำและมีปริมาณงานสูง ด้วยเหตุนี้ YugaByte DB จึงจัดเตรียม SQL และ NoSQL APIs ในแกนหลักทั่วไป แทนที่จะส่งเสริมแนวทางใดแนวทางหนึ่ง นอกจากนี้ ด้วยการให้ความเข้ากันได้กับภาษาฐานข้อมูลยอดนิยม รวมถึง PostgreSQL และ Cassandra ทำให้ YugaByte DB ช่วยให้มั่นใจได้ว่านักพัฒนาไม่จำเป็นต้องเรียนรู้ภาษาอื่นเพื่อทำงานกับกลไกฐานข้อมูลแบบกระจายที่มีความสอดคล้องสูง

ในบทความนี้ เราได้พิจารณาว่าพื้นฐานการออกแบบฐานข้อมูลแตกต่างกันอย่างไรระหว่าง PostgreSQL, Cassandra และ MongoDB ในบทความต่อๆ ไป เราจะเจาะลึกแนวคิดการออกแบบขั้นสูง เช่น ดัชนี ธุรกรรม JOIN คำสั่ง TTL และเอกสาร JSON

เราหวังว่าคุณจะได้พักผ่อนในช่วงสุดสัปดาห์อย่างเต็มที่และขอเชิญคุณมา การสัมมนาผ่านเว็บฟรีซึ่งจะจัดขึ้นในวันที่ 14 พฤษภาคม

ที่มา: will.com

เพิ่มความคิดเห็น