อ่านเอกสารนี้เพื่อดูคำแนะนำเกี่ยวกับการปรับขนาดแอปแบบไร้เซิร์ฟเวอร์ให้รองรับการดำเนินการมากกว่าหลายพันรายการต่อวินาทีหรือผู้ใช้พร้อมกันหลายแสนราย เอกสารนี้มีหัวข้อขั้นสูงที่จะช่วยให้คุณเข้าใจระบบอย่างละเอียด หากเพิ่งเริ่มต้นใช้งาน Cloud Firestore โปรดดูคู่มือเริ่มใช้งานฉบับย่อแทน
Cloud Firestore และ Firebase SDK สำหรับอุปกรณ์เคลื่อนที่/เว็บมีโมเดลที่มีประสิทธิภาพสำหรับการพัฒนาแอปแบบไร้เซิร์ฟเวอร์ ซึ่งโค้ดฝั่งไคลเอ็นต์จะเข้าถึงฐานข้อมูลโดยตรง SDK ช่วยให้ไคลเอ็นต์รับฟังข้อมูลอัปเดตแบบเรียลไทม์ได้ คุณสามารถใช้ข้อมูลอัปเดตแบบเรียลไทม์เพื่อสร้างแอปที่ตอบสนองได้ดีโดยไม่จำเป็นต้องมีโครงสร้างพื้นฐานของเซิร์ฟเวอร์ แม้ว่าการเริ่มต้นใช้งานจะทำได้ง่ายมาก แต่การทำความเข้าใจข้อจำกัดในระบบที่ประกอบขึ้นเป็น Cloud Firestore จะช่วยให้แอปแบบ Serverless ปรับขนาดและทำงานได้ดีเมื่อมีการรับส่งข้อมูลเพิ่มขึ้น
ดูคำแนะนำในการปรับขนาดแอปในส่วนต่อไปนี้
เลือกตำแหน่งฐานข้อมูลที่อยู่ใกล้กับผู้ใช้
แผนภาพต่อไปนี้แสดงสถาปัตยกรรมของแอปแบบเรียลไทม์
เมื่อแอปที่ทำงานบนอุปกรณ์ของผู้ใช้ (อุปกรณ์เคลื่อนที่หรือเว็บ) สร้างการเชื่อมต่อกับ Cloud Firestore ระบบจะกำหนดเส้นทางการเชื่อมต่อไปยังเซิร์ฟเวอร์ส่วนหน้าของ Cloud Firestore ในภูมิภาคเดียวกับที่ฐานข้อมูลของคุณอยู่ เช่น
หากฐานข้อมูลอยู่ใน us-east1 การเชื่อมต่อก็จะไปยัง
Cloud Firestore ส่วนหน้าใน us-east1 ด้วย การเชื่อมต่อเหล่านี้มีอายุการใช้งานยาวนานและจะเปิดอยู่จนกว่าแอปจะปิดอย่างชัดเจน ส่วนหน้าจะอ่านข้อมูลจากระบบพื้นที่เก็บข้อมูลCloud Firestoreที่เกี่ยวข้อง
ระยะห่างระหว่างตำแหน่งทางกายภาพของผู้ใช้กับตำแหน่งฐานข้อมูลจะส่งผลต่อเวลาในการตอบสนองที่ผู้ใช้ได้รับCloud Firestore เช่น ผู้ใช้ในอินเดียที่แอปพูดคุยกับฐานข้อมูลในภูมิภาค Google Cloud ในอเมริกาเหนืออาจพบว่าประสบการณ์การใช้งานช้าลงและแอปตอบสนองช้ากว่ากรณีที่ฐานข้อมูลอยู่ใกล้กว่า เช่น ในอินเดียหรือในส่วนอื่นๆ ของเอเชีย
ออกแบบเพื่อความน่าเชื่อถือ
หัวข้อต่อไปนี้จะปรับปรุงหรือส่งผลต่อความน่าเชื่อถือของแอป
เปิดใช้โหมดออฟไลน์
Firebase SDK มีฟีเจอร์การคงอยู่ของข้อมูลแบบออฟไลน์ หาก แอปในอุปกรณ์ของผู้ใช้เชื่อมต่อกับ Cloud Firestore ไม่ได้ ผู้ใช้จะยังคงใช้แอปได้โดยการทำงานกับข้อมูลที่แคชไว้ในเครื่อง ซึ่งจะช่วยให้เข้าถึงข้อมูลได้แม้ว่าผู้ใช้จะพบปัญหาการเชื่อมต่ออินเทอร์เน็ตไม่เสถียรหรือสูญเสียการเข้าถึงโดยสมบูรณ์เป็นเวลาหลายชั่วโมงหรือหลายวัน ดูรายละเอียดเพิ่มเติมเกี่ยวกับ โหมดออฟไลน์ได้ที่หัวข้อเปิดใช้ข้อมูลออฟไลน์
ทำความเข้าใจการลองใหม่โดยอัตโนมัติ
Firebase SDK จะจัดการการลองใหม่ของการดำเนินการและการสร้างการเชื่อมต่อที่ขาดหายไปอีกครั้ง ซึ่งจะช่วยหลีกเลี่ยงข้อผิดพลาดชั่วคราวที่เกิดจากการรีสตาร์ทเซิร์ฟเวอร์หรือปัญหาเครือข่ายระหว่างไคลเอ็นต์กับฐานข้อมูล
เลือกระหว่างตำแหน่งระดับภูมิภาคและหลายภูมิภาค
การเลือกระหว่างตำแหน่งระดับภูมิภาคและหลายภูมิภาคมีข้อดีข้อเสียที่ต้องพิจารณา ความแตกต่างหลักคือวิธีการจำลองข้อมูล ซึ่งจะกำหนดการรับประกันความพร้อมใช้งานของแอป อินสแตนซ์หลายภูมิภาคให้ความน่าเชื่อถือในการให้บริการที่สูงขึ้นและเพิ่มความทนทานของข้อมูล แต่ข้อเสียคือค่าใช้จ่าย
ทำความเข้าใจระบบการค้นหาแบบเรียลไทม์
การค้นหาแบบเรียลไทม์หรือที่เรียกว่า Listener ของสแนปชอตช่วยให้แอปรับฟังการเปลี่ยนแปลงในฐานข้อมูลและรับการแจ้งเตือนที่มีเวลาในการตอบสนองต่ำทันทีที่ข้อมูลมีการเปลี่ยนแปลง แอปสามารถรับผลลัพธ์เดียวกันได้โดยการโพลฐานข้อมูลเป็นระยะๆ เพื่อดูข้อมูลอัปเดต แต่การดำเนินการนี้มักจะช้ากว่า มีค่าใช้จ่ายสูงกว่า และต้องใช้โค้ดมากขึ้น ดูตัวอย่างวิธีตั้งค่าและใช้การค้นหาแบบเรียลไทม์ได้ที่หัวข้อ รับข้อมูลอัปเดตแบบเรียลไทม์ ส่วนต่อไปนี้จะอธิบายรายละเอียดเกี่ยวกับวิธีการทำงานของ Listener ของสแนปชอตและอธิบายแนวทางปฏิบัติแนะนำบางส่วนสำหรับการปรับขนาดการค้นหาแบบเรียลไทม์พร้อมทั้งรักษาประสิทธิภาพไว้
ลองนึกภาพผู้ใช้ 2 รายที่เชื่อมต่อกับ Cloud Firestore ผ่านแอปส่งข้อความ ที่สร้างขึ้นด้วย SDK สำหรับอุปกรณ์เคลื่อนที่แบบใดแบบหนึ่ง
ไคลเอ็นต์ ก เขียนลงในฐานข้อมูลเพื่อเพิ่มและอัปเดตเอกสารในคอลเล็กชันที่ชื่อว่า chatroom
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
ไคลเอ็นต์ ข รับฟังข้อมูลอัปเดตในคอลเล็กชันเดียวกันโดยใช้ Listener ของสแนปชอต ไคลเอ็นต์ ข จะได้รับการแจ้งเตือนทันทีเมื่อมีคนสร้างข้อความใหม่ แผนภาพต่อไปนี้แสดงสถาปัตยกรรมเบื้องหลัง Listener ของสแนปชอต
ลำดับเหตุการณ์ต่อไปนี้จะเกิดขึ้นเมื่อไคลเอ็นต์ ข เชื่อมต่อ Listener ของสแนปชอตกับฐานข้อมูล
- ไคลเอ็นต์ ข เปิดการเชื่อมต่อกับ Cloud Firestore และลงทะเบียน
Listener โดยการเรียก
onSnapshot(collection("chatroom"))ผ่าน Firebase SDK Listener นี้สามารถใช้งานได้นานหลายชั่วโมง - ส่วนหน้าของ Cloud Firestore จะค้นหาระบบพื้นที่เก็บข้อมูลที่เกี่ยวข้อง เพื่อเริ่มต้นชุดข้อมูล โดยจะโหลดชุดผลลัพธ์ทั้งหมดของเอกสารที่ตรงกัน เราเรียกการดำเนินการนี้ว่าการค้นหาแบบโพล จากนั้นระบบจะ ประเมินกฎความปลอดภัยสำหรับฐานข้อมูลเรียลไครม์ของ Firebase เพื่อ ตรวจสอบว่าผู้ใช้เข้าถึงข้อมูลนี้ได้ หากผู้ใช้ได้รับอนุญาต ฐานข้อมูลจะส่งคืนข้อมูลไปยังผู้ใช้
- จากนั้นการค้นหาของไคลเอ็นต์ ข จะเข้าสู่โหมดรับฟัง Listener จะลงทะเบียนกับตัวจัดการการสมัครใช้บริการและรอข้อมูลอัปเดต
- ตอนนี้ไคลเอ็นต์ ก ส่งการดำเนินการเขียนเพื่อแก้ไขเอกสาร
- ฐานข้อมูลจะคอมมิตการเปลี่ยนแปลงเอกสารลงในระบบพื้นที่เก็บข้อมูล
- ระบบจะคอมมิตข้อมูลอัปเดตเดียวกันลงในบันทึกการเปลี่ยนแปลงภายในแบบทรานแซกชัน บันทึกการเปลี่ยนแปลงจะกำหนดลำดับการเปลี่ยนแปลงที่เกิดขึ้นอย่างเข้มงวด
- จากนั้นบันทึกการเปลี่ยนแปลงจะกระจายข้อมูลที่อัปเดตไปยังพูลของตัวจัดการการสมัครใช้บริการ
- ตัวจับคู่การค้นหาแบบย้อนกลับ จะทำงานเพื่อดูว่าเอกสารที่อัปเดตตรงกับ Listener ของสแนปชอตที่ลงทะเบียนไว้ในปัจจุบันหรือไม่ ในตัวอย่างนี้ เอกสารตรงกับ Listener ของสแนปชอตของไคลเอ็นต์ ข ตามชื่อที่ระบุไว้ คุณสามารถคิดว่าตัวจับคู่การค้นหาแบบย้อนกลับเป็นการค้นหาฐานข้อมูลปกติแต่ทำแบบย้อนกลับ แทนที่จะค้นหาเอกสารเพื่อหาเอกสารที่ตรงกับการค้นหา ตัวจับคู่จะค้นหาการค้นหาอย่างมีประสิทธิภาพเพื่อหาการค้นหาที่ตรงกับเอกสารขาเข้า เมื่อพบรายการที่ตรงกัน ระบบจะส่งต่อเอกสารที่เป็นปัญหาไปยัง Listener ของสแนปชอต จากนั้นระบบจะประเมินกฎความปลอดภัยสำหรับฐานข้อมูลเรียลไทม์ของ Firebase เพื่อให้แน่ใจว่ามีเพียงผู้ใช้ที่ได้รับอนุญาตเท่านั้นที่จะได้รับข้อมูล
- ระบบจะส่งต่อข้อมูลอัปเดตเอกสารไปยัง SDK ในอุปกรณ์ของไคลเอ็นต์ ข และเรียกใช้ฟังก์ชันเรียกกลับ
onSnapshotหากเปิดใช้การคงอยู่ของข้อมูลในเครื่อง SDK จะใช้ข้อมูลอัปเดตกับแคชในเครื่องด้วย
ส่วนสำคัญของ Cloud Firestore's ขึ้นอยู่กับแฟนเอาต์ (Fan-Out) จากบันทึกการเปลี่ยนแปลงไปยังตัวจัดการการสมัครใช้บริการและเซิร์ฟเวอร์ส่วนหน้า แฟนเอาต์ (Fan-Out) ช่วยให้การเปลี่ยนแปลงข้อมูลรายการเดียวเผยแพร่ได้อย่างมีประสิทธิภาพเพื่อให้บริการการค้นหาแบบเรียลไทม์และผู้ใช้ที่เชื่อมต่อหลายล้านราย Cloud Firestore มีความพร้อมใช้งานสูงและความสามารถในการปรับขนาดสูงโดยการเรียกใช้สำเนาจำนวนมากของคอมโพเนนต์ทั้งหมดเหล่านี้ ในหลายโซน (หรือหลายภูมิภาคในกรณีของการทำให้ใช้งานได้หลายภูมิภาค )
โปรดทราบว่าการดำเนินการอ่านทั้งหมดที่ออกโดย SDK สำหรับอุปกรณ์เคลื่อนที่และเว็บเป็นไปตามโมเดลข้างต้น โดยจะทำการค้นหาแบบโพลตามด้วยโหมดรับฟังเพื่อรักษาการรับประกันความสอดคล้อง ซึ่งจะมีผลกับ Listener แบบเรียลไทม์ การเรียกเพื่อดึงข้อมูลเอกสาร และ การค้นหาแบบครั้งเดียวด้วย คุณสามารถคิดว่าการดึงข้อมูลเอกสารเดียวและการค้นหาแบบครั้งเดียวเป็น Listener ของสแนปชอตที่มีอายุการใช้งานสั้นซึ่งมีข้อจำกัดที่คล้ายกันเกี่ยวกับประสิทธิภาพ
ใช้แนวทางปฏิบัติแนะนำสำหรับการปรับขนาดการค้นหาแบบเรียลไทม์
ใช้แนวทางปฏิบัติแนะนำต่อไปนี้เพื่อออกแบบการค้นหาแบบเรียลไทม์ที่ปรับขนาดได้
ทำความเข้าใจการเข้าชมการเขียนสูงในระบบ
ส่วนนี้จะช่วยให้คุณเข้าใจวิธีที่ระบบตอบสนองต่อคำขอเขียนที่เพิ่มขึ้น
บันทึกการเปลี่ยนแปลงของ Cloud Firestore ที่ขับเคลื่อนการค้นหาแบบเรียลไทม์ จะปรับขนาดในแนวนอนโดยอัตโนมัติเมื่อการเข้าชมการเขียนเพิ่มขึ้น เมื่ออัตราการเขียนสำหรับฐานข้อมูลเพิ่มขึ้นเกินกว่าที่เซิร์ฟเวอร์เดียวจะจัดการได้ ระบบจะแยกบันทึกการเปลี่ยนแปลงออกเป็นหลายเซิร์ฟเวอร์ และการประมวลผลการค้นหาจะเริ่มใช้ข้อมูลจากตัวจัดการการสมัครใช้บริการหลายรายการแทนที่จะใช้เพียงรายการเดียว จากมุมมองของไคลเอ็นต์และ SDK การดำเนินการทั้งหมดนี้จะโปร่งใสและแอปไม่จำเป็นต้องดำเนินการใดๆ เมื่อมีการแยก แผนภาพต่อไปนี้แสดงวิธีที่การค้นหาแบบเรียลไทม์ปรับขนาด
การปรับขนาดอัตโนมัติช่วยให้คุณเพิ่มการเข้าชมการเขียนได้โดยไม่มีข้อจำกัด แต่เมื่อการเข้าชมเพิ่มขึ้น ระบบอาจใช้เวลาสักครู่ในการตอบสนอง ทำตามคำแนะนำของกฎ 5-5-5 เพื่อหลีกเลี่ยงการสร้างฮอตสปอตการเขียน Key Visualizer เป็น เครื่องมือที่มีประโยชน์สำหรับการวิเคราะห์ฮอตสปอตการเขียน
แอปจำนวนมากมีการเติบโตแบบออร์แกนิกที่คาดการณ์ได้ ซึ่ง Cloud Firestore สามารถ รองรับได้โดยไม่ต้องมีข้อควรระวัง อย่างไรก็ตาม เวิร์กโหลดแบบเป็นชุด เช่น การนำเข้าชุดข้อมูลขนาดใหญ่ อาจทำให้การเขียนเพิ่มขึ้นเร็วเกินไป เมื่อออกแบบแอป ให้ตระหนักถึงแหล่งที่มาของการเข้าชมการเขียน
ทำความเข้าใจวิธีที่การเขียนและการอ่านโต้ตอบกัน
คุณสามารถคิดว่าระบบการค้นหาแบบเรียลไทม์เป็นไปป์ไลน์ที่เชื่อมต่อการดำเนินการเขียนกับผู้อ่าน เมื่อมีการสร้าง อัปเดต หรือลบเอกสาร การเปลี่ยนแปลงจะเผยแพร่จากระบบพื้นที่เก็บข้อมูลไปยัง Listener ที่ลงทะเบียนไว้ในปัจจุบัน Cloud Firestoreโครงสร้างบันทึกการเปลี่ยนแปลงของ รับประกันความสอดคล้องที่แข็งแกร่ง ซึ่งหมายความว่าแอปของคุณจะไม่ได้รับการแจ้งเตือนข้อมูลอัปเดตที่เรียงลำดับไม่ถูกต้องเมื่อเทียบกับเวลาที่ฐานข้อมูลคอมมิตการเปลี่ยนแปลงข้อมูล ซึ่งจะช่วยลดความซับซ้อนในการพัฒนาแอปโดยการนำกรณีขอบออกไปเกี่ยวกับความสอดคล้องของข้อมูล
ไปป์ไลน์ที่เชื่อมต่อนี้หมายความว่าการดำเนินการเขียนที่ทำให้เกิดฮอตสปอตหรือการแย่งชิงล็อกอาจส่งผลเสียต่อการดำเนินการอ่าน เมื่อการดำเนินการเขียนล้มเหลวหรือมีการควบคุมปริมาณ การอ่านอาจหยุดชะงักเพื่อรอข้อมูลที่สอดคล้องกันจากบันทึกการเปลี่ยนแปลง หากเกิดเหตุการณ์นี้ในแอป คุณอาจเห็นทั้งการดำเนินการเขียนที่ช้าและเวลาในการตอบสนองที่ช้าที่สัมพันธ์กันสำหรับการค้นหา การหลีกเลี่ยงฮอตสปอตเป็นวิธีสำคัญในการหลีกเลี่ยงปัญหานี้
เก็บเอกสารและการดำเนินการเขียนให้มีขนาดเล็ก
เมื่อสร้างแอปด้วย Listener ของสแนปชอต คุณมักจะต้องการให้ผู้ใช้ทราบเกี่ยวกับการเปลี่ยนแปลงข้อมูลอย่างรวดเร็ว เพื่อให้บรรลุเป้าหมายนี้ ให้พยายามเก็บข้อมูลให้มีขนาดเล็ก ระบบสามารถส่งเอกสารขนาดเล็กที่มีฟิลด์หลายสิบรายการผ่านระบบได้อย่างรวดเร็ว เอกสารขนาดใหญ่ที่มีฟิลด์หลายร้อยรายการและข้อมูลขนาดใหญ่จะใช้เวลาในการประมวลผลนานกว่า
เช่นเดียวกัน ให้เลือกใช้การดำเนินการคอมมิตและการเขียนที่สั้นและรวดเร็วเพื่อรักษาเวลาในการตอบสนองให้ต่ำ ชุดข้อมูลขนาดใหญ่อาจทำให้ได้อัตราการส่งข้อมูลที่สูงขึ้นจากมุมมองของผู้เขียน แต่จริงๆ แล้วอาจเพิ่มเวลาในการแจ้งเตือนสำหรับ Listener ของสแนปชอต ซึ่งมักจะขัดกับสัญชาตญาณเมื่อเทียบกับการใช้ระบบฐานข้อมูลอื่นๆ ที่คุณอาจใช้การจัดกลุ่มเพื่อปรับปรุงประสิทธิภาพ
ใช้ Listener ที่มีประสิทธิภาพ
เมื่ออัตราการเขียนสำหรับฐานข้อมูลเพิ่มขึ้น Cloud Firestore จะแยกการประมวลผลข้อมูลออกเป็นหลายเซิร์ฟเวอร์ อัลกอริทึมการแบ่งส่วนของ Cloud Firestore พยายามจัดวางข้อมูลจาก คอลเล็กชันหรือกลุ่มคอลเล็กชันเดียวกันไว้ในเซิร์ฟเวอร์บันทึกการเปลี่ยนแปลงเดียวกัน ระบบพยายามเพิ่มปริมาณงานการเขียนที่เป็นไปได้ให้สูงสุดพร้อมทั้งลดจำนวนเซิร์ฟเวอร์ที่เกี่ยวข้องกับการประมวลผลการค้นหาให้เหลือน้อยที่สุด
อย่างไรก็ตาม รูปแบบบางอย่างอาจยังคงทำให้เกิดลักษณะการทำงานที่ไม่เหมาะสมสำหรับ Listener ของสแนปชอต เช่น หากแอปจัดเก็บข้อมูลส่วนใหญ่ไว้ในคอลเล็กชันขนาดใหญ่ Listener อาจต้องเชื่อมต่อกับเซิร์ฟเวอร์หลายเครื่องเพื่อรับข้อมูลทั้งหมดที่ต้องการ ซึ่งยังคงเป็นจริงแม้ว่าคุณจะใช้ตัวกรองการค้นหาก็ตาม การเชื่อมต่อกับเซิร์ฟเวอร์หลายเครื่องจะเพิ่มความเสี่ยงที่การตอบสนองจะช้าลง
ออกแบบสคีมาและแอปเพื่อให้ระบบให้บริการ Listener ได้โดยไม่ต้องไปที่เซิร์ฟเวอร์ต่างๆ มากมายเพื่อหลีกเลี่ยงการตอบสนองที่ช้าลง การแบ่งข้อมูลออกเป็นคอลเล็กชันขนาดเล็กลงที่มีอัตราการเขียนต่ำลงอาจเป็นวิธีที่ดีที่สุด
ซึ่งคล้ายกับการคิดถึงการค้นหาประสิทธิภาพในฐานข้อมูลเชิงสัมพันธ์ที่ต้องมีการสแกนตารางทั้งหมด ในฐานข้อมูลเชิงสัมพันธ์ การค้นหาที่ต้องมีการสแกนตารางทั้งหมดเทียบเท่ากับ Listener ของสแนปชอตที่ดูคอลเล็กชันที่มีการเปลี่ยนแปลงสูง การค้นหาอาจทำงานช้าเมื่อเทียบกับการค้นหาที่ฐานข้อมูลสามารถให้บริการได้โดยใช้ดัชนีที่เฉพาะเจาะจงมากขึ้น การค้นหาที่มีดัชนีที่เฉพาะเจาะจงมากขึ้นจะเหมือนกับ Listener ของสแนปชอตที่ดูเอกสารเดียวหรือคอลเล็กชันที่มีการเปลี่ยนแปลงน้อยลง คุณควรทดสอบการโหลดแอปเพื่อทำความเข้าใจลักษณะการทำงานและความต้องการของ Use Case ได้ดีที่สุด
รักษาการค้นหาแบบโพลให้รวดเร็ว
ส่วนสำคัญอีกส่วนหนึ่งของการค้นหาแบบเรียลไทม์ที่ตอบสนองได้ดีคือการตรวจสอบว่าการค้นหาแบบโพลเพื่อเริ่มต้นข้อมูลนั้นรวดเร็วและมีประสิทธิภาพ เมื่อ Listener ของสแนปชอตใหม่เชื่อมต่อเป็นครั้งแรก Listener จะต้องโหลดชุดผลลัพธ์ทั้งหมดและส่งไปยังอุปกรณ์ของผู้ใช้ การค้นหาที่ช้าจะทำให้แอปตอบสนองได้ช้าลง ซึ่งรวมถึงการค้นหาที่พยายามอ่านเอกสารจำนวนมากหรือการค้นหาที่ไม่ได้ใช้ดัชนีที่เหมาะสม
Listener อาจย้ายกลับจากสถานะรับฟังไปยังสถานะโพลในบางสถานการณ์ การดำเนินการนี้จะเกิดขึ้นโดยอัตโนมัติและ SDK และแอปของคุณจะมองเห็นได้ชัดเจน เงื่อนไขต่อไปนี้อาจทำให้เกิดสถานะโพล
- ระบบจะปรับสมดุลบันทึกการเปลี่ยนแปลงอีกครั้งเนื่องจากการเปลี่ยนแปลงโหลด
- ฮอตสปอตทำให้การเขียนลงในฐานข้อมูลล้มเหลวหรือล่าช้า
- การรีสตาร์ทเซิร์ฟเวอร์ชั่วคราวส่งผลต่อ Listener ชั่วคราว
หากการค้นหาแบบโพลเร็วพอ ผู้ใช้แอปจะมองไม่เห็นสถานะโพล
เลือกใช้ Listener ที่มีอายุการใช้งานยาวนาน
การเปิดและรักษา Listener ให้ใช้งานได้นานที่สุดมักจะเป็นวิธีที่มีประสิทธิภาพสูงสุดในการสร้างแอปที่ใช้ Cloud Firestore เมื่อใช้ Cloud Firestore ระบบจะเรียกเก็บเงินจากคุณสำหรับเอกสารที่ส่งคืนไปยังแอป และไม่ใช่สำหรับการรักษาการเชื่อมต่อที่เปิดอยู่ Listener ของสแนปชอตที่มีอายุการใช้งานยาวนานจะอ่านเฉพาะข้อมูลที่จำเป็นในการให้บริการการค้นหาตลอดอายุการใช้งาน ซึ่งรวมถึงการดำเนินการโพลเริ่มต้นตามด้วยการแจ้งเตือนเมื่อข้อมูลมีการเปลี่ยนแปลงจริง ในทางกลับกัน การค้นหาแบบครั้งเดียวจะอ่านข้อมูลซ้ำซึ่งอาจไม่มีการเปลี่ยนแปลงนับตั้งแต่แอปดำเนินการค้นหาครั้งล่าสุด
ในกรณีที่แอปต้องใช้ข้อมูลในอัตราสูง Listener ของสแนปชอตอาจไม่เหมาะสม เช่น หาก Use Case ของคุณส่งเอกสารจำนวนมากต่อวินาทีผ่านการเชื่อมต่อเป็นระยะเวลานาน การเลือกใช้การค้นหาแบบครั้งเดียวที่ทำงานด้วยความถี่ต่ำกว่าอาจเป็นทางเลือกที่ดีกว่า
ต้องทำอะไรต่อไป
- ดูวิธีใช้ Listener ของสแนปชอต
- อ่านข้อมูลเพิ่มเติมเกี่ยวกับแนวทางปฏิบัติแนะนำ