SQL กับ NoSQL ต่างกันอย่างไร? เทียบข้อมูลชุดเดียวกันให้เห็นชัด

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

วันนี้ Superdev Academy เลยจะทำแบบนั้นให้ดู เอาข้อมูลชุดเล็กชุดเดียวกัน คือผู้ใช้หนึ่งคนที่มีคำสั่งซื้อสองรายการ มาเก็บสองแบบ แบบแรกเป็นตารางของ SQL แบบที่สองเป็น Document ของ NoSQL แล้วค่อยดูว่าความต่างจริงๆ อยู่ตรงไหน และควรเลือกแบบไหนสำหรับงานของคุณ

สรุปสั้นๆ: SQL เก็บข้อมูลเป็นตารางที่ประกาศ Schema ไว้ก่อน แล้วประกอบข้อมูลด้วย JOIN ส่วน NoSQL แบบ Document เก็บข้อมูลที่อ่านด้วยกันไว้ใน Document เดียว Schema ยืดหยุ่นกว่า

ข้อมูลชุดเดียวกัน เก็บได้สองแบบ

โจทย์ของเราง่ายมาก ผู้ใช้ชื่อ Mint สั่งของสองชิ้น คือ Keyboard กับ Mouse แต่ละคำสั่งซื้อมีรหัสและยอดรวมของตัวเอง

แบบที่ 1: SQL (Relational Database หรือฐานข้อมูลเชิงสัมพันธ์) ข้อมูลถูกแยกเป็นหลายตาราง เชื่อมด้วย Foreign Key (คอลัมน์ที่ชี้ไปหาแถวในอีกตาราง) ตาราง users เก็บผู้ใช้ ตาราง orders เก็บคำสั่งซื้อ และแต่ละคำสั่งซื้อมี user_id บอกว่าเป็นของใคร

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  user_id INTEGER NOT NULL REFERENCES users(id),
  item TEXT,
  total INTEGER
);
INSERT INTO users VALUES (1, 'Mint');
INSERT INTO orders VALUES (101, 1, 'Keyboard', 1290), (102, 1, 'Mouse', 590);

SELECT u.name, o.item, o.total
FROM users u JOIN orders o ON o.user_id = u.id;

เราลองรันชุดนี้จริงด้วย sqlite3 เวอร์ชัน 3.43.2 ผลที่ได้คือสองแถว แต่ละแถวมีชื่อ Mint ซ้ำกัน เพราะ JOIN (การเอาสองตารางมาต่อกันตามเงื่อนไข) คือการประกอบข้อมูลที่แยกเก็บไว้กลับมาเป็นภาพเดียวตอนอ่าน

name  item      total
----  --------  -----
Mint  Keyboard  1290
Mint  Mouse     590

แบบที่ 2: NoSQL แบบ Document (เช่น MongoDB) ข้อมูลทั้งหมดของ Mint อยู่ใน Document ก้อนเดียว คำสั่งซื้อถูกฝังไว้เป็น Array ข้างใน หน้าตาเหมือน JSON ที่คุณอาจเคยเห็นมาแล้ว

{
  "_id": 1,
  "name": "Mint",
  "orders": [
    { "orderId": 101, "item": "Keyboard", "total": 1290 },
    { "orderId": 102, "item": "Mouse", "total": 590 }
  ]
}

ถ้ายังไม่คุ้นกับวงเล็บปีกกาและวงเล็บเหลี่ยมพวกนี้ ไม่ต้องกังวล อ่านพื้นฐานได้ใน บทความ JSON สำหรับมือใหม่ ของเรา แล้วกลับมาอ่านต่อได้เลย

ข้อมูลเหมือนกันทุกตัว ต่างกันแค่รูปร่าง

ฝั่ง SQL คือตาราง + JOIN ส่วนฝั่ง NoSQL คือ Document ก้อนเดียว ความต่างที่เหลือทั้งหมดในบทความนี้ไหลออกมาจากจุดนี้จุดเดียว

Schema: ตกลงกันก่อน หรือค่อยปรับทีหลัง

Schema คือโครงสร้างที่บอกว่าข้อมูลแต่ละชิ้นต้องมีช่องอะไรบ้าง ฝั่ง SQL ต้องประกาศไว้ก่อนตั้งแต่ตอน CREATE TABLE ทุกแถวในตาราง orders จะมีคอลัมน์ชุดเดียวกันเสมอ อยากเพิ่มช่องใหม่ก็ต้องแก้โครงสร้างตาราง

ข้อดีของความเข้มงวดนี้เห็นได้ชัดตอนเราลองใส่คำสั่งซื้อของผู้ใช้ id 99 ที่ไม่มีอยู่จริง ฐานข้อมูลตอบกลับมาทันทีว่า FOREIGN KEY constraint failed และไม่ยอมบันทึก ข้อมูลกำพร้าแบบนี้หลุดเข้าไปไม่ได้ มีจุดหนึ่งที่ต้องรู้ไว้คือ SQLite ปิดการตรวจ Foreign Key ไว้เป็นค่าเริ่มต้น ต้องสั่ง PRAGMA foreign_keys = ON; ก่อน ซึ่งเราเปิดไว้ตอนทดสอบ

ฝั่ง MongoDB เอกสารของ MongoDB อธิบายว่า Document ใน Collection (กลุ่มของ Document คล้ายกับตาราง) เดียวกันไม่จำเป็นต้องมีชุดฟิลด์เหมือนกัน และชนิดข้อมูลของฟิลด์เดียวกันก็ต่างกันได้ในแต่ละ Document พูดง่ายๆ คือถ้าคำสั่งซื้อบางรายการมีช่อง "คูปอง" เพิ่มมา ก็ใส่ลงไปได้เลยโดยไม่ต้องแก้โครงสร้างอะไร

ความยืดหยุ่นไม่ได้แปลว่าไม่ต้องคิดเรื่องโครงสร้าง แค่ย้ายความรับผิดชอบจากฐานข้อมูลมาอยู่ในโค้ดของคุณแทน

JOIN กับการฝังข้อมูล (Embedding)

ตอนอยากรู้ว่า Mint สั่งอะไรไปบ้าง ฝั่ง SQL ต้อง JOIN สองตาราง ส่วนฝั่ง Document อ่าน Document ก้อนเดียวก็ได้ครบ คู่มือ Data Modeling ของ MongoDB วางหลักไว้ตรงๆ ว่าข้อมูลที่ถูกอ่านด้วยกันควรเก็บไว้ด้วยกัน และบอกว่าการฝังข้อมูลช่วยเลี่ยง JOIN ที่ซับซ้อนข้ามหลาย Collection ได้

แต่การฝังก็มีราคาของมัน ลองนึกภาพว่า Mint สั่งของไปแล้วหลายพันรายการ Document ก้อนเดียวจะใหญ่ขึ้นเรื่อยๆ หรือถ้าหน้ารายงานอยากดูว่า "Keyboard ขายไปกี่ชิ้นจากลูกค้าทุกคน" ข้อมูลที่ฝังอยู่ในผู้ใช้แต่ละคนจะถูกดึงออกมายากกว่าตาราง orders ที่รวมทุกคำสั่งซื้อไว้ที่เดียว

MongoDB เองก็ไม่ได้บังคับให้ฝังเสมอ เอกสารของ MongoDB บอกว่าความสัมพันธ์จำลองได้ทั้งแบบฝัง (Embedding) และแบบอ้างอิง (Referencing) และมีคำสั่ง $lookup ที่ทำ Left Outer Join ไปยัง Collection อื่นในฐานข้อมูลเดียวกันได้ ส่วนฝั่ง SQL ถ้าอยากได้ข้อมูลแบบก้อนเดียวก็ทำได้เหมือนกัน ดังนั้นคำถามที่ถูกไม่ใช่ "ใครทำ JOIN ได้" แต่คือ "งานของคุณอ่านข้อมูลแบบไหนบ่อยที่สุด"

NoSQL ไม่มี ACID จริงไหม?

ความเชื่อนี้ยังเจอบ่อยมาก ACID คือชุดคุณสมบัติที่ทำให้มั่นใจได้ว่า Transaction (ชุดการเขียนข้อมูลหลายขั้นที่ต้องสำเร็จพร้อมกันหรือล้มพร้อมกัน) จะไม่ทิ้งข้อมูลไว้ครึ่งๆ กลางๆ ตัวอย่างคลาสสิกคือการโอนเงิน ตัดเงินบัญชีหนึ่งแล้วต้องเพิ่มอีกบัญชีให้ได้ ถ้าขั้นที่สองพัง ขั้นแรกต้องถูกยกเลิกด้วย

ฐานข้อมูล SQL อย่าง PostgreSQL หรือ SQLite รองรับ Transaction เป็นพื้นฐานอยู่แล้ว (ถ้าอยากเห็นการจัดการ Transaction ในโค้ดจริง ดูต่อได้ที่ JS2GO EP.45 Transactions และ ACID ใน Go และ JavaScript) ส่วน MongoDB เอกสาร Transactions ของ MongoDB ระบุว่าการเขียนบน Document เดียวเป็น Atomic อยู่แล้ว และ MongoDB ประกาศ Multi-Document Transaction แบบ ACID ในเวอร์ชัน 4.0 ซึ่งเปิดใช้ทั่วไปเมื่อเดือนมิถุนายน 2018 บนระบบแบบ Replica Set

ที่น่าสนใจคือเอกสารของ MongoDB เองเตือนว่า Transaction ข้ามหลาย Document มีต้นทุนด้านประสิทธิภาพสูงกว่าการเขียน Document เดียว และไม่ควรใช้แทนการออกแบบ Schema ที่ดี นี่คือเหตุผลที่ตัวอย่างข้างบนฝังคำสั่งซื้อไว้ใน Document ของผู้ใช้ เพราะการอัปเดตผู้ใช้พร้อมคำสั่งซื้อจะกลายเป็นการเขียน Document เดียว ไม่ต้องพึ่ง Transaction เลย

สรุปคือ พูดว่า "NoSQL ไม่มี ACID" ไม่ถูก ที่ถูกกว่าคือ แต่ละตัวออกแบบมาไม่เหมือนกัน ต้องเปิดเอกสารของตัวที่คุณจะใช้ดู

NoSQL ไม่ได้มีแค่ MongoDB

คำว่า NoSQL เป็นชื่อเรียกรวมของฐานข้อมูลที่ไม่ได้เก็บแบบตารางเชิงสัมพันธ์ บทความอธิบาย NoSQL ของ MongoDB แบ่งเป็น 4 ประเภทหลัก

• Document: เก็บข้อมูลเป็น Document หน้าตาคล้าย JSON แบบตัวอย่างของ Mint เช่น MongoDB

• Key-Value: เก็บเป็นคู่ Key กับค่า เหมาะกับงาน Cache และ Session เช่น Redis ซึ่ง JS2GO EP.44 มีตัวอย่างโค้ดเชื่อมต่อให้ดูทั้งฝั่ง JavaScript และ Go

• Wide-Column: มีตาราง แถว และคอลัมน์ แต่แต่ละแถวมีชุดคอลัมน์ไม่เหมือนกันได้ เช่น Apache Cassandra

• Graph: เก็บเป็นจุด (Node) กับเส้นเชื่อม (Edge) เหมาะกับข้อมูลที่ความสัมพันธ์คือหัวใจ เช่น เครือข่ายเพื่อน ตัวที่รู้จักกันดีคือ Neo4j

เพราะฉะนั้นเวลามีคนเทียบ "SQL กับ NoSQL" ส่วนใหญ่เขากำลังเทียบ SQL กับ Document Database อย่าง MongoDB ซึ่งเป็นแค่หนึ่งในสี่ประเภท

ใช้ PostgreSQL ที่มี JSONB ก็ได้ทั้งสองแบบไม่ใช่เหรอ?

จริงๆ ได้ และเป็นทางเลือกที่หลายทีมใช้อยู่ เอกสาร PostgreSQL อธิบายว่าชนิดข้อมูล jsonb เก็บ JSON ในรูปแบบไบนารีที่แยกส่วนไว้แล้ว ประมวลผลเร็วกว่า json แบบข้อความธรรมดาอย่างมาก และรองรับการทำ Index เช่น GIN Index เอกสารยังแนะนำว่าแอปพลิเคชันส่วนใหญ่ควรเลือก jsonb มากกว่า json

แปลว่าคุณสามารถเก็บข้อมูลหลักอย่างผู้ใช้และคำสั่งซื้อเป็นตารางที่มี Foreign Key คอยกันข้อมูลกำพร้า แล้วเก็บส่วนที่รูปร่างไม่แน่นอน เช่น รายละเอียดสินค้าที่แต่ละหมวดมีช่องไม่เหมือนกัน เป็น jsonb ในคอลัมน์เดียวได้

แต่ JSONB ก็ไม่ได้ทำให้ PostgreSQL กลายเป็น MongoDB ทั้งตัว ถ้าข้อมูลเกือบทั้งหมดของคุณมีรูปร่างเป็น Document และทีมอยากทำงานกับโมเดลแบบ Document ตั้งแต่ต้นจนจบ การใช้ Document Database ตรงๆ ก็ยังสมเหตุสมผล สิ่งที่อยากให้เห็นคือ เส้นแบ่งระหว่าง SQL กับ NoSQL ในปัจจุบันไม่ได้ขาดจากกันเหมือนเมื่อก่อน

SQL กับ NoSQL ใช้ตอนไหน เลือกยังไงดี

ให้เลือกจากรูปร่างของข้อมูลและรูปแบบการอ่าน ไม่ใช่จากกระแส ลองถามตัวเองสามข้อ

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

• ส่วนใหญ่อ่านข้อมูลเป็นก้อนไหม ถ้าหน้าจอหลักดึงข้อมูลหนึ่งชุดมาแสดงทีเดียว เช่น หน้าโปรไฟล์ที่มีทุกอย่างของคนคนเดียว Document จะเข้ากับงานนี้

• รูปร่างข้อมูลเปลี่ยนบ่อยไหม ถ้าแต่ละรายการมีช่องไม่เหมือนกันจริงๆ ความยืดหยุ่นของ Document หรือคอลัมน์ JSONB จะช่วยได้

ถ้าคุณเพิ่งเริ่มต้นและยังตอบไม่ได้ เราแนะนำให้เริ่มจาก SQL ก่อน เพราะแนวคิดเรื่องตาราง Key และ JOIN ใช้ต่อได้แทบทุกที่ ลองเริ่มจาก เขียน SQL query แรกของคุณ แล้วค่อยขยับไปที่ พื้นฐาน SQL ที่นักพัฒนาเว็บต้องรู้ พอเข้าใจว่าการแยกตารางแก้ปัญหาอะไร คุณจะเห็นเองว่าการฝังข้อมูลใน Document ช่วยตรงไหน และแลกกับอะไร

สรุป: SQL กับ NoSQL ต่างกันอย่างไร

ความต่างหลักคือรูปร่างของข้อมูล SQL เก็บเป็นตารางที่มี Schema ประกาศไว้ล่วงหน้า แยกข้อมูลเป็นหลายตารางแล้วประกอบกลับด้วย JOIN ส่วน NoSQL แบบ Document อย่าง MongoDB เก็บข้อมูลที่อ่านด้วยกันไว้ใน Document เดียว Schema ยืดหยุ่นกว่า ทั้งสองฝั่งมี Transaction แบบ ACID และ PostgreSQL ก็เก็บ JSON ได้ด้วย JSONB เส้นแบ่งจึงไม่ได้อยู่ที่ว่าใครทันสมัยกว่า

ลองเอาโปรเจกต์ที่คุณกำลังจะทำ เขียนข้อมูลตัวอย่างสักสองสามรายการแบบที่เราทำกับ Mint ทั้งแบบตารางและแบบ Document แล้วถามว่าหน้าจอที่ใช้บ่อยที่สุดต้องอ่านข้อมูลแบบไหน คำตอบของคุณจะชัดกว่าการอ่านบทความเทียบอีกสิบบทความ

ติดตามบทความและเทคนิคสำหรับคนเริ่มต้นสายโปรแกรมเมอร์ได้ที่ช่องทางของเรา

Facebook: Superdev Academy Thailand — https://www.facebook.com/superdev.academy.th

YouTube: Superdev Academy Channel — https://www.youtube.com/@SuperdevAcademy

Instagram: @superdevacademy — https://www.instagram.com/superdevacademy/

TikTok: @superdevacademy — https://www.tiktok.com/@superdevacademy?lang=th-TH