Go Media Pipelines แยกการตรวจสอบสถานะและการทำดัชนี
แนวทาง Go Media Pipelines แยกการตรวจสอบสิทธิ์การอัปโหลดและการทำดัชนีภาพออกจากกัน เพื่อป้องกันปัญหาคอขวดและเพิ่มความยืดหยุ่นในการจัดการระบบ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- แยกการตรวจสอบสถานะอัปโหลดและการทำดัชนีภาพออกจากกันอย่างเด็ดขาด
- การตรวจสอบสถานะเป็นกระบวนการซิงโครนัสขนาดเล็กที่ทำงานในขั้นตอนการอัปโหลด
- การทำดัชนีเมตาเดตาทำงานแบบอะซิงโครนัสและสามารถทำซ้ำหรือสร้างใหม่ได้
- การคำนวณความจุต้องพิจารณาอัตราการอัปโหลดและเวลาประมวลผลเพื่อรองรับงาน
การพัฒนาจัดการคลังสื่อดิจิทัลด้วยภาษา Go เสนอแนวทางสำคัญในการแบ่งแยกระหว่างกระบวนการตรวจสอบวงจรชีวิตของไฟล์กับการทำดัชนีเมตาเดตาของรูปภาพออกจากกันอย่างชัดเจน โดยกำหนดให้การตรวจสอบสถานะการอัปโหลดเป็นด่านซิงโครนัสขนาดเล็กที่ทำงานรวดเร็ว ขณะที่การสร้างดัชนีค้นหาถูกย้ายไปทำงานเบื้องหลังแบบอะซิงโครนัส เพื่อไม่ให้กระบวนการค้นหาส่งผลกระทบต่อความเร็วและความเสถียรในขั้นตอนการอัปโหลดไฟล์เข้าสู่ระบบ
เงื่อนไขสำคัญที่สุดในการตัดสินใจคือความสามารถในการย้อนกลับของการทำงาน การตัดสินใจเรื่องวงจรชีวิตไฟล์เป็นตัวควบคุมว่าวัตถุใดสามารถเข้าสู่คลังสื่อที่มีการควบคุมได้หรือไม่ ในขณะที่ดัชนีเมตาเดตาทำหน้าที่เพียงควบคุมวิธีการค้นหาวัตถุดิบเหล่านั้น การรวมกระบวนการทั้งสองเข้าด้วยกันจะทำให้ความพร้อมใช้งานของการค้นหาต้องผูกติดกับข้อกำหนดระดับการให้บริการของการอัปโหลด และทำให้ทุกครั้งที่มีการเปลี่ยนแปลงหมวดหมู่กลายเป็นการแก้ไขประวัติการจัดการที่มีความเสี่ยงสูง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การแยกสถาปัตยกรรมแบบนี้มีความสำคัญมากในระบบคลังข้อมูลขนาดใหญ่ เพราะช่วยให้ทีมพัฒนาสามารถอัปเดตหรือปรับปรุงตรรกะการวิเคราะห์ภาพและแท็กสินค้าได้โดยไม่ต้องเสี่ยงแก้ไขข้อมูลหลักของการอัปโหลด ซึ่งแนวคิดนี้เทียบได้กับการแยก Read Model ออกจาก Write Model ในสถาปัตยกรรม CQRS ที่นิยมใช้ในระบบแบ็คเอนด์สมัยใหม่
บทความนี้ได้จำลองแบบจำลองข้อมูลในภาษา Go ที่แยกความรับผิดชอบอย่างชัดเจน โดยใช้โมเดลอินเทอร์เฟซที่กำหนดขอบเขตการตรวจสอบข้อมูลเบื้องต้น เช่น การจำกัดการตรวจสอบไฟล์ให้อยู่ในขนาดไม่เกิน 512 ไบต์ และรองรับประเภทสื่อรูปภาพที่กำหนดไว้ เพื่อให้มั่นใจว่าการทำงานมีความกระชับและลดภาระของระบบในช่วงที่มีการอัปโหลดเข้ามาจำนวนมากพร้อมกัน
ในด้านการวางแผนความจุและการคำนวณทรัพยากรระบบ หากกำหนดอัตราการอัปโหลดสูงสุดที่ 20 รายการต่อวินาที ระยะเวลาการดึงข้อมูลเฉลี่ย 2 วินาที และเป้าหมายการใช้งาน Worker ที่ 0.70 การคำนวณความหนาแน่นเบื้องต้นจะได้ผลลัพธ์ประมาณ ceil(20 * 2 / 0.70) = 58 เธรดการทำงาน ซึ่งตัวเลขเหล่านี้เป็นเพียงตัวอย่างการคำนวณสำหรับภาระงานที่สมมติขึ้น ผู้ดูแลระบบควรวัดค่าจากปริมาณการใช้งานจริงของตัวเอง
"Start with two records that answer different questions. The lifecycle record says, 'May this object exist here, under this retention and access policy?' The index record says, 'Which searchable attributes can currently be derived from it?'"
Carter Hughes
นอกจากนี้ ระบบยังกำหนดสถานะการทำงานออกเป็น 3 สถานะที่สังเกตได้ชัดเจน ได้แก่ queued, ready และ failed เพื่อให้การจัดการข้อผิดพลาดและการทำซ้ำเป็นไปอย่างมีระบบ การบันทึกที่มาและประวัติของข้อมูล เช่น เวอร์ชันของตัวสกัดข้อมูลและระดับความมั่นใจ จะช่วยให้การตรวจสอบย้อนหลังและการโรลแบ็กระบบสามารถทำได้อย่างแม่นยำโดยไม่ต้องเดา
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น