SQLite: ฐานข้อมูลที่ถูกปรับใช้มากที่สุดที่ผู้ดูแลระบบส่วนใหญ่เพิกเฉย

ประเด็นสำคัญ

• Serverless เป็นคุณลักษณะ ไม่ใช่การขาดหายไป: การเรียกใช้ไลบรารี ไม่มี daemons ไม่มีซ็อกเก็ตเครือข่าย ไม่มีการกำหนดค่า สำหรับการวิเคราะห์แบบกระบวนการเดียวและแอปขนาดเล็ก พื้นผิวการปรับใช้งานจะเข้าใกล้ศูนย์
• การเห็นพร้อมกันเป็นข้อจำกัดที่จำกัด: โหมด WAL จะเพิ่มตัวอ่านที่เกิดขึ้นพร้อมกันด้วยตัวเขียนหนึ่งคน N-Threads-of-writers ในกระบวนการอิสระหลายกระบวนการมีกลิ่นการออกแบบทันที: ไฟล์ฐานข้อมูลไม่ได้มีไว้สำหรับการโฮสต์หลายเครื่อง
• ความซื่อสัตย์ในการจัดเก็บ: ไฟล์เป็นฐานข้อมูล ซึ่งทำให้การสำรองข้อมูลเป็นเรื่องง่าย (การคัดลอกสดผ่าน .backup API หรือ VACUUM INTO ไม่ใช่ cp ระหว่างการเขียน!) และหายนะในการจัดวางอย่างไม่ระมัดระวัง (การล็อกไฟล์ระดับ NFS เป็นคติชนวิทยา; ดิสก์ในเครื่องหรือความเข้าใจที่มั่นคงเกี่ยวกับข้อเท็จจริงที่ว่าซีแมนทิกส์การล็อกล้มเหลวผ่าน NFS เป็นสิ่งจำเป็น)
• ความเสถียรของรูปแบบไฟล์ถือเป็นความสำเร็จที่หาได้ยาก: ไฟล์ที่เขียนเมื่อหลายสิบปีก่อนยังคงเปิดต่อไปอีกเป็นเวลาหลายทศวรรษ เวิร์กโฟลว์ข้อมูลทางนิติวิทยาศาสตร์/การวิจัย การจัดเก็บการกำหนดค่า และแคชของแอป ล้วนได้รับประโยชน์จากรูปแบบที่ไม่เคยทำให้วงจรการอัปเดตเกิดความประหลาดใจ
• ไม่สามารถสันนิษฐานได้ว่ามีขนาดเล็ก: SQLite ขับเคลื่อนระบบการบินและแคชระดับเบราว์เซอร์ เพดานในทางปฏิบัติมักจะแสดงรอบโหลดการเขียนพร้อมกันหรือข้อกำหนด HA ไม่ใช่ขนาดข้อมูลทั้งหมด (เกินกว่าการดำเนินการคลาสเทราไบต์ขอบเขตแคชที่มีอยู่)
• ขอบเขตอยู่ที่ไหน: การวิเคราะห์แบบผู้เขียนคนเดียว, พื้นที่จัดเก็บภายในแอป, อุปกรณ์ Edge, ระยะ MVP ต้นแบบสู่การผลิต ทันทีที่เซิร์ฟเวอร์หลายเครื่องหรือผู้เขียนพร้อมกันแบบเรียลไทม์เข้ามาในรูปภาพ ให้เปลี่ยนไปใช้ PostgreSQL หรือ MySQL อย่างตรงไปตรงมา แทนที่จะบังคับฟอร์แมต

บันทึกจากหน้างาน

ไฟล์ SQLite ที่บรรทุกกลุ่มอุปกรณ์เป็นเวลาเจ็ดปีไม่เคยมีปัญหาคอขวด แต่ความล้มเหลวในการสำรองข้อมูลทุกครั้งที่เราเห็นนั้นมาจาก cp ระหว่างการเขียน แทนที่จะเป็นระเบียบวินัย VACUUM INTO เพื่อความปลอดภัยของไฟล์ในเครื่อง การสำรองข้อมูลที่ถูกต้องนั้นมาพร้อมกับเครื่องมือ ไม่ใช่พฤติกรรมการดิสโทร

คำถามที่พบบ่อย