ความเข้าใจผิดเกี่ยวกับ SQLite-on-the-Server: เหมาะกับงานระดับ Hyper-Scale มากกว่างานขนาดเล็ก
(rivet.gg)- นักพัฒนาจำนวนมากมองว่า การใช้ SQLite บนเซิร์ฟเวอร์เหมาะกับแอปพลิเคชันขนาดเล็กเท่านั้น
- เหตุผลมีดังนี้:
- ต้นทุนโครงสร้างพื้นฐานต่ำ: ไม่จำเป็นต้องมีเซิร์ฟเวอร์ฐานข้อมูลแยกต่างหาก (ทำงานเป็นไฟล์เดียว)
- พัฒนาและทดสอบได้ง่าย: สามารถใช้ไฟล์ DB เดียวกันได้ทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์
- ภาระการดูแลต่ำที่สุด: ไม่ต้องตั้งค่าที่ซับซ้อนหรือจัดการเดมอน
- ความน่าเชื่อถือสูง: SQLite เป็น DB ที่ถูกแจกจ่ายใช้งานมากที่สุดในโลก และมีความทนทานสูง
- เครื่องมืออย่าง LiteFS, Litestream, rqlite, Dqlite, Bedrock เพิ่มความสามารถด้าน replication และ high availability (HA) ให้ SQLite ทำให้เหมาะกับการดีพลอยขนาดเล็ก
แต่บทความนี้สำรวจ ศักยภาพของ SQLite สำหรับแอปพลิเคชันระดับ Hyper-Scale ไม่ใช่แค่ขนาดเล็ก
ปัญหาของการขยายฐานข้อมูลขนาดใหญ่แบบเดิม
- แอปพลิเคชันขนาดใหญ่มักรักษา PostgreSQL หรือ MySQL ให้เป็น DB เดียวต่อไปได้ยาก จึงใช้ ฐานข้อมูลแบบ sharding
- ตัวอย่าง: Cassandra, ScyllaDB, DynamoDB, Vitess (MySQL แบบ sharding), Citus (Postgres แบบ sharding)
- DB แบบ sharding มีข้อดีดังนี้:
- ปรับแต่ง batch read ได้ดีขึ้นผ่านการแบ่งพาร์ทิชันข้อมูล
- ขยายแนวนอน (scalability) ได้
- ให้ ประสิทธิภาพการเขียนที่รวดเร็ว
แต่โซลูชันการแบ่งพาร์ทิชันในปัจจุบันมี ข้อเสียต่อไปนี้
- สคีมาที่ตายตัว (Rigid Schemas): ไม่รองรับการคิวรีที่ยืดหยุ่นแบบ MySQL หรือ Postgres
- เปลี่ยนสคีมายาก: เมื่อเพิ่มดัชนีหรือเปลี่ยนความสัมพันธ์ ภาระในการปฏิบัติการจะสูง
- การทำงานข้ามพาร์ทิชันที่ซับซ้อน: รักษาธุรกรรม ACID ได้ยาก และต้องใช้เทคนิคซับซ้อนอย่าง two-phase commit (2PC)
- ปัญหาความไม่สอดคล้องของข้อมูล: บังคับใช้ข้อจำกัดข้อมูลที่เข้มงวดระหว่างพาร์ทิชันได้ยาก และมีโอกาสที่ความถูกต้องสอดคล้องของข้อมูลจะเสียหาย
ความเป็นไปได้ของฐานข้อมูล Hyper-Scale ที่อิง SQLite
- Cloudflare Durable Objects และ Turso แสดงให้เห็น แนวทางออกแบบแอปพลิเคชันระดับ Hyper-Scale บนพื้นฐานของ SQLite
- ระบบเหล่านี้มีจุดแข็งดังนี้:
- การขยายแบบไดนามิก (Dynamic Scaling): สร้างฐานข้อมูลแยกตามเอนทิตี (Entity) เพื่อลดความซับซ้อนของโครงสร้างพื้นฐาน
- ฐานข้อมูลต้นทุนต่ำจำนวนไม่จำกัด: ไม่ได้บังคับให้แบ่งพาร์ทิชันข้อมูลแบบ sharding เดิม และสามารถสร้างอินสแตนซ์ SQLite ใหม่ได้ทุกเมื่อที่ต้องการ
- การกระจายตัวทั่วโลก (Global Distribution): วางฐานข้อมูลไว้ใกล้ผู้ใช้เพื่อเพิ่มประสิทธิภาพ
- replication และ durability ในตัว (Built-in Replication & Durability): ต่างจาก SQLite แบบเดิม โดยทำ replication ข้อมูลข้ามหลายภูมิภาคเพื่อคง high availability
- แนวทางแทนที่ sharding ด้วย SQLite (ใช้ Cloudflare Durable Objects & Turso)
- ในวิธี sharding แบบเดิม จะเก็บล็อกแชตหลายรายการไว้ในพาร์ทิชันฐานข้อมูลเดียว
- หากใช้ SQLite สามารถ สร้างฐานข้อมูล SQLite แยกอิสระสำหรับแต่ละช่อง เพื่อใช้สคีมาที่ยืดหยุ่นกว่าได้
- โครงสร้างตัวอย่าง
- sharding แบบเดิม: ตารางล็อกแชต + คีย์พาร์ทิชัน
- แบบอิง SQLite: SQLite DB แยกต่อช่อง (รวมล็อกแชต ผู้เข้าร่วม และข้อมูลรีแอ็กชัน)
- ข้อดีของแนวทางนี้เมื่อใช้ SQLite มีดังนี้:
- คงธุรกรรม ACID ภายในเครื่อง: สามารถทำธุรกรรมภายใน DB แต่ละตัวได้โดยไม่มีปัญหาข้ามพาร์ทิชัน
- I/O ประสิทธิภาพสูง: เนื่องจาก SQLite เป็น DB แบบไฟล์เดียว ประสิทธิภาพการอ่านและเขียนจึงดีมาก
- ใช้ความสามารถส่วนขยายของ SQL ได้:
- FTS5 (Full-Text Search): เพิ่มประสิทธิภาพการค้นหา
- JSON1: รองรับการจัดเก็บและคิวรีข้อมูล JSON
- R*Tree, SpatiaLite: ใช้งานข้อมูลเชิงพื้นที่ได้
- รองรับ SQL migration: ใช้งานร่วมกับเครื่องมือ migration เดิมอย่าง Prisma, Drizzle ได้
- รองรับ lazy schema migration:
- ไม่จำเป็นต้องรัน migration ทันที แต่สามารถใช้วิธีทำ migration แบบเบาเมื่อเปิดอินสแตนซ์ SQLite ได้
ข้อจำกัดของการใช้ SQLite บนเซิร์ฟเวอร์
- ยังมีโซลูชันโอเพนซอร์สที่โฮสต์เองได้ไม่มาก
- ไม่รองรับคิวรีข้ามฐานข้อมูล → หากต้องการงานวิเคราะห์ยังต้องมี data lake แยกต่างหาก
- เครื่องมือสำหรับฐานข้อมูลยังมีจำกัด (SQL browser, ETL pipeline, monitoring, backup)
- StarbaseDB กำลังแก้ปัญหานี้บนพื้นฐาน Cloudflare Durable Objects + SQLite
- ยังขาดโปรโตคอลมาตรฐานแบบรวมศูนย์
- PostgreSQL, MySQL, Cassandra ใช้โปรโตคอลที่เป็นมาตรฐาน แต่ SQLite server ยังขาดโปรโตคอลเครือข่ายมาตรฐาน
- ยังมีกรณีใช้งานขนาดใหญ่ของ SQLite ในระดับ Hyper-Scale ไม่มาก
- แม้ยังไม่มีกรณีศึกษาแบบ Cassandra หรือ DynamoDB มากนัก แต่มีแนวโน้มว่าจะเปลี่ยนไปตามเวลา
บทสรุป: SQLite ไม่ได้เป็นเพียง DB ภายในเครื่องแบบเรียบง่าย แต่เป็นตัวเลือกที่ทรงพลังสำหรับแอปพลิเคชันระดับใหญ่มากด้วย
- SQLite ไม่ใช่แค่ DB สำหรับโปรเจ็กต์เล็ก ๆ แต่เป็นเครื่องมือทรงพลังที่สามารถทดแทนวิธี sharding แบบเดิมในแอปพลิเคชันระดับ Hyper-Scale ได้
- เมื่อใช้ Cloudflare Durable Objects & Turso จะสามารถ แบ่งฐานข้อมูลตามระดับเอนทิตี และขยายระบบได้โดยยังคงความสามารถอันทรงพลังของ SQL และธุรกรรม ACID ไว้
- มีแนวโน้มสูงที่จะกลายเป็น ทางเลือกที่ยืดหยุ่นกว่าและจัดการง่ายกว่าฐานข้อมูลแบบ sharding ดั้งเดิม
2 ความคิดเห็น
ใครกันจะกล้าพอที่จะเต็มใจใช้ sqlite ในระดับไฮเปอร์สเกลที่ต้องรองรับคำขอจำนวนมหาศาล...
ความคิดเห็นจาก Hacker News
ผู้ใช้คนหนึ่งกำลังพิจารณาแทนที่ฐานข้อมูลแบบกำหนดเองด้วย SQL
Sqlite3ถูกพิจารณาเป็นตัวเลือกเพราะทำงานบนเซิร์ฟเวอร์เดี่ยวSqlite3ได้เปรียบSqlite3กับPostgresqlผ่านการทดสอบ benchmarkSqlite3เร็วกว่าPostgresqlประมาณสองเท่าในทุกงานSqlite3100 ถึง 1,000 เท่าในการเข้าถึงเรคคอร์ดเดี่ยวผู้ใช้รายหนึ่งกำลังพัฒนาเว็บแอปแบบ local-first และคิดว่า SQLite เหมาะสม
มีการพูดคุยถึงข้อดีของ SQLite-Per-Partition
ในสภาพแวดล้อมแบบหลายผู้ใช้ SQLite ประสบความยากลำบากเนื่องจากขาด MVCC
Ruby on Rails รุ่น 8.0 ขยายการรองรับ SQLite
ผู้ใช้ที่ไม่คุ้นเคยกับ Vitess หรือ Citus เข้าใจเนื้อหาของบทความได้ยาก
ผู้ใช้คนหนึ่งไม่ต้องการโฮสต์ VPS จึงสร้างหน้าเว็บโดยใช้ SQLite
ผู้ใช้ที่ประสบปัญหาในการตั้งค่า Ubiquiti controller เสนอให้ใช้ SQLite
Apple ดำเนินการอินสแตนซ์ Cassandra/ScyllaDB ราว 300,000 ตัว ณ ปี 2022
TDLib (ไลบรารีฐานข้อมูลของ Telegram) ใช้ SQLite