เหตุใดจึงไม่อนุญาตให้เขียนพร้อมกันในฐานข้อมูล SQLite

ฉันกำลังเขียนโปรแกรมฐานข้อมูลโดยใช้ Java กับ SQLite

ฉันพบว่าการเชื่อมต่อครั้งเดียวเท่านั้นไปยังฐานข้อมูลมีความสามารถในการเขียนในขณะที่การเชื่อมต่อหลายครั้งพร้อมกันมีความสามารถในการอ่าน

ทำไมสถาปัตยกรรมของ SQLite จึงถูกออกแบบมาเช่นนี้ ตราบใดที่ทั้งสองสิ่งที่กำลังเขียนไม่ได้ถูกเขียนไปยังที่เดียวกันในฐานข้อมูลเหตุใดจึงไม่สามารถเขียนสองรายการได้ในคราวเดียว

database concurrency sqlite

— SteelToe
แหล่งที่มา

ที่เกี่ยวข้อง (อาจซ้ำกัน): SQLite ที่มีกระบวนการหลามสองเข้าถึง: หนึ่งอ่านหนึ่งเขียน

— gnat

เนื่องจาก SQLite ได้รับการออกแบบให้เป็น "lite" หน่วยความจำต่ำและการประมวลผลต่ำพร้อมประสิทธิภาพ คิดถึงวิธีที่คุณจะทำให้ SQLite จัดการกับการเขียนหลาย ๆ ไฟล์ในไฟล์เดียวกัน การออกแบบปัจจุบันใช้งานง่าย - ไฟล์ทั้งหมดถูกล็อคและอื่น ๆ ต้องรอ ในการจัดการการเขียนพร้อมกันที่ระดับความละเอียดต่ำกว่าต้องมีการล็อกแถว / หน้าซึ่งคุณได้รับจาก RDMS หากความต้องการที่ต้องการเขียนพร้อมกันแล้ว SQLite ไม่ใช่ผู้สมัครและคุณควรมองหา RDBMS ที่มีน้ำหนักเบา: en.wikipedia.org/wiki/…

— Thomas Carlisle

คำตอบ:

157

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

การสนับสนุนการเขียนพร้อมกันระดับสูงเป็นจุดเด่นของเอ็นจินฐานข้อมูลขนาดใหญ่เช่น DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL และ Sybase แต่ก็ยากที่จะประสบความสำเร็จในทางเทคนิคต้องกว้างขวางควบคุมภาวะพร้อมกันและการเพิ่มประสิทธิภาพกลยุทธ์ดังกล่าวเป็นฐานข้อมูลตารางและล็อคแถวหรือในการใช้งานที่ทันสมัยมากขึ้นหลายรุ่นควบคุมภาวะพร้อมกัน การวิจัยเกี่ยวกับปัญหานี้ / ความต้องการเป็นใหญ่โตและไปกลับทศวรรษที่ผ่านมา

SQLite มีปรัชญาการออกแบบที่แตกต่างจาก DBMS ส่วนใหญ่ที่ใช้เซิร์ฟเวอร์ซึ่งสนับสนุนตัวเขียนหลายตัว มันถูกออกแบบมาเพื่อนำพลังของ SQL และโมเดลเชิงสัมพันธ์มาสู่แอพพลิเคชั่นแต่ละตัว เป้าหมายนั้นต้องการการแลกเปลี่ยนที่สำคัญ การไม่เพิ่มโครงสร้างพื้นฐานที่สำคัญและค่าใช้จ่ายที่จำเป็นในการจัดการผู้เขียนหลายคนพร้อมกันเป็นหนึ่งในนั้น

ปรัชญาสามารถสรุปโดยคำสั่งในหน้าการใช้งานที่เหมาะสมของ SQLite :

SQLite ไม่แข่งขันกับฐานข้อมูลลูกค้า / เซิร์ฟเวอร์ SQLite แข่งขันกับ fopen ()

— Jonathan Eunice
แหล่งที่มา

+1 SQLite เป็นฐานข้อมูลระหว่างดำเนินการ ไม่มีอาร์บิทเตอร์กลางเหมือนอยู่ในฐานข้อมูลบนเซิร์ฟเวอร์ ผู้เขียนจะต้องร่วมมือโดยตรงและไว้วางใจซึ่งกันและกัน นักเขียนที่เป็นอันตรายเพียงคนเดียวอาจสร้างความเสียหายได้เพียงโดยไม่ให้ความร่วมมือ

— Jörg W Mittag

นอกจากนี้สภาพแวดล้อมบางส่วนที่ SQLite ดำเนินการอาจไม่สนับสนุนกระบวนการหลายอย่าง

— david25272

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

— bdsl

ในแอพที่เกิดขึ้นพร้อมกันนั้นมีพื้นที่ตรงกลางไม่มากนัก ไม่ว่าคุณจะได้รับการทำงานพร้อมกันความสอดคล้องและความถูกต้องของข้อมูลเป็นหลัก 100% ของเวลารวมถึงภายใต้เงื่อนไขที่ท้าทายและกรณีขอบหรือคุณไม่ ถ้าคุณทำไม่ได้มันเปราะบางช้าและชนง่ายและผู้คนหยุดไว้วางใจอย่างรวดเร็ว แต่การทำให้ถูกต้องเป็นประจำนั้นเป็นเรื่องยากลำบากอย่างโหดเหี้ยม มีหลายกรณีที่ผู้เขียนไม่สามารถสนับสนุนการเขียนหลักได้

— Jonathan Eunice

@bdsl ฐานข้อมูลทุกประเภทต้องถือว่าผู้เขียนจะไม่ประพฤติตัวดีดังนั้นพวกเขาจะไม่สูญเสียข้อมูล ผู้เขียน SQLite วางตำแหน่งให้เป็นคู่แข่งfopen()ดังนั้นให้พิจารณาความดกทั้งหมดที่มาพร้อมกับการเขียนพร้อมกันไปยังไฟล์ข้อความธรรมดา

— Blrfl

เพราะไม่มีเซิร์ฟเวอร์ที่สามารถบอกได้ว่าสิ่งต่าง ๆ จะถูกเขียนไปยังที่เดียวกันหรือไม่ มีเพียงสองกระบวนการที่พยายามเขียนลงไฟล์

ตามที่ระบุไว้ในความคิดเห็นการเขียนพร้อมกันอาจได้รับการสนับสนุนโดยเธรดภายใน ไม่แน่ใจว่ามันจะทำงานได้ดีแค่ไหน (ก็ไม่ได้คิดมากเหมือนกัน) อย่างไรก็ตามนี่คือเหตุผลที่ SQLite ไม่ใช้เธรด: Dr Hipp คิดว่าเธรดนั้นชั่ว

ความจริงที่ว่า DR Hipp คิดว่าหัวข้อเป็นความชั่วร้ายจะถูกบันทึกไว้ในSQLite คำถามที่พบบ่อย

— Goyo
แหล่งที่มา

สิ่งนี้อธิบายถึงเหตุผลทางเทคนิคว่าทำไมจึงไม่อนุญาตให้เขียนพร้อมกัน แต่ไม่ใช่เหตุผลการตัดสินใจออกแบบ

— Robert Harvey

การตัดสินใจออกแบบ SQLite เพื่อให้สามารถจัดการกับการเขียนครั้งละหนึ่งรายการเท่านั้น

— Robert Harvey

@Goyo เซิร์ฟเวอร์ไม่จำเป็นต้องจัดการกับการเขียนพร้อมกัน: เซิร์ฟเวอร์ฐานข้อมูลเป็นกระบวนการที่แยกต่างหากอาจมีเธรดแยกต่างหากภายในกับ SQLite ที่ให้บริการเพื่อวัตถุประสงค์เดียวกัน Robert Harvey ถูกต้อง: มีการตัดสินใจออกแบบโดยทีม SQLite และไม่มีอะไรเกี่ยวข้องกับความสามารถของไลบรารีเดียวในการจัดการการเขียนพร้อมกัน (เพราะในทางทฤษฎีแล้ว)

คำตอบนี้ดูเหมือนดีสำหรับฉัน เมื่อต้องการจัดการการเขียนพร้อมกันดูเหมือนว่าจะต้องมีเซิร์ฟเวอร์หรือการใช้งานหลายเธรด sqlite เนื่องจากทั้งสองข้อได้รับการตัดออกจากการตัดสินใจออกแบบอื่น ๆ การใช้การเขียนพร้อมกันจึงเป็นเรื่องยากอย่างยิ่ง

— jpa

@jpa: SQLite จัดการการซิงโครไนซ์การล็อกระหว่างหลายกระบวนการ / เธรดโดยไม่มี "เซิร์ฟเวอร์" อยู่แล้ว ไม่จำเป็นต้องใช้ "เซิร์ฟเวอร์" - โดยใช้การล็อค / การซิงโครไนซ์ / IPC / ที่ได้รับจากระบบปฏิบัติการของ OS: อะไรก็ตามที่เพียงพอ แต่ได้รับความซับซ้อนอย่างรวดเร็วจริง "หัวข้อภายใน" ที่กล่าวถึงในโพสต์ไม่สมเหตุสมผล

— Mat