DriftDB จุดประกายการอภิปรายเรื่อง Event Sourcing และมาตรฐานฐานข้อมูลเชิงเวลา

DriftDB ฐานข้อมูลทดลองแบบ append-only ที่มีความสามารถในการเดินทางข้ามเวลา ได้ดึงดูดความสนใจจากนักพัฒนาที่คุ้นเคยกับสถาปัตยกรรม event sourcing และฐานข้อมูลเชิงเวลา โครงการนี้นำเสนอแนวทางที่เป็นเอกลักษณ์ในการจัดเก็บข้อมูล โดยการเปลี่ยนแปลงทั้งหมดจะถูกเก็บรักษาไว้เป็นเหตุการณ์ที่ไม่เปลี่ยนแปลง ทำให้ผู้ใช้สามารถสอบถามสถานะในอดีตได้ณจุดใดก็ตามในเวลา

คุณสมบัติหลักของ DriftDB :

• การจัดเก็บแบบ append-only พร้อมกับ drift events ที่ไม่สามารถเปลี่ยนแปลงได้
• การค้นหาข้อมูลย้อนเวลาโดยใช้คำสั่ง AS OF
• เซ็กเมนต์ที่ตรวจสอบด้วย CRC เพื่อความสมบูรณ์ของข้อมูล
• ดัชนี B-tree รองสำหรับการค้นหาที่รวดเร็ว
• การสร้าง snapshots ทุก 100k events หรือ 128MB
• สถาปัตยกรรมแบบ single writer, multi-reader
• ป้องกันการเสียหายจากการ crash ด้วย atomic writes และ fsync

ความน่าสนใจของสถาปัตยกรรม Event Sourcing

ฐานข้อมูลนี้ได้รับการตอบรับเป็นอย่างดีจากนักพัฒนาที่ชื่นชอบรูปแบบ event sourcing โดยเฉพาะ แนวทางสถาปัตยกรรมนี้จัดเก็บการเปลี่ยนแปลงทั้งหมดของสถานะแอปพลิเคชันเป็นลำดับของเหตุการณ์ แทนที่จะเก็บเพียงสถานะปัจจุบัน โมเดลการจัดเก็บแบบ append-only ของ DriftDB สอดคล้องกับปรัชญานี้อย่างสมบูรณ์แบบ ทำให้เป็นตัวเลือกที่น่าสนใจสำหรับระบบที่ต้องการร่องรอยการตรวจสอบที่สมบูรณ์และความสามารถในการสร้างประวัติศาสตร์ใหม่

ความสามารถของโครงการในการจัดการคำสั่งสอบถามการเดินทางข้ามเวลาผ่าน AS OF clauses ได้รับการเปรียบเทียบกับฐานข้อมูลอนุกรมเวลาอย่าง InfluxDB อย่างไรก็ตาม การอภิปรายเผยให้เห็นความแตกต่างที่สำคัญระหว่างประเภทของการสอบถามเชิงเวลาที่แตกต่างกัน - DriftDB มุ่งเน้นไปที่คำสั่งสอบถามย้อนกลับเวลาระบบ ซึ่งช่วยให้ผู้ใช้เห็นว่าฐานข้อมูลมีลักษณะอย่างไรในช่วงเวลาเฉพาะในประวัติศาสตร์

ประเภทของ Event ที่รองรับ:

• INSERT: เพิ่มแถวใหม่พร้อมเอกสารแบบเต็ม
• PATCH: อัปเดตบางส่วนโดยใช้ primary key
• SOFT_DELETE: ทำเครื่องหมายแถวว่าถูกลบแล้วในขณะที่ยังคงรักษา audit trail ไว้

มาตรฐานทางเทคนิคและความเข้ากันได้กับ SQL

ข้อเสนอแนะจากชุมชนได้เน้นย้ำถึงข้อพิจารณาทางเทคนิคที่น่าสนใจเกี่ยวกับมาตรฐาน SQL เชิงเวลา ข้อกำหนด SQL:2011 จริงๆ แล้วได้กำหนดโครงสร้างไวยากรณ์ที่แตกต่างจากที่ DriftDB ใช้งานในปัจจุบันสำหรับคำสั่งสอบถามเชิงเวลา ตามมาตรฐานที่กำหนดไว้ ตัวกรองเชิงเวลาควรปรากฏขึ้นทันทีหลังจากการอ้างอิงตาราง แทนที่จะอยู่ที่ท้ายคำสั่งสอบถาม

การอภิปรายนี้ชี้ให้เห็นถึงความท้าทายที่กว้างขึ้นในการใช้งานคุณสมบัติฐานข้อมูลเชิงเวลา ในขณะที่ยังคงความเข้ากันได้กับมาตรฐาน SQL ที่มีอยู่ โซลูชันที่มีอยู่แล้วหลายตัวอย่าง XTDB มีความสามารถที่คล้ายกันพร้อมการใช้งานที่เป็นผู้ใหญ่มากขึ้นและการปฏิบัติตาม SQL:2011 ที่เหมาะสม

ความขัดแย้งเรื่องเครื่องมือพัฒนา

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

ในฐานะ Senior Full Stack Developer ที่มีประสบการณ์มืออาชีพมากกว่า 26 ปี ฉันกำลังมีช่วงเวลาที่ดีที่สุดในชีวิตกับพลัง AI ใหม่เหล่านี้และประตูและการอภิปรายที่พวกเขาเปิดขึ้น

ความขัดแย้งนี้เน้นย้ำถึงภูมิทัศน์ที่เปลี่ยนแปลงไปของการพัฒนาซอฟต์แวร์ ที่แนวปฏิบัติการเขียนโค้ดแบบดั้งเดิมมาบรรจบกับเครื่องมือช่วยเหลือ AI สมัยใหม่ การอภิปรายสัมผัสกับคำถามเกี่ยวกับความแท้จริง ความคุ้มทุน และการเปิดเผยที่เหมาะสมของการมีส่วนร่วมของ AI ในการพัฒนาโครงการ

ทิศทางอนาคตและทางเลือก

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

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

อ้างอิง: DriftDB