หน้านี้อธิบายแนวทางปฏิบัติแนะนำเมื่อโหลดข้อมูลแบบเป็นกลุ่มไปยัง Cloud Firestore
ด้วยเครื่องมือต่างๆ เช่น mongoimport
Cloud Firestore เป็นระบบที่มีการกระจายสูงซึ่งมีการปรับขนาดอัตโนมัติ เพื่อตอบสนองความต้องการของธุรกิจ Cloud Firestore แยกและรวมข้อมูลแบบไดนามิก ตามภาระงานที่ระบบได้รับ
การแยกตามภาระงานจะเกิดขึ้นโดยอัตโนมัติโดยไม่ต้องมีการกำหนดค่าล่วงหน้า Cloud Firestoreระบบการแยกตามภาระงานมีลักษณะเฉพาะที่สำคัญบางอย่างเมื่อเทียบกับฐานข้อมูลเอกสารอื่นๆ ซึ่งคุณควรคำนึงถึงขณะสร้างโมเดลข้อมูล
Cloud Firestoreลักษณะการทำงานแบบกระจายอาจต้องมีการเปลี่ยนแปลงตัวเลือกการออกแบบบางอย่าง โดยเฉพาะอย่างยิ่งสำหรับภาระงานที่ได้รับการเพิ่มประสิทธิภาพสำหรับ ฐานข้อมูลที่สำเนาหลักเป็นคอขวดสำหรับปริมาณการเขียน
แนวทางปฏิบัติแนะนำ
เวิร์กโหลดที่ประมวลผลข้อมูลจำนวนมากในไคลเอ็นต์แบบ Single Thread อาจ ทำให้เกิดคอขวดได้ ไคลเอ็นต์อาจใช้การทำงานแบบเธรดเดียวเพื่อโหลดข้อมูลจำนวนมากได้ เนื่องจากปริมาณงานของไคลเอ็นต์และเซิร์ฟเวอร์จะตรงกัน Cloud Firestoreฐานข้อมูลสามารถจัดการการทำงานแบบขนานได้มากขึ้นอย่างมาก แต่ คุณต้องกำหนดค่าไคลเอ็นต์ให้ส่งคำขอแบบขนาน
mongoimport
เมื่อใช้เครื่องมือ mongoimport ระบบจะส่งคำขอตามลำดับโดยค่าเริ่มต้น
หากต้องการปรับปรุงเวลาในการโหลดใน Cloud Firestore
ให้ตั้งค่าจำนวนผู้ปฏิบัติงานด้วยแฟล็ก --numInsertionWorkers
การตั้งค่าที่ถูกต้องอาจต้องมีการปรับตามขนาดของไคลเอ็นต์ แต่โดยทั่วไปเราขอแนะนำให้เริ่มต้นด้วยอย่างน้อย 32
การเขียนโปรแกรมแบบไม่พร้อมกัน
เมื่อพัฒนาซอฟต์แวร์ของคุณเองโดยใช้ API ที่เข้ากันได้กับ MongoDB คุณจะปรับปรุง การทำงานแบบคู่ขนานได้ด้วยวิธีต่อไปนี้
- เฟรมเวิร์กแบบอะซิงโครนัส: การใช้เฟรมเวิร์กแบบอะซิงโครนัสช่วยให้คุณประมวลผลและตอบกลับคำขอได้แบบคู่ขนาน คุณไม่จำเป็นต้อง พัฒนาการจัดกลุ่มหรือการจัดคิวที่ซับซ้อนเมื่อทำการเรียกไปยังฐานข้อมูล โฟลว์คำขอแต่ละรายการสามารถใช้การเชื่อมต่ออิสระและทำการเรียกฐานข้อมูลแบบขนานได้
- ใช้ข้อเสนอการประมวลผลแบบขนาน: การใช้บริการต่างๆ เช่น Cloud Run ระบบจะปรับขนาดจำนวนผู้ปฏิบัติงานด้านการคำนวณที่จำเป็นต่อการประมวลผลข้อมูลได้
การทำงานล้มเหลวชั่วคราว
เมื่อทำงานกับระบบแบบกระจายขนาดใหญ่ เช่น Cloud Firestore คุณอาจพบ ความล้มเหลวชั่วคราว เช่น เครือข่ายขัดข้องหรือการแย่งกันเข้าถึง เอกสาร
เมื่อโหลดข้อมูลจำนวนมากแบบเป็นกลุ่ม คุณควร รักษากลยุทธ์การลองใหม่สำหรับการเขียนที่ไม่สำเร็จโดยไม่ทำให้การดำเนินการโหลดแบบเป็นกลุ่มขนาดใหญ่ล้มเหลว