SQL กับ NoSQL เชิงลึก

คำถามฐานข้อมูลไม่ได้วัดว่าเราเขียน query เป็นไหม แต่วัดว่าเราเข้าใจ "ลักษณะของข้อมูล" และเลือกเทคโนโลยีให้เหมาะกับโจทย์ได้ไหม DCE ต้องฟังลูกค้าเล่า workload แล้วบอกได้ว่าควรใช้ database แบบไหนพร้อมเหตุผลที่หนักแน่น ดังนั้นเตรียมตอบสามชั้น: ความต่างเชิงโครงสร้าง คุณสมบัติเชิงทฤษฎี (ACID, CAP) และการเลือกใช้จริงบน GCP

relational database เก็บข้อมูลเป็นตารางที่มี schema กำหนดไว้ล่วงหน้า แต่ละตารางมีคอลัมน์ชนิดข้อมูลชัดเจน และเชื่อมกันด้วย key ความสัมพันธ์ จุดเด่นคือ:

• Schema-on-write: ต้องนิยามโครงสร้างก่อนใส่ข้อมูล ทำให้ข้อมูลสะอาดและสอดคล้อง
• Normalization: ลดข้อมูลซ้ำซ้อนด้วยการแยกตาราง ช่วยความถูกต้องแต่ทำให้ query ต้อง join
• ACID: คุณสมบัติที่รับประกันความถูกต้องของ transaction ได้แก่ Atomicity (ทำทั้งหมดหรือไม่ทำเลย), Consistency (ข้อมูลอยู่ในสถานะที่ถูกต้องตามกฎเสมอ), Isolation (transaction ไม่กวนกัน), Durability (เมื่อ commit แล้วข้อมูลไม่หายแม้ระบบล่ม)
• การ scale: ดั้งเดิมเน้น vertical scaling คือเพิ่มสเปกเครื่อง ซึ่งมีเพดาน

เหมาะกับ: ระบบที่ความถูกต้องของข้อมูลสำคัญสูงสุด เช่น การเงิน การบัญชี ระบบ inventory ที่ห้ามนับผิด

NoSQL / Non-relational เชิงลึก:

NoSQL ออกแบบมาเพื่อความยืดหยุ่นและการ scale แนวนอน แบ่งเป็นหลายตระกูลตามรูปแบบข้อมูล:

• Document store: เก็บเป็นเอกสาร JSON-like ยืดหยุ่น schema เหมาะ app ที่โครงสร้างข้อมูลเปลี่ยนบ่อย เช่น Firestore
• Wide-column store: เก็บแบบคอลัมน์กว้าง รองรับข้อมูลมหาศาล latency ต่ำ เช่น Bigtable เหมาะ time-series, IoT, ข้อมูล sensor
• Key-value store: เก็บคู่ key กับ value เร็วมาก เหมาะ caching และ session เช่น Memorystore (Redis)
• Graph database: เก็บความสัมพันธ์เป็นกราฟ เหมาะ social network, recommendation, fraud detection

คุณสมบัติ NoSQL มักเป็น:

• Schema-on-read หรือ flexible schema: ใส่ข้อมูลได้เลยโดยไม่ต้องนิยามล่วงหน้า ยืดหยุ่นแต่ต้องระวังความสะอาดข้อมูล
• Horizontal scaling: กระจายข้อมูลข้ามหลายเครื่อง (sharding) รองรับการโตได้แทบไม่จำกัด
• BASE และ eventual consistency: ยอมให้ข้อมูลไม่ sync กันชั่วครู่เพื่อแลกกับ availability และ scale

CAP theorem บอกว่าในระบบฐานข้อมูลแบบกระจาย (distributed) เราเลือกได้แค่สองในสามคุณสมบัติพร้อมกันเมื่อเกิดปัญหาเครือข่าย: Consistency (ทุก node เห็นข้อมูลเดียวกันในเวลาเดียวกัน), Availability (ระบบตอบได้เสมอ), Partition tolerance (ทำงานต่อได้แม้เครือข่ายระหว่าง node ขาด) เนื่องจาก distributed system ต้องทน partition เสมอ ในทางปฏิบัติจึงเป็นการเลือกระหว่าง C กับ A เวลาเกิด partition ระบบที่เลือก consistency จะยอมปฏิเสธ request เพื่อไม่ให้ข้อมูลเพี้ยน ส่วนระบบที่เลือก availability จะยอมตอบด้วยข้อมูลที่อาจยังไม่ sync การเข้าใจ CAP ทำให้อธิบายได้ว่าทำไมบางระบบเลือก strong consistency บางระบบเลือก eventual consistency

Cloud SQL: managed relational รองรับ MySQL, PostgreSQL, SQL Server เหมาะ workload relational ทั่วไประดับ regional ที่ย้ายมาจาก database เดิม Google ดูแล backup, patch, replication ให้ จุดจำกัดคือ scale ได้ในระดับหนึ่ง เหมาะแอปทั่วไปถึงกลาง

Cloud Spanner: relational database ที่ scale แนวนอนได้ระดับโลกพร้อม strong consistency และ SLA สูงมาก เป็นจุดเด่นเฉพาะตัวของ GCP ที่คู่แข่งเทียบยาก เพราะปกติ relational กับ horizontal scale ระดับ global เป็นของที่ได้ยากพร้อมกัน เหมาะระบบการเงิน e-commerce ระดับ global ที่ต้องการทั้ง scale และความถูกต้อง ข้อแลกเปลี่ยนคือราคาสูงกว่า Cloud SQL

AlloyDB: PostgreSQL-compatible ประสิทธิภาพสูง ออกแบบให้รองรับทั้ง transactional และ analytical ในตัว เหมาะ workload PostgreSQL ที่ต้องการ performance สูงกว่า Cloud SQL

Bigtable: NoSQL wide-column สำหรับข้อมูลมหาศาล latency ต่ำ throughput สูง เหมาะ time-series, IoT, ข้อมูลการเงินเชิงปริมาณ เกี่ยวข้องกับโลก HBase/Hadoop เดิม

Firestore: NoSQL document database สำหรับ mobile และ web app มี real-time sync และ offline support เหมาะแอปที่ต้องอัปเดตสด

Memorystore: managed Redis และ Memcached สำหรับ caching ลดภาระ database หลักและเพิ่มความเร็ว

ถามตัวเองตามลำดับ: ข้อมูลมีโครงสร้างชัดและสัมพันธ์กันไหม ต้องการ transaction ถูกต้องแบบ ACID ไหม ปริมาณข้อมูลและ traffic ใหญ่แค่ไหน ต้องการ scale ระดับ regional หรือ global ต้องการ latency ต่ำมากไหม รูปแบบข้อมูลเป็น document, time-series หรือ key-value

แนวเลือกคร่าว ๆ: relational + regional + ทั่วไป เลือก Cloud SQL; relational + global + strong consistency เลือก Cloud Spanner; PostgreSQL + performance สูง + งานผสม เลือก AlloyDB; ข้อมูลมหาศาล time-series/IoT latency ต่ำ เลือก Bigtable; mobile/web realtime เลือก Firestore; caching เลือก Memorystore

ถาม: "SQL กับ NoSQL ต่างกันอย่างไร เลือกอย่างไร" ตอบ: ไล่ความต่างเชิงโครงสร้างและ consistency แล้วปิดด้วยเกณฑ์เลือกตามลักษณะข้อมูลและความต้องการ scale/consistency

ถาม: "ระบบธนาคารหลายประเทศต้องการความถูกต้องและ scale ระดับโลก ใช้อะไร" ตอบ: Cloud Spanner เพราะให้ relational + strong consistency + horizontal scale ระดับ global พร้อมกัน

ถาม: "เก็บข้อมูลจาก sensor IoT หลายล้านจุดต่อวินาที ใช้อะไร" ตอบ: Bigtable เพราะรองรับ write throughput สูงและ latency ต่ำสำหรับ time-series

ถาม: "ACID คืออะไร ทำไมสำคัญกับการเงิน" ตอบ: อธิบายสี่ตัวและยกตัวอย่างการโอนเงินที่ต้องทำทั้งหักและเพิ่มพร้อมกันหรือไม่ทำเลย

ถาม: "อธิบาย CAP theorem" ตอบ: เลือกได้สองในสาม เมื่อเกิด partition ต้องเลือกระหว่าง consistency กับ availability พร้อมตัวอย่างระบบที่เลือกต่างกัน

มองว่า NoSQL ดีกว่า SQL เสมอหรือกลับกัน ทั้งที่ขึ้นกับโจทย์; ลืมว่า Spanner เป็น relational ที่ scale ได้ จึงตอบ NoSQL ทุกครั้งที่ลูกค้าพูดคำว่า scale; อธิบาย ACID ไม่ครบหรือสับสนกับ CAP; เลือก database โดยไม่ถาม requirement เรื่อง consistency และ scale ก่อน; ลืม Memorystore/caching ในการออกแบบ performance

SQL เน้นโครงสร้างชัดและ ACID เหมาะงานที่ความถูกต้องสำคัญ NoSQL เน้นยืดหยุ่นและ horizontal scale มีหลายตระกูลตามรูปแบบข้อมูล CAP theorem อธิบายการเลือกระหว่าง consistency กับ availability บน GCP จับคู่ให้ถูก: Cloud SQL สำหรับ relational ทั่วไป, Spanner สำหรับ global + strong consistency, AlloyDB สำหรับ PostgreSQL performance สูง, Bigtable สำหรับ time-series มหาศาล, Firestore สำหรับ realtime app, Memorystore สำหรับ caching และที่สำคัญที่สุดคือถาม requirement ก่อนเลือกเสมอ