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