หยุดซิงก์ข้อมูลทั้งหมด

 (sqlsync.dev)
1 คะแนน โดย GN⁺ 2025-04-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

แนวทางใหม่สำหรับการทำ Edge Replication

  • การซิงก์ข้อมูลเป็นปัญหาที่ยากกว่าที่คิด โซลูชันเดิมมักแบ่งเป็นการซิงก์ชุดข้อมูลทั้งหมดไปยังไคลเอนต์ หรือการติดตามการเปลี่ยนแปลงเชิงตรรกะ
  • Graft ถูกออกแบบมาเพื่อแก้ปัญหานี้ และเป็นโอเพนซอร์ส storage engine ที่ผสาน physical replication แบบเรียบง่ายเข้ากับ logical replication ที่มีประสิทธิภาพ

Lazy Sync: ซิงก์ด้วยความเร็วที่คุณต้องการ

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

Partial Sync: ซิงก์เฉพาะสิ่งที่จำเป็น

  • ในสภาพแวดล้อม edge ไม่สามารถดาวน์โหลดชุดข้อมูลทั้งหมดได้ ดังนั้น Graft จึงรองรับ partial sync ที่ดึงมาเฉพาะเพจที่จำเป็น
  • Graft สามารถดึงเพจที่จำเป็นล่วงหน้าได้โดยใช้ทั้งอัลกอริทึมการคาดการณ์ทั่วไปและความรู้เฉพาะโดเมน

Edge: ซิงก์ใกล้กับจุดที่ต้องใช้

  • Graft ให้บริการข้อมูลผ่าน edge server ทั่วโลก เพื่อคงค่า latency ต่ำและการตอบสนองสูงไม่ว่าผู้ใช้จะอยู่ที่ใด
  • ไคลเอนต์ถูกออกแบบให้มีน้ำหนักเบา จึงผสานเข้ากับเบราว์เซอร์ แอปมือถือ และสภาพแวดล้อม serverless ได้ง่าย

ความสอดคล้อง: การซิงก์ที่ปลอดภัย

  • Graft มี consistency model ที่แข็งแกร่ง เพื่อจัดการความขัดแย้งระหว่างไคลเอนต์ได้อย่างปลอดภัย
  • ไคลเอนต์สามารถมองเห็นข้อมูลที่สอดคล้องกันผ่านโมเดล snapshot isolation และการเขียนจะถูก serialize อย่างเคร่งครัด

จะสร้างอะไรได้บ้างด้วย Graft?

  • Graft มอบรากฐานที่แข็งแกร่งสำหรับแอปพลิเคชัน edge-native หลากหลายรูปแบบ
  • รองรับทั้งแอปแบบ offline-first, ข้อมูลข้ามแพลตฟอร์ม, read replica แบบไร้สถานะ และการทำ data replication ตามต้องการ

ส่วนขยาย Graft SQLite (libgraft)

  • libgraft เป็นส่วนขยายแบบเนทีฟของ SQLite ที่ทำให้ไคลเอนต์จำลองข้อมูลเฉพาะส่วนของฐานข้อมูลที่ใช้งานจริงได้ จึงสามารถรัน SQLite ได้แม้ในสภาพแวดล้อมที่มีทรัพยากรจำกัด
  • มีฟีเจอร์อย่าง asynchronous replication, lazy partial replication, snapshot isolation และ point-in-time recovery

วิธีมีส่วนร่วม

  • Graft พัฒนาบน GitHub และยินดีรับการมีส่วนร่วมจากชุมชน
  • สามารถเข้าร่วม Discord หรือส่งฟีดแบ็กทางอีเมลได้
  • สามารถลงชื่อใน waiting list สำหรับบริการจัดการ Graft ได้

Roadmap

  • Graft ยังอยู่ระหว่างการพัฒนา และมีแผนรองรับ WebAssembly, การรวมเข้ากับ SQLSync และการรองรับไลบรารีฝั่งไคลเอนต์ที่หลากหลาย
  • ยังมีแผนเพิ่มฟีเจอร์อย่างการลด write latency, garbage collection, authentication และ authorization, volume forking และการจัดการความขัดแย้ง

เปรียบเทียบกับโซลูชัน SQLite replication อื่น ๆ

  • Graft มีจุดเด่นเฉพาะตัวเมื่อเทียบกับ mvSQLite, Litestream, cr-sqlite, Cloudflare Durable Objects, Cloudflare D1, Turso & libSQL, rqlite & dqlite และ Verneuil
  • จุดแตกต่างสำคัญคือ partial replication, การรองรับโครงสร้างข้อมูลตามต้องการ และ replication ที่มีประสิทธิภาพบน edge

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-04-02
ความคิดเห็นจาก Hacker News

  • ไม่เข้าใจโมเดลความสอดคล้อง

    • ไคลเอนต์ Graft คอมมิตในเครื่องก่อนแล้วจึงพยายามคอมมิตไปยังรีโมตแบบอะซิงโครนัส
    • หากไคลเอนต์สองตัวคอมมิตพร้อมกันโดยอิงจากสแนปช็อตเดียวกัน ตัวหนึ่งจะสำเร็จและอีกตัวจะล้มเหลว
    • API มีให้เพียงการทำงานคอมมิตแบบเดี่ยวเท่านั้น
    • เมื่อการคอมมิตในเครื่องสำเร็จ แต่การเผยแพร่แบบอะซิงโครนัสล้มเหลว จะเกิดปัญหาว่าต้องย้อนกลับหรือไม่
    • แนวคิดของ "คอมมิต" ถูกใช้ปะปนกันหลายความหมาย

  • ผู้สร้าง Graft กล่าวขอบคุณ

    • กำลังเข้าร่วมงาน Antithesis BugBash ที่วอชิงตัน ดี.ซี.
    • อยากพบปะผู้คนที่อยู่ในวอชิงตัน

  • เข้าใจว่าโมเดลความสอดคล้องคล้ายกับ git

    • แก้ไขสำเนาในเครื่องแล้วอาจเกิดความขัดแย้งตอน "push"
    • ไม่มีวิธีตรวจจับความขัดแย้งให้สะอาดชัดเจน
    • ความขัดแย้งอาจเกิดจาก read conflict

  • เมื่อไคลเอนต์ดึง Graft มา ก็จะรู้ได้อย่างแม่นยำว่ามีอะไรเปลี่ยนไปบ้าง

    • เปรียบเทียบกับ manifest ของ Cloud-Backed SQLite
    • ไม่ต้องให้เซิร์ฟเวอร์คำนวณ

  • ไม่ได้กล่าวถึงรายละเอียดการติดตั้งใช้งาน

    • ต้องการเลเยอร์ซิงก์ที่ทำให้นักพัฒนาแอปไม่ต้องกังวลเรื่องการซิงก์
    • สามารถรองรับการซิงก์ส่วนตัวได้โดยไม่ต้องมีค่าสมัครสมาชิก

  • คิดว่าการใช้ VFS เป็น "แฮ็ก" ที่น่าสนุก

    • กำลังพัฒนาเอนจินซิงก์ของตัวเองสำหรับ IDE ที่เน้นออฟไลน์ก่อน
    • การใช้โครงสร้างแบบต้นไม้ทำให้การแก้ conflict เป็นความท้าทาย

  • โปรเจ็กต์ที่ใช้อัลกอริทึม Leap น่าสนใจมาก

    • แม้จะโฟกัสกับการรวมเข้ากับ SQLite ได้ง่าย แต่กลับเข้าหาปัญหาการจัดเก็บแบบกระจายที่ทั่วไปกว่าและอยู่ระดับล่างกว่า
    • โซลูชันทั่วไปที่ไม่มีประสบการณ์เฉพาะด้านอาจมีความเสี่ยง

  • อาจเกิดปัญหาเมื่อไคลเอนต์มือถืออยู่บนการเชื่อมต่อที่ช้า

    • เสนอแนวทางแบบไฮบริดที่ตรวจจับการซิงก์ช้าแล้วส่งคิวรีไปยังเซิร์ฟเวอร์โดยตรง

  • แนวทางที่ใช้เพจเป็นหน่วยพื้นฐานของการซิงก์นั้นน่าสนใจ

    • อาจเกิดความขัดแย้งกับผู้ใช้พร้อมกันจำนวนมาก
    • OT หรือ CRDT อาจดีกว่า

  • เป็นปัญหาที่ท้าทายมาก

    • อยากลองใช้กับแอป React Native