~/VibeHandbook
PDF ฟรี

บท 14 · 01

รูปแบบทั้งสามของการจัดเก็บข้อมูล

ฐานข้อมูลส่วนใหญ่แบ่งออกเป็นสามตระกูล คุณไม่จำเป็นต้องจำชื่อผลิตภัณฑ์ทั้งหมด — คุณแค่ต้องรู้ว่า รูปแบบ ไหนเหมาะกับปัญหาของคุณ

ประเภทตัวอย่างเหมาะกับข้อแลกเปลี่ยน
เชิงสัมพันธ์ ()PostgreSQL, MySQL, SQLiteข้อมูลที่มีโครงสร้างและความสัมพันธ์กัน; อะไรก็ตามที่เกี่ยวกับเงินหรือต้องแม่นยำต้องออกแบบสคีมา (schema) ไว้ล่วงหน้า; การสเกลการเขียนข้อมูลจำนวนมากทำได้ยากกว่า
เอกสาร / MongoDB, Firestore, DynamoDBข้อมูลที่ยืดหยุ่นหรือซ้อนกัน, การพัฒนาแบบเร็ว, รูปแบบเรคคอร์ดที่หลากหลายสร้างข้อมูลที่ไม่สอดคล้องกันได้ง่าย; ความสัมพันธ์และการทำรายงานจะยุ่งยาก
คีย์-แวลูRedis, Memcached, Cloudflare KVการแคช, เซสชัน, ตัวนับ, การค้นหาที่รวดเร็วด้วยคีย์ที่รู้อยู่แล้วค้นหาตามเนื้อหาไม่ได้; มักไม่ใช่แหล่งข้อมูลหลักของคุณ

ทั้งสามรูปแบบเก็บข้อมูลด้วยวิธีที่แตกต่างกันจริง ๆ ลองนึกภาพเทียบกันดู

  RELATIONAL (SQL)          DOCUMENT (NoSQL)         KEY-VALUE
  rows + columns            self-contained blobs     one key → one value
  ┌────┬───────┬──────┐     ┌──────────────────┐     ┌─────────┬─────────┐
  │ id │ email │ name │     │ {                │     │ key     │ value   │
  ├────┼───────┼──────┤     │   id, email,     │     ├─────────┼─────────┤
  │ 1  │ a@... │ Ana  │     │   name,          │     │ session │ "x9f2"  │
  │ 2  │ b@... │ Bob  │     │   posts: [ ... ] │     │ count   │ "42"    │
  └────┴───────┴──────┘     │ }                │     └─────────┴─────────┘
  tables reference          └──────────────────┘     no querying inside —
  each other                everything nested        look up by key only

ลองนึกภาพฐานข้อมูลเชิงสัมพันธ์เป็นชุดสเปรดชีตที่รู้วิธีอ้างอิงถึงกันเอง ภาษาที่คุณใช้คุยกับมันคือ SQL (Structured Query Language — ภาษาสำหรับสอบถามโครงสร้าง) ค่าเริ่มต้นที่ดีสำหรับโปรเจกต์ 90% คือ เริ่มด้วยฐานข้อมูลเชิงสัมพันธ์ (Postgres) มันเป็นเทคโนโลยีที่เติบโตเต็มที่ คาดเดาได้ บังคับให้มีโครงสร้าง และรองรับความสัมพันธ์ที่แอปจริงย่อมเติบโตขึ้นมาในที่สุด หันไปใช้ document store เมื่อข้อมูลของคุณไม่มีรูปแบบตายตัวจริง ๆ และใช้ key-value store เป็นชั้น เสริม (การแคช) ไม่ใช่ที่เก็บข้อมูลหลักของคุณ

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

อยากได้แบบออฟไลน์?

ดาวน์โหลดหนังสือทั้งเล่มเป็น PDF หรือ EPUB — ฟรี