7 ฐานข้อมูลสำหรับปี 2025

xguru · 2024-12-09T09:56:01+09:00

แนะนำฐานข้อมูล 7 ตัวที่ควรค่าแก่การจับตามองเพื่อใช้แก้ปัญหาที่หลากหลาย นี่ไม่ใช่ลิสต์ "ฐานข้อมูลที่ดีที่สุด" แต่เป็นเครื่องมือที่มอบมุมมองใหม่และมีประโยชน์ ในปี 2025 อยากชวนให้ลองลงทุนเวลาอย่างละหนึ่งสัปดาห์กับฐานข้อมูลแต่ละตัว (7 DBs in 7 Weeks) 1. PostgreSQL: ฐานข้อมูลพื้นฐาน PostgreSQL เป็นเทคโนโลยีที่มั่นคงและถูกใช้เป็นค่าเริ่มต้น วลี "Just use Postgres" เป็นทั้งมีมที่รู้จักกันอย่างแพร่หลายและสื่อถึงความน่าเชื่อถือ รองรับ ACID และมีความสามารถที่แข็งแกร่ง รวมถึงการทำ replication ทั้งแบบ physical และ logical เป็นฐานข้อมูลที่เสถียรและได้รับการสนับสนุนอย่างกว้างขวางจากผู้ให้บริการรายหลัก เสน่ห์สำคัญที่สุดของ PostgreSQL: ความสามารถในการขยาย สามารถเพิ่มความสามารถเฉพาะทางได้ผ่าน Extensions ตัวอย่าง extension หลัก: AGE: รองรับโครงสร้างข้อมูลกราฟและภาษา query แบบ Cypher TimescaleDB: รองรับการทำงานกับข้อมูลอนุกรมเวลา Hydra Columnar: มอบเอนจินจัดเก็บข้อมูลแบบคอลัมน์ Extensions คือองค์ประกอบหลักที่ทำให้ PostgreSQL แตกต่างจากฐานข้อมูลอื่น ประโยชน์ใช้สอยและความยืดหยุ่นของ PostgreSQL มี ecosystem ที่หลากหลาย พร้อมค่าเริ่มต้นที่สมเหตุสมผลและเป็นมิตรต่อผู้ใช้ แม้แต่บริการที่ไม่ใช่ PostgreSQL ก็ยังใช้ Postgres wire protocol เพื่อให้เข้ากันได้กับไคลเอนต์ เบาพอที่จะติดตั้งได้แม้ในสภาพแวดล้อม WebAssembly (Wasm) แนะนำให้เรียนรู้ PostgreSQL คุ้มค่าที่จะลงทุนเวลาเพื่อเข้าใจศักยภาพและข้อจำกัดของ PostgreSQL ตัวอย่าง: ทำความเข้าใจความซับซ้อนของ MVCC(Multi-Version Concurrency Control) แนะนำให้ลองพัฒนาแอป CRUD แบบง่าย ๆ หรือเขียน PostgreSQL extension เอง 2. SQLite: ฐานข้อมูลแบบ local-first SQLite เป็นฐานข้อมูลแบบ "local-first" ที่ทำงานได้อย่างอิสระ ไม่ยึดติดกับโมเดล client-server และทำงานอยู่ในสภาพแวดล้อมเดียวกับแอปพลิเคชัน ตัวอย่าง: WhatsApp และ Signal ใช้ SQLite ภายในอุปกรณ์เพื่อเก็บข้อมูลแชต กรณีการใช้งาน SQLite ที่พัฒนาไปไกลกว่าเดิม นำไปใช้เชิงสร้างสรรค์ได้มากกว่าการเป็นฐานข้อมูลที่รองรับ ACID พื้นฐาน เครื่องมือและ extension ใหม่ ๆ: Litestream: ทำ streaming backup ให้ SQLite LiteFS: รองรับ distributed access เพื่อให้สร้าง topology ที่ยืดหยุ่นขึ้นได้ CR-SQLite: ใช้ CRDT(Conflict-free Replicated Data Types) เพื่อตัดความจำเป็นในการแก้ conflict ตอนรวม change set การกลับมาได้รับความนิยมของ SQLite กำลังกลับมาได้รับความสนใจอีกครั้งจาก Ruby on Rails 8.0 37signals: พัฒนาโมดูล Rails (เช่น Solid Queue) บนพื้นฐานของ SQLite รองรับการจัดการฐานข้อมูล SQLite หลายตัวใน Rails (database.yml) Bluesky: ใช้ฐานข้อมูล SQLite แยกต่อผู้ใช้เป็น Personal Data Servers แนะนำให้เรียนรู้การใช้งาน SQLite ลองทดลองสถาปัตยกรรมแบบเน้น local ด้วย SQLite ทดสอบว่าสามารถแทนที่โมเดล client-server ที่เดิมใช้ PostgreSQL ด้วย SQLite ได้หรือไม่ 3. DuckDB: ฐานข้อมูลที่ query ได้กับทุกสิ่ง DuckDB เป็นฐานข้อมูลแบบ embedded ที่เชี่ยวชาญด้าน OLAP คล้าย SQLite ตรงที่ทำงานร่วมกับแอปพลิเคชัน แต่เน้นงาน OLAP แทน OLTP เป็นระบบที่ออกแบบมาโดยเน้นการวิเคราะห์ข้อมูลและการ query คุณสมบัติ "Query-Anything" ของ DuckDB สามารถ query แหล่งข้อมูลหลากหลายได้โดยตรงด้วย SQL: ฟอร์แมตไฟล์ทั่วไป เช่น CSV, TSV, JSON รองรับฟอร์แมตขั้นสูงอย่าง Parquet ความสามารถนี้ให้ความยืดหยุ่นสูง เช่น ใช้วิเคราะห์สตรีมข้อมูลของ Bluesky ความสามารถในการขยายและ ecosystem DuckDB ก็มี extensions เช่นกัน แต่ยังไม่หลากหลายเท่า Postgres (เพราะเป็นโปรเจ็กต์ที่อายุน้อยกว่า) มี extension จากชุมชนจำนวนมาก โดย gsheets (เชื่อมต่อ Google Sheets) น่าสนใจเป็นพิเศษ แนะนำให้เรียนรู้การใช้ DuckDB ทดลองวิเคราะห์และประมวลผลข้อมูลผ่าน Python notebook หรือ Evidence ใช้ร่วมกับ SQLite: โยน analytical query ของฐานข้อมูล SQLite ไปให้ DuckDB เพื่อเพิ่มประสิทธิภาพ 4. ClickHouse: ฐานข้อมูลแบบคอลัมน์ ClickHouse เป็นฐานข้อมูลที่เชี่ยวชาญด้านงาน OLAP การจับคู่ PostgreSQL สำหรับ OLTP และ ClickHouse สำหรับ OLAP ถือว่าเหมาะมาก รองรับ workload เชิงวิเคราะห์ขนาดใหญ่ และรองรับความเร็วในการเขียนข้อมูลสูงผ่านการขยายแนวนอนและ sharding คุณลักษณะสำคัญของ ClickHouse รองรับ hierarchical storage: แยกจัดเก็บ "hot data" และ "cold data" ได้ ตัวอย่าง: เอกสารของ GitLab อธิบายกรณีใช้งานนี้ไว้อย่างละเอียด รองรับ dataset ขนาดใหญ่และการวิเคราะห์แบบเรียลไทม์: เหมาะกับ dataset ที่ใหญ่เกินกว่าที่ DuckDB จะจัดการได้สะดวก ให้ประสิทธิภาพสูงในสถานการณ์ที่ต้องการการวิเคราะห์แบบเรียลไทม์ ความสะดวกในการดูแลระบบ เอกสารด้านปฏิบัติการ เช่น การ deploy, scale, backup มีโครงสร้างดีและละเอียด ตัวอย่าง: มีเอกสารที่ลงลึกถึงวิธีตั้งค่า CPU ที่เหมาะสม แนะนำให้เรียนรู้ ClickHouse ลองทดลองกับ dataset เชิงวิเคราะห์ขนาดใหญ่ หรือแปลงงานวิเคราะห์ที่ทำใน DuckDB มาใช้กับ ClickHouse ใช้ chDB ซึ่งเป็นเวอร์ชัน embedded ของ ClickHouse เพื่อเปรียบเทียบกับ SQLite ได้โดยตรงมากขึ้น 5. FoundationDB: ฐานข้อมูลแบบ layered FoundationDB เป็นระบบที่มีเอกลักษณ์เฉพาะตัวในฐานะ "รากฐานของฐานข้อมูล" ถูกออกแบบเป็น key-value store แต่ทำงานเหมือน "พื้นฐาน" สำหรับสร้างฐานข้อมูล มากกว่าจะเป็นฐานข้อมูลแบบเรียบง่าย ถูกใช้งานโดยบริษัทใหญ่ เช่น Apple, Snowflake และ Tigris Data คุณสมบัติสำคัญและข้อจำกัด ข้อจำกัด: ข้อมูลธุรกรรมต้องไม่เกิน 10MB ธุรกรรมต้องไม่เกิน 5 วินาทีนับจากการอ่านครั้งแรก ข้อจำกัดเหล่านี้ทำให้สามารถรองรับ ธุรกรรม ACID แบบสมบูรณ์ในสเกลขนาดใหญ่ ได้ ตัวอย่าง: มีกรณีการรันคลัสเตอร์ขนาดมากกว่า 100TiB การออกแบบและการทดสอบของ FoundationDB ออกแบบมาให้เหมาะกับ workload เฉพาะประเภท พิสูจน์ความเสถียรและความสามารถในการขยายด้วย simulation testing: Antithesis และฐานข้อมูลอื่น ๆ ก็ใช้ระเบียบวิธีการทดสอบแบบเดียวกัน เอกสารอ้างอิงที่เกี่ยวข้อง: เอกสารของ Tyler Neely และ Phil Eaton FoundationDB ในฐานะฐานข้อมูลแบบ "layered" การผูกกันระหว่าง storage engine กับ data model ค่อนข้างหลวม: สามารถ remap storage engine ได้ในหลายเลเยอร์ ตัวอย่าง: Record Layer, Document Layer (จัดทำโดยองค์กร FoundationDB) กรณีศึกษาการออกแบบเลเยอร์จาก Tigris Data ก็น่าอ่านเช่นกัน แนะนำให้เรียนรู้ FoundationDB ลองทำตาม tutorial และสำรวจความเป็นไปได้ในการใช้แทนระบบอย่าง RocksDB อ่านแนวทางการออกแบบ (Design Recipes) และงานวิจัยที่เกี่ยวข้อง ทำความเข้าใจข้อจำกัดการใช้งานและปัญหาที่แก้ได้ผ่านเอกสาร Anti-Features และ Features 6. TigerBeetle: ฐานข้อมูลที่ถูกต้องแม่นยำอย่างถึงที่สุด TigerBeetle เป็นฐานข้อมูลแบบ single-purpose ที่เชี่ยวชาญด้านธุรกรรมทางการเงิน แตกต่างจากฐานข้อมูลเอนกประสงค์ โดยมุ่งเน้นเป้าหมายเฉพาะ โดยเฉพาะ ธุรกรรมทางการเงิน เปิดเป็นโอเพนซอร์ส และออกแบบมาโดยมีเป้าหมายเรื่องความน่าเชื่อถือและความถูกต้องในระดับสูง ปรัชญาการออกแบบเพื่อความถูกต้องอย่างเข้มงวด นำ Power of Ten Rules ของ NASA และ Protocol-Aware Recovery มาใช้ ใช้ strict serialisability และ Direct I/O เพื่อหลีกเลี่ยงปัญหาที่เกี่ยวข้องกับ kernel page cache สามารถเห็นความพิถีพิถันนี้ได้จากเอกสารด้านความปลอดภัย (Safety doc) และรูปแบบการเขียนโปรแกรมเฉพาะตัวอย่าง "Tiger Style" แนวทางที่ล้ำสมัยด้วยการพัฒนาในภาษา Zig Zig เป็นภาษาสำหรับ system programming ที่ยังค่อนข้างใหม่ แต่เหมาะอย่างยิ่งกับเป้าหมายของ TigerBeetle ใช้จุดเด่นของ Zig เพื่อเพิ่มทั้งความกระชับและประสิทธิภาพให้สูงสุด ข้อเสนอแนะในการเรียนรู้และใช้งาน TigerBeetle ทดลองจำลองโมเดลบัญชีการเงินในสภาพแวดล้อมติดตั้งแบบ local: ติดตั้งและลองใช้งานตาม Quick Start อ่านเอกสารสถาปัตยกรรมระบบ (System Architecture docs) เพื่อสำรวจความเป็นไปได้ในการใช้ร่วมกับฐานข้อมูลเอนกประสงค์ ตัวอย่าง: ใช้งานร่วมกับ PostgreSQL หรือ FoundationDB เพื่อขยายกรณีใช้งาน 7. CockroachDB: ฐานข้อมูลระดับโลก CockroachDB เป็นฐานข้อมูลแบบกระจายระดับโลก รองรับ PostgreSQL wire protocol พร้อมการขยายแนวนอนและความสอดคล้องที่เข้มแข็ง เป็นการออกแบบที่ได้แรงบันดาลใจจาก Google Spanner ทำให้ขยายฐานข้อมูลข้ามหลายภูมิภาคได้ ลักษณะทางเทคนิคสำคัญของ CockroachDB เทคโนโลยีการซิงก์เวลา: Google Spanner ใช้นาฬิกาอะตอมและ GPS clock แต่ CockroachDB ถูกออกแบบให้ทำงานได้บนฮาร์ดแวร์ทั่วไป มีการชดเชยความหน่วงของการซิงก์ด้วย NTP, เปรียบเทียบ clock drift ระหว่างโหนด และตัดสมาชิกออกเมื่อเกิน maximum offset การตั้งค่าหลายภูมิภาค: ฟีเจอร์ Table Localities ช่วยให้ปรับแต่งตาม trade-off ระหว่างการอ่านและการเขียนได้ กระจายข้อมูลตามตำแหน่งทางภูมิศาสตร์ของผู้ใช้เพื่อปรับปรุงประสิทธิภาพและ latency ข้อเสนอแนะในการเรียนรู้การใช้ CockroachDB นำตัวอย่าง MovR มาสร้างใหม่: ใช้ภาษาและเฟรมเวิร์กที่ต้องการเพื่อสร้าง MovR (ตัวอย่างแอปพลิเคชันแบบกระจาย) ทดลองออกแบบแอประดับโลกโดยใช้กลยุทธ์ multi-region และ scaling ของ CockroachDB เหตุผลที่เลือก CockroachDB ต่างจากฐานข้อมูลแบบกระจายอื่นอย่าง DynamoDB ตรงที่สามารถรันฟรีในเครื่อง local ได้ มอบคุณสมบัติที่แตกต่างทั้งด้านความสอดคล้องที่เข้มแข็งและการรองรับการกระจายแบบ global Wrap Up ฐานข้อมูลที่แนะนำแต่ละตัวถูกออกแบบมาเพื่อแก้ปัญหาและตอบโจทย์ความต้องการที่แตกต่างกัน ในปี 2025 ลองเรียนรู้ฐานข้อมูลเหล่านี้และสำรวจวิธีแก้ปัญหาที่น่าสนใจและสร้างสรรค์ยิ่งขึ้นกัน!

(matt.blwt.io)

53 คะแนน โดย xguru 2024-12-09 | 14 ความคิดเห็น | แชร์ทาง WhatsApp

แนะนำฐานข้อมูล 7 ตัวที่ควรค่าแก่การจับตามองเพื่อใช้แก้ปัญหาที่หลากหลาย
นี่ไม่ใช่ลิสต์ "ฐานข้อมูลที่ดีที่สุด" แต่เป็นเครื่องมือที่มอบมุมมองใหม่และมีประโยชน์
ในปี 2025 อยากชวนให้ลองลงทุนเวลาอย่างละหนึ่งสัปดาห์กับฐานข้อมูลแต่ละตัว (7 DBs in 7 Weeks)

1. PostgreSQL: ฐานข้อมูลพื้นฐาน

PostgreSQL เป็นเทคโนโลยีที่มั่นคงและถูกใช้เป็นค่าเริ่มต้น
- วลี "Just use Postgres" เป็นทั้งมีมที่รู้จักกันอย่างแพร่หลายและสื่อถึงความน่าเชื่อถือ
- รองรับ ACID และมีความสามารถที่แข็งแกร่ง รวมถึงการทำ replication ทั้งแบบ physical และ logical
- เป็นฐานข้อมูลที่เสถียรและได้รับการสนับสนุนอย่างกว้างขวางจากผู้ให้บริการรายหลัก
เสน่ห์สำคัญที่สุดของ PostgreSQL: ความสามารถในการขยาย
- สามารถเพิ่มความสามารถเฉพาะทางได้ผ่าน Extensions
- ตัวอย่าง extension หลัก:
  - AGE: รองรับโครงสร้างข้อมูลกราฟและภาษา query แบบ Cypher
  - TimescaleDB: รองรับการทำงานกับข้อมูลอนุกรมเวลา
  - Hydra Columnar: มอบเอนจินจัดเก็บข้อมูลแบบคอลัมน์
- Extensions คือองค์ประกอบหลักที่ทำให้ PostgreSQL แตกต่างจากฐานข้อมูลอื่น
ประโยชน์ใช้สอยและความยืดหยุ่นของ PostgreSQL
- มี ecosystem ที่หลากหลาย พร้อมค่าเริ่มต้นที่สมเหตุสมผลและเป็นมิตรต่อผู้ใช้
- แม้แต่บริการที่ไม่ใช่ PostgreSQL ก็ยังใช้ Postgres wire protocol เพื่อให้เข้ากันได้กับไคลเอนต์
- เบาพอที่จะติดตั้งได้แม้ในสภาพแวดล้อม WebAssembly (Wasm)
แนะนำให้เรียนรู้ PostgreSQL
- คุ้มค่าที่จะลงทุนเวลาเพื่อเข้าใจศักยภาพและข้อจำกัดของ PostgreSQL
- ตัวอย่าง: ทำความเข้าใจความซับซ้อนของ MVCC(Multi-Version Concurrency Control)
- แนะนำให้ลองพัฒนาแอป CRUD แบบง่าย ๆ หรือเขียน PostgreSQL extension เอง

2. SQLite: ฐานข้อมูลแบบ local-first

SQLite เป็นฐานข้อมูลแบบ "local-first" ที่ทำงานได้อย่างอิสระ
- ไม่ยึดติดกับโมเดล client-server และทำงานอยู่ในสภาพแวดล้อมเดียวกับแอปพลิเคชัน
- ตัวอย่าง: WhatsApp และ Signal ใช้ SQLite ภายในอุปกรณ์เพื่อเก็บข้อมูลแชต
กรณีการใช้งาน SQLite ที่พัฒนาไปไกลกว่าเดิม
- นำไปใช้เชิงสร้างสรรค์ได้มากกว่าการเป็นฐานข้อมูลที่รองรับ ACID พื้นฐาน
- เครื่องมือและ extension ใหม่ ๆ:
  - Litestream: ทำ streaming backup ให้ SQLite
  - LiteFS: รองรับ distributed access เพื่อให้สร้าง topology ที่ยืดหยุ่นขึ้นได้
  - CR-SQLite: ใช้ CRDT(Conflict-free Replicated Data Types) เพื่อตัดความจำเป็นในการแก้ conflict ตอนรวม change set
การกลับมาได้รับความนิยมของ SQLite
- กำลังกลับมาได้รับความสนใจอีกครั้งจาก Ruby on Rails 8.0
- 37signals: พัฒนาโมดูล Rails (เช่น Solid Queue) บนพื้นฐานของ SQLite
  - รองรับการจัดการฐานข้อมูล SQLite หลายตัวใน Rails (database.yml)
- Bluesky: ใช้ฐานข้อมูล SQLite แยกต่อผู้ใช้เป็น Personal Data Servers
แนะนำให้เรียนรู้การใช้งาน SQLite
- ลองทดลองสถาปัตยกรรมแบบเน้น local ด้วย SQLite
- ทดสอบว่าสามารถแทนที่โมเดล client-server ที่เดิมใช้ PostgreSQL ด้วย SQLite ได้หรือไม่

3. DuckDB: ฐานข้อมูลที่ query ได้กับทุกสิ่ง

DuckDB เป็นฐานข้อมูลแบบ embedded ที่เชี่ยวชาญด้าน OLAP
- คล้าย SQLite ตรงที่ทำงานร่วมกับแอปพลิเคชัน แต่เน้นงาน OLAP แทน OLTP
- เป็นระบบที่ออกแบบมาโดยเน้นการวิเคราะห์ข้อมูลและการ query
คุณสมบัติ "Query-Anything" ของ DuckDB
- สามารถ query แหล่งข้อมูลหลากหลายได้โดยตรงด้วย SQL:
  - ฟอร์แมตไฟล์ทั่วไป เช่น CSV, TSV, JSON
  - รองรับฟอร์แมตขั้นสูงอย่าง Parquet
- ความสามารถนี้ให้ความยืดหยุ่นสูง เช่น ใช้วิเคราะห์สตรีมข้อมูลของ Bluesky
ความสามารถในการขยายและ ecosystem
- DuckDB ก็มี extensions เช่นกัน แต่ยังไม่หลากหลายเท่า Postgres (เพราะเป็นโปรเจ็กต์ที่อายุน้อยกว่า)
- มี extension จากชุมชนจำนวนมาก โดย gsheets (เชื่อมต่อ Google Sheets) น่าสนใจเป็นพิเศษ
แนะนำให้เรียนรู้การใช้ DuckDB
- ทดลองวิเคราะห์และประมวลผลข้อมูลผ่าน Python notebook หรือ Evidence
- ใช้ร่วมกับ SQLite: โยน analytical query ของฐานข้อมูล SQLite ไปให้ DuckDB เพื่อเพิ่มประสิทธิภาพ

4. ClickHouse: ฐานข้อมูลแบบคอลัมน์

ClickHouse เป็นฐานข้อมูลที่เชี่ยวชาญด้านงาน OLAP
- การจับคู่ PostgreSQL สำหรับ OLTP และ ClickHouse สำหรับ OLAP ถือว่าเหมาะมาก
- รองรับ workload เชิงวิเคราะห์ขนาดใหญ่ และรองรับความเร็วในการเขียนข้อมูลสูงผ่านการขยายแนวนอนและ sharding
คุณลักษณะสำคัญของ ClickHouse
- รองรับ hierarchical storage:
  - แยกจัดเก็บ "hot data" และ "cold data" ได้
  - ตัวอย่าง: เอกสารของ GitLab อธิบายกรณีใช้งานนี้ไว้อย่างละเอียด
- รองรับ dataset ขนาดใหญ่และการวิเคราะห์แบบเรียลไทม์:
  - เหมาะกับ dataset ที่ใหญ่เกินกว่าที่ DuckDB จะจัดการได้สะดวก
  - ให้ประสิทธิภาพสูงในสถานการณ์ที่ต้องการการวิเคราะห์แบบเรียลไทม์
ความสะดวกในการดูแลระบบ
- เอกสารด้านปฏิบัติการ เช่น การ deploy, scale, backup มีโครงสร้างดีและละเอียด
- ตัวอย่าง: มีเอกสารที่ลงลึกถึงวิธีตั้งค่า CPU ที่เหมาะสม
แนะนำให้เรียนรู้ ClickHouse
- ลองทดลองกับ dataset เชิงวิเคราะห์ขนาดใหญ่ หรือแปลงงานวิเคราะห์ที่ทำใน DuckDB มาใช้กับ ClickHouse
- ใช้ chDB ซึ่งเป็นเวอร์ชัน embedded ของ ClickHouse เพื่อเปรียบเทียบกับ SQLite ได้โดยตรงมากขึ้น

5. FoundationDB: ฐานข้อมูลแบบ layered

FoundationDB เป็นระบบที่มีเอกลักษณ์เฉพาะตัวในฐานะ "รากฐานของฐานข้อมูล"
- ถูกออกแบบเป็น key-value store แต่ทำงานเหมือน "พื้นฐาน" สำหรับสร้างฐานข้อมูล มากกว่าจะเป็นฐานข้อมูลแบบเรียบง่าย
- ถูกใช้งานโดยบริษัทใหญ่ เช่น Apple, Snowflake และ Tigris Data
คุณสมบัติสำคัญและข้อจำกัด
- ข้อจำกัด:
  - ข้อมูลธุรกรรมต้องไม่เกิน 10MB
  - ธุรกรรมต้องไม่เกิน 5 วินาทีนับจากการอ่านครั้งแรก
- ข้อจำกัดเหล่านี้ทำให้สามารถรองรับ ธุรกรรม ACID แบบสมบูรณ์ในสเกลขนาดใหญ่ ได้
  - ตัวอย่าง: มีกรณีการรันคลัสเตอร์ขนาดมากกว่า 100TiB
การออกแบบและการทดสอบของ FoundationDB
- ออกแบบมาให้เหมาะกับ workload เฉพาะประเภท
- พิสูจน์ความเสถียรและความสามารถในการขยายด้วย simulation testing:
  - Antithesis และฐานข้อมูลอื่น ๆ ก็ใช้ระเบียบวิธีการทดสอบแบบเดียวกัน
  - เอกสารอ้างอิงที่เกี่ยวข้อง: เอกสารของ Tyler Neely และ Phil Eaton
FoundationDB ในฐานะฐานข้อมูลแบบ "layered"
- การผูกกันระหว่าง storage engine กับ data model ค่อนข้างหลวม:
  - สามารถ remap storage engine ได้ในหลายเลเยอร์
  - ตัวอย่าง: Record Layer, Document Layer (จัดทำโดยองค์กร FoundationDB)
- กรณีศึกษาการออกแบบเลเยอร์จาก Tigris Data ก็น่าอ่านเช่นกัน
แนะนำให้เรียนรู้ FoundationDB
- ลองทำตาม tutorial และสำรวจความเป็นไปได้ในการใช้แทนระบบอย่าง RocksDB
- อ่านแนวทางการออกแบบ (Design Recipes) และงานวิจัยที่เกี่ยวข้อง
- ทำความเข้าใจข้อจำกัดการใช้งานและปัญหาที่แก้ได้ผ่านเอกสาร Anti-Features และ Features

6. TigerBeetle: ฐานข้อมูลที่ถูกต้องแม่นยำอย่างถึงที่สุด

TigerBeetle เป็นฐานข้อมูลแบบ single-purpose ที่เชี่ยวชาญด้านธุรกรรมทางการเงิน
- แตกต่างจากฐานข้อมูลเอนกประสงค์ โดยมุ่งเน้นเป้าหมายเฉพาะ โดยเฉพาะ ธุรกรรมทางการเงิน
- เปิดเป็นโอเพนซอร์ส และออกแบบมาโดยมีเป้าหมายเรื่องความน่าเชื่อถือและความถูกต้องในระดับสูง
ปรัชญาการออกแบบเพื่อความถูกต้องอย่างเข้มงวด
- นำ Power of Ten Rules ของ NASA และ Protocol-Aware Recovery มาใช้
- ใช้ strict serialisability และ Direct I/O เพื่อหลีกเลี่ยงปัญหาที่เกี่ยวข้องกับ kernel page cache
- สามารถเห็นความพิถีพิถันนี้ได้จากเอกสารด้านความปลอดภัย (Safety doc) และรูปแบบการเขียนโปรแกรมเฉพาะตัวอย่าง "Tiger Style"
แนวทางที่ล้ำสมัยด้วยการพัฒนาในภาษา Zig
- Zig เป็นภาษาสำหรับ system programming ที่ยังค่อนข้างใหม่ แต่เหมาะอย่างยิ่งกับเป้าหมายของ TigerBeetle
- ใช้จุดเด่นของ Zig เพื่อเพิ่มทั้งความกระชับและประสิทธิภาพให้สูงสุด
ข้อเสนอแนะในการเรียนรู้และใช้งาน TigerBeetle
- ทดลองจำลองโมเดลบัญชีการเงินในสภาพแวดล้อมติดตั้งแบบ local:
  - ติดตั้งและลองใช้งานตาม Quick Start
- อ่านเอกสารสถาปัตยกรรมระบบ (System Architecture docs) เพื่อสำรวจความเป็นไปได้ในการใช้ร่วมกับฐานข้อมูลเอนกประสงค์
- ตัวอย่าง: ใช้งานร่วมกับ PostgreSQL หรือ FoundationDB เพื่อขยายกรณีใช้งาน

7. CockroachDB: ฐานข้อมูลระดับโลก

CockroachDB เป็นฐานข้อมูลแบบกระจายระดับโลก
- รองรับ PostgreSQL wire protocol พร้อมการขยายแนวนอนและความสอดคล้องที่เข้มแข็ง
- เป็นการออกแบบที่ได้แรงบันดาลใจจาก Google Spanner ทำให้ขยายฐานข้อมูลข้ามหลายภูมิภาคได้
ลักษณะทางเทคนิคสำคัญของ CockroachDB
- เทคโนโลยีการซิงก์เวลา:
  - Google Spanner ใช้นาฬิกาอะตอมและ GPS clock แต่ CockroachDB ถูกออกแบบให้ทำงานได้บนฮาร์ดแวร์ทั่วไป
  - มีการชดเชยความหน่วงของการซิงก์ด้วย NTP, เปรียบเทียบ clock drift ระหว่างโหนด และตัดสมาชิกออกเมื่อเกิน maximum offset
- การตั้งค่าหลายภูมิภาค:
  - ฟีเจอร์ Table Localities ช่วยให้ปรับแต่งตาม trade-off ระหว่างการอ่านและการเขียนได้
  - กระจายข้อมูลตามตำแหน่งทางภูมิศาสตร์ของผู้ใช้เพื่อปรับปรุงประสิทธิภาพและ latency
ข้อเสนอแนะในการเรียนรู้การใช้ CockroachDB
- นำตัวอย่าง MovR มาสร้างใหม่:
  - ใช้ภาษาและเฟรมเวิร์กที่ต้องการเพื่อสร้าง MovR (ตัวอย่างแอปพลิเคชันแบบกระจาย)
- ทดลองออกแบบแอประดับโลกโดยใช้กลยุทธ์ multi-region และ scaling ของ CockroachDB
เหตุผลที่เลือก CockroachDB
- ต่างจากฐานข้อมูลแบบกระจายอื่นอย่าง DynamoDB ตรงที่สามารถรันฟรีในเครื่อง local ได้
- มอบคุณสมบัติที่แตกต่างทั้งด้านความสอดคล้องที่เข้มแข็งและการรองรับการกระจายแบบ global

Wrap Up

ฐานข้อมูลที่แนะนำแต่ละตัวถูกออกแบบมาเพื่อแก้ปัญหาและตอบโจทย์ความต้องการที่แตกต่างกัน
ในปี 2025 ลองเรียนรู้ฐานข้อมูลเหล่านี้และสำรวจวิธีแก้ปัญหาที่น่าสนใจและสร้างสรรค์ยิ่งขึ้นกัน!

14 ความคิดเห็น

wfedev 2025-11-28

สอบถามอะไรก็ได้! 😆🐤

budaestew 2024-12-16

ผมประหลาดใจมากที่ Duckdb มีประสิทธิภาพด้านการวิเคราะห์ที่ยอดเยี่ยมกว่าที่คิดไว้

halfenif 2024-12-09

หลายเดือนมานี้ผมใช้ sqlite อยู่ครับ เป็นงานที่ประมวลผลข้อมูลตามวันที่ ระดับประมาณ 2 ล้านรายการ ขนาดราว 5GB

ความเร็วในการประมวลผลก็น่าพอใจนะครับ.. แต่หลังจากแปลงข้อมูลแล้ว เวลาที่ใช้สร้างเป็นไฟล์ Excel อีกครั้งเพื่อส่งให้ผู้มีส่วนเกี่ยวข้องนั้นนานเกินไป

ดูเหมือนว่าคงต้องลองศึกษาแนวทางการใช้ OpenPyXl เพิ่มเติมหน่อยครับ

kimjj81 2024-12-18

ไม่รู้ว่ามีเวทมนตร์อะไรอยู่เบื้องหลัง แต่เขาบอกว่าใช้ชุดผสม duckDB + sqlite กันครับ

channprj 2024-12-09

น่าแปลกที่ไม่มีการพูดถึง MongoDB เลย

felizgeek 2024-12-09

ถ้าเป็นสภาพแวดล้อมที่กังวลเรื่องช่วงเรียนรู้ของนักพัฒนา ขอแนะนำ SQLite ครับ เพราะเป็นแบบไฟล์จึงใช้งานง่าย

savvykang 2024-12-09

ถ้ามั่นใจว่าไม่มีความต้องการการเข้าถึงระยะไกล นี่คือโซลูชันที่น่าพอใจมากจริง ๆ จุดที่ต้องดูแลจัดการ DB หายไป แถมยังแก้ไขข้อมูล รวมถึงสำรอง/กู้คืนได้ง่าย จึงดีมาก

aer0700 2024-12-09

พอพูดว่าจะใช้ SQLITE ก็มักจะโดนด่าได้ง่าย ๆ แต่ก่อนจะบอกว่าใช้ SQLITE ก็ไม่มีใครรู้เหมือนกันนะ... SQLITE ดีกว่าที่คิดครับ

jpumpkin94 2024-12-09

ผมใช้แต่ MySQL มาหลายสิบปี(??)แล้วครับ
อยากทราบว่า PostgreSQL เป็นอย่างไรบ้าง และหวังว่าจะมีคอมเมนต์จากหลาย ๆ ท่านที่ใช้งาน PostgreSQL ในโปรดักชันจริงอยู่ในสายงานมาแชร์กันครับ

zuppiy 2024-12-09

"ช้างเหนือกว่าแมวน้ำ"
นี่เป็นความจริงในสถานการณ์ส่วนใหญ่

roxie 2024-12-11

ฮ่าๆๆๆ

kibae 2024-12-09

ฉันย้ายจาก mysql ที่เต็มไปด้วยบั๊กในปี 2001 (ตอนนั้นเป็น v3.x) มาใช้ pgsql
แม้จะมีหลายจุดที่คิดว่าเหนือกว่า.. แต่ในโลกความเป็นจริง ฉันคิดว่าการมีอยู่ของ Partial Index คือฟีเจอร์ที่ทรงพลังที่สุด

chanhee 2024-12-09

เพราะงานที่บริษัท ผมเคยใช้แค่ Oracle กับ Sqlserver พอลองจะใช้ MySQL ก็เจอหลายอย่างมากที่ทำให้คิดว่า "ทำไมอันนี้ใช้ไม่ได้?" ตอนนี้ผมเองก็จำรายละเอียดได้ไม่แม่นแล้ว
สุดท้ายก็ย้ายมาใช้ Postgres ครับ

bbulbum 2024-12-09

พอย้ายจากที่ใช้ Postgres มาอยู่ที่ที่ใช้ MySQL ก็มีหลายอย่างที่ทำให้รู้สึกว่า ทำไมอันนี้ถึงทำไม่ได้? ทำไมประสิทธิภาพถึงไม่ออกมาแบบนี้?
จำไม่ได้ชัดเจนว่าเป็นเรื่องอะไรบ้าง (อาจจะเป็นเรื่องเล็กน้อยหรือไม่ก็ได้)