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