DBOS เผชิญความสงสัยจากนักพัฒนาเกี่ยวกับการอ้าง "Exactly-Once" Processing และข้อกำหนด Idempotency

ทีมชุมชน BigGo
DBOS เผชิญความสงสัยจากนักพัฒนาเกี่ยวกับการอ้าง "Exactly-Once" Processing และข้อกำหนด Idempotency

DBOS Transact ระบบจัดการเวิร์กโฟลว์แบบใหม่ที่สร้างบน PostgreSQL กำลังสร้างการถกเถียงในชุมชนนักพัฒนาเกี่ยวกับการอ้างทางเทคนิคและความท้าทายในการนำไปใช้งานจริง แม้ว่าระบบนี้จะสัญญาว่าจะลดความซับซ้อนของการจัดการเวิร์กโฟลว์ที่ทนทานผ่านการสร้างจุดตรวจสอบที่รองรับด้วยฐานข้อมูล แต่นักพัฒนากำลังตั้งคำถามสำคัญเกี่ยวกับการรับประกันหลักและความซับซ้อนในการดำเนินงาน

การรองรับภาษาของ DBOS:

  • ภาษาที่รองรับในปัจจุบัน: Go, Python, TypeScript
  • ภาษาที่วางแผนไว้: Java
  • สถาปัตยกรรม: การผสานรวมแบบไลบรารี (เทียบกับคลัสเตอร์ภายนอก)
  • ฐานข้อมูล: การสร้างจุดตรวจสอบที่รองรับด้วย PostgreSQL

การตั้งคำถามเกี่ยวกับการอ้าง Exactly-Once Processing

การถกเถียงทางเทคนิคที่สำคัญที่สุดมุ่งเน้นไปที่การอ้างของ DBOS เกี่ยวกับการประมวลผลเหตุการณ์แบบ exactly-once สมาชิกในชุมชนได้ชี้ให้เห็นความท้าทายพื้นฐานในระบบกระจาย: ความเป็นไปไม่ได้ที่จะรับประกันการดำเนินการแบบ exactly-once อย่างแท้จริงโดยไม่มีการพิจารณาการออกแบบอย่างรอบคอบ ปัญหาหลักอยู่ที่เวลาที่การดำเนินการถูกทำเครื่องหมายว่าเสร็จสิ้นเมื่อเทียบกับเวลาที่การดำเนินการนั้นเสร็จสิ้นจริง ๆ

นี่ฟังดู...เป็นไปไม่ได้? หากคุณมีขั้นตอนใดขั้นตอนหนึ่งในเวิร์กโฟลว์ของคุณ คุณจะบันทึกว่าเสร็จสิ้นเมื่อเริ่มต้น แต่แล้วคุณสามารถขัดข้องได้ครึ่งทาง และเมื่อคุณกู้คืนเวิร์กโฟลว์ ตอนนี้มันไม่ได้ถูกประมวลผล หรือบันทึกว่าเสร็จสิ้นหลังจากที่คุณทำเสร็จแล้ว แต่แล้วคุณสามารถขัดข้องระหว่างการเสร็จสิ้นและการบันทึก และเมื่อคุณกู้คืน คุณจะรันขั้นตอนนั้นสองครั้ง

นักพัฒนา DBOS ได้ชี้แจงว่าการอ้าง exactly-once ของพวกเขาใช้กับการเริ่มต้นเวิร์กโฟลว์โดยเฉพาะในการตอบสนองต่อเหตุการณ์ ไม่ใช่การดำเนินการของขั้นตอนแต่ละขั้นตอน พวกเขายอมรับว่าขั้นตอนแต่ละขั้นตอนอาจต้องเริ่มต้นใหม่หากขัดข้องระหว่างการดำเนินการ ซึ่งต้องการให้นักพัฒนาใช้การดำเนินการแบบ idempotent

การดำเนินการแบบ Idempotent: ฟังก์ชันที่สามารถเรียกได้หลายครั้งด้วยผลลัพธ์เดียวกัน เพื่อให้มั่นใจในความสอดคล้องของระบบแม้จะถูกดำเนินการซ้ำ ๆ

ข้อจำกัดทางเทคนิคที่สำคัญ:

  • ขั้นตอนการทำงานแต่ละขั้นต้องได้รับการออกแบบให้เป็น idempotent
  • การประมวลผล "exactly-once" ใช้ได้เฉพาะกับการเริ่มต้น workflow เท่านั้น ไม่ใช่การดำเนินการของขั้นตอน
  • ขั้นตอนต่างๆ อาจเริ่มต้นใหม่หากเกิดข้อผิดพลาดระหว่างการดำเนินการ
  • ความรับผิดชอบของนักพัฒนาในการใช้งาน fault-tolerant step ยังคงอยู่

ความรับผิดชอบของนักพัฒนาต่อความทนทานต่อข้อผิดพลาด

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

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

ข้อได้เปรียบของโมเดลการดำเนินงาน

แม้จะมีความกังวลทางเทคนิค แต่ DBOS ก็ให้ประโยชน์ด้านการดำเนินงานที่น่าสังเกตเมื่อเปรียบเทียบกับระบบที่มีอยู่แล้วเช่น Temporal หรือ Airflow ระบบนี้ทำงานเป็นไลบรารีที่รวมเข้ากับแอปพลิเคชันที่มีอยู่โดยตรง แทนที่จะต้องการโครงสร้างคลัสเตอร์แยกต่างหาก วิธีการนี้ลดความซับซ้อนในการปรับใช้และค่าใช้จ่ายในการดำเนินงานสำหรับทีมพัฒนาอย่างมาก

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

ตำแหน่งในตลาดและคำถามเกี่ยวกับการเติบโต

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

ระบบนี้ปัจจุบันรองรับ Go, Python และ TypeScript โดยมีแผนรองรับ Java วิธีการหลายภาษานี้แสดงให้เห็นความทะเยอทะยานเกินกว่าการนำไปใช้เฉพาะกลุ่ม แม้ว่าการตอบรับจากตลาดในท้ายที่สุดยังคงต้องกำหนด

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

อ้างอิง: DBOS Transact: Lightweight Durable Workflow Orchestration with Postgres