นักพัฒนาฐานข้อมูลกำลังพูดถึงการนำ Multi-version Concurrency Control (MVCC) รุ่นใหม่ของ Turso ที่สัญญาจะแก้ไขข้อจำกัดการเขียนข้อมูลแบบ Single-writer ของ SQLite ที่มีมานาน การแสดงตัวอย่างทางเทคนิค ซึ่งเปิดตัวพร้อมกับฟีเจอร์ทดลอง ได้จุดประเด็นการอภิปรายอย่างร้อนแรงว่าควรจะพัฒนา SQLite ให้ก้าวข้ามข้อจำกัดการออกแบบดั้งเดิม หรือว่าควรให้นักพัฒนาไปใช้ฐานข้อมูลอื่นสำหรับเวิร์กโหลดที่ต้องการการทำงานพร้อมกันสูงแทน
การถกเถียงเรื่อง Single-Writer ร้อนขึ้น
หัวใจของข้อโต้แย้งอยู่ที่สถาปัตยกรรมพื้นฐานของ SQLite เป็นเวลาหลายปีที่นักพัฒนายอมรับว่า SQLite อนุญาตให้มีผู้เขียนข้อมูลได้เพียงคนเดียวในหนึ่งเวลา ซึ่งสามารถทำให้เกิดข้อผิดพลาด SQLITE_BUSY ในแอปพลิเคชันที่ต้องเขียนข้อมูลบ่อยครั้ง ในขณะที่สมาชิกในชุมชนบางส่วนแย้งว่าข้อจำกัดนี้เป็นส่วนหนึ่งของธรรมชาติแบบ Embedded ของ SQLite แต่บางส่วนมองว่ามันเป็นข้อจำกัดที่ไม่จำเป็นในระบบ multi-core สมัยใหม่
ผู้ใช้หนึ่งแสดงความคิดเห็นถึงผลกระทบในทางปฏิบัติ: ข้อจำกัด single-writer ใน SQLite นั้นเป็นต่อฐานข้อมูล ไม่ใช่ต่อการเชื่อมต่อ คุณสามารถแบ่งตาราง SQLite ของคุณออกเป็นหลายไฟล์ฐานข้อมูลและสอบถามข้อมูลจากทั้งหมดได้จากการเชื่อมต่อเดียว วิธีการแก้ปัญหาชั่วคราวนี้เป็นวิธีที่นักพัฒนาหลายคนใช้ แต่ก็มาพร้อมกับข้อเสียที่สำคัญเกี่ยวกับความปลอดภัยของธุรกรรมและความซับซ้อน
หากคุณใช้โหมด WAL คุณจะไม่ได้รับความปลอดภัยของธุรกรรม / ACID กับคำสั่ง ATTACH ยิ่งไปกว่านั้น ATTACH ไม่รองรับฐานข้อมูลมากกว่า 125 แห่ง ซึ่งจำกัดจำนวน shards ไว้ที่ 125
การอภิปรายเปิดเผยว่าในขณะที่การแบ่งข้อมูลข้ามไฟล์ฐานข้อมูลหลายไฟล์โดยใช้คำสั่ง ATTACH ให้ทางออกบางอย่าง แต่มันไม่สามารถรับประกัน ACID ที่แท้จริงข้ามฐานข้อมูลทั้งหมดเมื่อใช้โหมด WAL ข้อจำกัดนี้กลายเป็นเรื่องสำคัญสำหรับแอปพลิเคชันที่ต้องการธุรกรรมที่สอดคล้องกันข้ามหลายตาราง
การวิวัฒนาการของ SQLite เองและแนวทางที่แข่งขันกัน
ที่น่าสนใจคือ ทีม SQLite ก็ไม่ได้หยุดนิ่ง สมาชิกในชุมชนชี้ให้เห็นว่าทีม SQLite กำลังพัฒนาโหมด multi-writer ของตัวเองซึ่งพัฒนาต่อยอดจาก BEGIN CONCURRENT ไทม์ไลน์อย่างเป็นทางการของ SQLite แสดงการพัฒนาอย่างต่อเนื่องด้วยคอมมิตใหม่เจ็ดรายการในเดือนนี้เพียงเดือนเดียว ซึ่งชี้ให้เห็นว่าทั้งสองโปรเจกต์กำลังแข่งขันเพื่อเป้าหมายที่คล้ายกันผ่านแนวทางทางเทคนิคที่แตกต่างกัน
การนำ MVCC ของ Turso มาประยุกต์ใช้ได้รับแรงบันดาลใจจากระบบของ TokuDB โดยรักษาโครงสร้างข้อมูลในหน่วยความจำที่ติดตามหลายเวอร์ชันของแถวข้อมูล ซึ่งช่วยให้ธุรกรรมสามารถดำเนินไปอย่าง optimistic โดยตรวจสอบความขัดแย้งเฉพาะในช่วงเวลาที่ commit แทนที่จะบล็อกทันที แนวทางนี้แตกต่างจาก mvcc_CONCURRENT ที่ยังอยู่ในขั้นทดลองของ SQLite ซึ่งทำงานในระดับ page และสามารถทำให้เกิดการ rollback โดยไม่จำเป็นเมื่อการแก้ไขที่ไม่ได้เกี่ยวข้องกันเกิดขึ้นใน page เดียวกันของฐานข้อมูล
การเปรียบเทียบแนวทาง MVCC ระหว่าง SQLite และ Turso
ด้าน | SQLite แบบดั้งเดิม | SQLite Experimental mvcc_CONCURRENT | Turso MVCC |
---|---|---|---|
โมเดลการทำงานพร้อมกัน | Single-writer | การตรวจจับความขัดแย้งระดับเพจ | การกำหนดเวอร์ชันระดับแถว |
การแก้ไขความขัดแย้ง | การล็อกแบบเอกสิทธิ์ | Rollback เมื่อเกิดความขัดแย้งของเพจ | Optimistic concurrency control |
ผลกระทบต่อประสิทธิภาพ | ข้อผิดพลาด SQLITE_BUSY | อาจเกิด rollback ที่ไม่จำเป็น | การตรวจสอบความขัดแย้งเมื่อ commit |
ความปลอดภัยของธุรกรรม | ACID เต็มรูปแบบ | จำกัดในสถานการณ์หลายไฟล์ | รักษาความสอดคล้อง |
สถานะการพัฒนา | เสถียรสำหรับ production | สาขาทดลอง | Technology preview |
![]() |
---|
วิวัฒนาการของฐานข้อมูลที่คล้าย SQL โดยเน้นที่ฟีเจอร์การเขียนพร้อมกันของ Turso |
การประยุกต์ใช้และกรณีใช้งานในทางปฏิบัติเริ่มปรากฏ
การสนทนาเปิดเผยสถานการณ์ในโลกจริงหลายสถานการณ์ที่การเขียนข้อมูลพร้อมกันสามารถเปลี่ยนแปลงวิธีที่นักพัฒนาใช้ฐานข้อมูลประเภทคล้าย SQLite นักพัฒนาหนึ่งแบ่งปันประสบการณ์เกี่ยวกับการประมวลผลข้อมูล: การนำเข้าชุดข้อมูลแบบง่ายๆ มีการแทรกข้อมูลประมาณ 131 ล้านรายการ ใช้เวลา 10 นาที... มันคงจะดีกว่าถ้าสามารถทำได้ในครึ่งเวลา แม้ว่ากรณีการใช้งานเฉพาะนี้จะอาจไม่ได้รับประโยชน์จากการเขียนพร้อมกัน (ตามที่ผู้ใช้อีกท่านระบุ) แต่มันก็เน้นย้ำถึงความต้องการด้านประสิทธิภาพที่นักพัฒนาวางไว้บนระบบเหล่านี้
แอปพลิเคชันอื่นๆ ที่ถูกพูดถึงรวมถึงระบบอีคอมเมิร์ซที่ประมวลผลหลายธุรกรรมชำระเงินพร้อมกัน, ไปป์ไลน์การรับข้อมูลแบบเรียลไทม์, และแอปพลิเคชันที่ทำงานคำนวณภายในธุรกรรม ความสามารถในการรันงานรวมข้อมูลในพื้นหลังหรือการทำ inference ของแมชชีนเลิร์นนิงควบคู่ไปกับการดำเนินการฐานข้อมูลปกติ สามารถขยายประโยชน์การใช้ SQLite ในสถาปัตยกรรมแอปพลิเคชันสมัยใหม่ได้อย่างมีนัยสำคัญ
กรณีการใช้งานที่ระบุโดยชุมชนสำหรับการเขียนข้อมูลพร้อมกัน
- ระบบรับข้อมูลปริมาณสูงที่ต้องการการประมวลผลแบบขนาน
- แอปพลิเคชันที่ทำงานคำนวณภายในธุรกรรม
- แพลตฟอร์มอีคอมเมิร์ซที่ประมวลผลการชำระเงินพร้อมกัน
- การวิเคราะห์แบบเรียลไทม์พร้อมการเพิ่มข้อมูลอย่างต่อเนื่อง
- ระบบประมวลผลสตรีมที่แปลงเหตุการณ์เป็นข้อมูลในฐานข้อมูลโดยตรง
- งานรวบรวมข้อมูลเบื้องหลังที่ทำงานควบคู่ไปกับการดำเนินงานปกติ
![]() |
---|
อัตราการเขียนข้อมูลของ SQLite ระหว่างการแทรกข้อมูลเป็นชุดด้วยจำนวนเธรดที่แตกต่างกัน แสดงให้เห็นผลกระทบของโมเดลการเขียนแบบเธรดเดียว |
ความแตกแยกทางปรัชญา: วิวัฒนาการ vs. ความเชี่ยวชาญเฉพาะ
ความตึงเครียดพื้นฐานอยู่ภายใต้การอภิปรายทั้งหมด: SQLite ควรจะคงความสนใจในตลาดฐานข้อมูลแบบ Embedded ดั้งเดิม หรือควรจะวิวัฒนาการเพื่อแข่งขันกับฐานข้อมูลแบบ client-server? บางคนแย้งอย่างแข็งขันเพื่อความเชี่ยวชาญเฉพาะ: SQLite และ Postgres/MySQL/ฯลฯ ครองตำแหน่งที่ต่างกัน หากคุณต้องการการเขียนข้อมูลพร้อมกันจำนวนมหาศาล นั่นไม่ใช่สิ่งที่ Postgres/MySQL/ฯลฯ มีไว้สำหรับหรอกหรือ?
ผู้อื่นโต้แย้งด้วยตัวอย่างของวิวัฒนาการเครื่องมือที่ประสบความสำเร็จ: Linux ถูกออกแบบมาให้รันในพีซีตามบ้าน และเราก็ยังรันมันในซูเปอร์คอมพิวเตอร์ มันทำงานได้ดี เครื่องมือมีวิวัฒนาการ มุมมองนี้ชี้ให้เห็นว่าเทคโนโลยีฐานข้อมูลควรปรับตัวให้เข้ากับกรณีการใช้งานใหม่ แทนที่จะยังคงถูกจำกัดด้วยความตั้งใจในการออกแบบดั้งเดิม
การโต้แย้งขยายไปถึงข้อกังวลด้านการนำไปใช้ทางเทคนิค ด้วยคำถามเกี่ยวกับว่าการเปลี่ยนแปลง MVCC ของ Turso แบ่งปันระหว่างกระบวนการอย่างไร และมันเปรียบเทียบกับการพัฒนา hctree อย่างเป็นทางการของ SQLite อย่างไร สมาชิกในชุมชนบางส่วนแสดงความสงสัยเกี่ยวกับความพยายามทั้งหมดนี้ โดยสงสัยว่าการพยายามทำให้ SQLite จัดการกับผู้เขียนข้อมูลพร้อมกันหลายคนนั้นเหมือนกับการปรับรถสปอร์ตคันเล็กให้ลากพ่วงบรรทุกสินค้าขนาดใหญ่หรือไม่
มองไปข้างหน้าในภูมิทัศน์ฐานข้อมูล
ในขณะที่การอภิปรายยังคงดำเนินต่อไป ชัดเจนว่าทั้งสองแนวทางต่างมีข้อดี การวิวัฒนาการแบบอนุรักษ์นิยมของ SQLite รับประกันความเสถียรและความน่าเชื่อถือสำหรับฐานผู้ใช้จำนวนมหาศาล ในขณะที่โปรเจกต์เช่น Turso สำรวจนวัตกรรมที่ก้าวร้าวมากขึ้น การมีส่วนร่วมอย่างกระตือรือร้นของชุมชนกับทั้งรายละเอียดทางเทคนิคและคำถามเชิงปรัชญาแสดงให้เห็นว่านักพัฒนาให้ความสำคัญกับตัวเลือกโครงสร้างพื้นฐานพื้นฐานเหล่านี้มากเพียงใด
ฟีเจอร์การเขียนข้อมูลพร้อมกันใน Turso ยังคงอยู่ในขั้นทดลอง โดยมีข้อจำกัดที่ได้รับการยอมรับเกี่ยวกับการดำเนินการ DELETE และประสิทธิภาพของหน่วยความจำ อย่างไรก็ตาม การมีอยู่ของฟังก์ชันการทำงานนี้—และการอภิปรายที่มีชีวิตชีวาที่มันจุดประกาย—ชี้ให้เห็นว่าภูมิทัศน์ฐานข้อมูลยังคงวิวัฒนาการในทิศทางที่คาดไม่ถึง ไม่ว่านวัตกรรมเหล่านี้จะส่งประโยชน์แก่นักพัฒนากระแสหลักในที่สุดหรือจะยังคงเป็นโซลูชันเฉพาะทางนั้นขึ้นอยู่กับการดำเนินการทางเทคนิคและการยอมรับจากชุมชนในเดือนข้างหน้า
MVCC (Multi-version Concurrency Control): วิธีการที่อนุญาตให้หลายธุรกรรมเข้าถึงข้อมูลเดียวกันได้พร้อมกันโดยการรักษาเวอร์ชันต่างๆ ของข้อมูลนั้น แทนที่จะล็อกข้อมูลเพื่อธุรกรรมเดียวในหนึ่งเวลา
อ้างอิง: Beyond the Single-Writer Limitation with Turso's Concurrent Writes