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