ทำความเข้าใจการค้นหาแบบเรียลไทม์ในวงกว้าง

อ่านเอกสารนี้เพื่อดูคําแนะนําในการปรับขนาดแอปแบบเซิร์ฟเวอร์เลสให้รองรับการดำเนินการหลายพันรายการต่อวินาทีหรือผู้ใช้หลายแสนคนพร้อมกัน เอกสารนี้มีหัวข้อขั้นสูงเพื่อช่วยให้คุณเข้าใจระบบอย่างละเอียด หากคุณเพิ่งเริ่มใช้ Cloud Firestore โปรดดูคู่มือเริ่มใช้งานฉบับย่อแทน

Cloud Firestore และ Firebase Mobile/Web 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 ของสแนปชอต ให้แอปฟังการเปลี่ยนแปลงในฐานข้อมูลและรับการแจ้งเตือนที่มีเวลาในการตอบสนองต่ำทันทีที่มีการเปลี่ยนแปลงข้อมูล แอปสามารถรับผลลัพธ์เดียวกันได้โดยการสำรวจฐานข้อมูลเป็นระยะๆ เพื่อหาการอัปเดต แต่มักจะช้ากว่า ราคาแพงกว่า และต้องใช้โค้ดมากกว่า ดูตัวอย่างวิธีตั้งค่าและใช้การค้นหาแบบเรียลไทม์ได้ที่รับข้อมูลอัปเดตแบบเรียลไทม์ ส่วนต่อไปนี้จะอธิบายรายละเอียดเกี่ยวกับวิธีการทำงานของเครื่องมือรับฟังภาพรวมและอธิบายแนวทางปฏิบัติแนะนำบางส่วนสำหรับการปรับขนาดการค้นหาแบบเรียลไทม์โดยยังคงรักษาประสิทธิภาพไว้

สมมติว่าผู้ใช้ 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 ของสแนปชอต

ลำดับเหตุการณ์ต่อไปนี้จะเกิดขึ้นเมื่อไคลเอ็นต์ ข. เชื่อมต่อโปรแกรมรับฟังสแนปชอตกับฐานข้อมูล

  1. ไคลเอ็นต์ ข เปิดการเชื่อมต่อกับ Cloud Firestore และลงทะเบียนโปรแกรมรับฟังโดยเรียกใช้ onSnapshot(collection("chatroom")) ผ่าน Firebase SDK ผู้ฟังรายนี้สามารถใช้งานอยู่ได้หลายชั่วโมง
  2. Cloud Firestore frontend จะค้นหาระบบพื้นที่เก็บข้อมูลพื้นฐานเพื่อเริ่มต้นชุดข้อมูล ซึ่งจะโหลดชุดผลการค้นหาทั้งชุดของเอกสาร ที่ตรงกัน เราเรียกการดำเนินการนี้ว่าการค้นหาแบบโพล จากนั้นระบบจะประเมินกฎความปลอดภัย Firebase ของฐานข้อมูลเพื่อยืนยันว่าผู้ใช้เข้าถึงข้อมูลนี้ได้ หากผู้ใช้ได้รับอนุญาต ฐานข้อมูลจะส่งคืนข้อมูลให้กับผู้ใช้
  3. จากนั้นคําค้นหาของลูกค้า ข. จะเข้าสู่โหมดฟังเสียง ผู้ฟังจะลงทะเบียนกับตัวแฮนเดิลการสมัครใช้บริการและรอการอัปเดตข้อมูล
  4. ตอนนี้ไคลเอ็นต์ ก ส่งการดำเนินการเขียนเพื่อแก้ไขเอกสาร
  5. ฐานข้อมูลจะบันทึกการเปลี่ยนแปลงเอกสารลงในระบบพื้นที่เก็บข้อมูล
  6. ในทางธุรกรรม ระบบจะบันทึกการอัปเดตเดียวกันลงในบันทึกการเปลี่ยนแปลงภายใน บันทึกการเปลี่ยนแปลงจะกำหนดลำดับการเปลี่ยนแปลงอย่างเคร่งครัดเมื่อเกิดขึ้น
  7. บันทึกการเปลี่ยนแปลงจะกระจายข้อมูลที่อัปเดตไปยังกลุ่มตัวแฮนเดิลการสมัครใช้บริการ
  8. ตัวจับคู่การค้นหาย้อนกลับจะทำงานเพื่อดูว่าเอกสารที่อัปเดตตรงกับ Listener ของสแนปชอตที่ลงทะเบียนไว้ในปัจจุบันหรือไม่ ในตัวอย่างนี้ เอกสารจะตรงกับเครื่องมือรับฟังภาพรวมของลูกค้า ข. ตามที่ชื่อบอกไว้ คุณสามารถคิดว่าตัวจับคู่การค้นหาแบบย้อนกลับเป็นการค้นหาฐานข้อมูลตามปกติ แต่ทําแบบย้อนกลับ แทนที่จะค้นหาเอกสารต่างๆ ที่ตรงกับคำค้นหา Google Search จะช่วยค้นหาเอกสารที่ตรงกับเอกสารที่เข้ามาใหม่ได้อย่างมีประสิทธิภาพ เมื่อพบรายการที่ตรงกัน ระบบจะส่งต่อเอกสารที่เป็นปัญหาไปยังผู้ฟังสแนปชอต จากนั้นระบบจะประเมินกฎความปลอดภัย Firebase ของฐานข้อมูลเพื่อให้มั่นใจว่ามีเพียงผู้ใช้ที่ได้รับอนุญาตเท่านั้นที่จะได้รับข้อมูล
  9. ระบบจะส่งต่อการอัปเดตเอกสารไปยัง SDK ในอุปกรณ์ของลูกค้า ข. และเรียกใช้การเรียกกลับ onSnapshot หากเปิดใช้การคงอยู่ในเครื่องแล้ว SDK จะใช้การอัปเดตกับแคชในเครื่องด้วย

ส่วนสําคัญของความสามารถในการปรับขนาดของ Cloud Firestore ขึ้นอยู่กับการแยกสาขาจากบันทึกการเปลี่ยนแปลงไปยังตัวแฮนเดิลการสมัครใช้บริการและเซิร์ฟเวอร์ส่วนหน้า การแยกสาขาช่วยให้การเปลี่ยนแปลงข้อมูลรายการเดียวเผยแพร่ได้อย่างมีประสิทธิภาพเพื่อให้บริการการค้นหาแบบเรียลไทม์และผู้ใช้ที่เชื่อมต่อหลายล้านราย Cloud Firestore ทำงานได้อย่างพร้อมใช้งานและปรับขนาดได้สูงด้วยการเรียกใช้คอมโพเนนต์เหล่านี้ทั้งหมดแบบจำลองหลายรายการในหลายโซน (หรือหลายภูมิภาคในกรณีที่มีการทำให้ใช้งานได้ในหลายภูมิภาค)

โปรดทราบว่าการดําเนินการอ่านทั้งหมดที่มาจาก SDK ของอุปกรณ์เคลื่อนที่และเว็บจะเป็นไปตามรูปแบบข้างต้น โดยทำการค้นหาแบบสำรวจตามด้วยโหมดฟังเพื่อรักษาการรับประกันความสอดคล้อง การดำเนินการนี้ยังใช้กับ Listener แบบเรียลไทม์ การเรียกให้ดึงข้อมูลเอกสาร และการค้นหาแบบดำเนินการครั้งเดียวด้วย คุณสามารถมองว่าการดึงข้อมูลเอกสารรายการเดียวและการค้นหาแบบครั้งเดียวคือเครื่องมือรับฟังภาพรวมที่มีอายุสั้นซึ่งมีข้อจำกัดด้านประสิทธิภาพคล้ายกัน

นำแนวทางปฏิบัติแนะนำสำหรับการปรับขนาดการค้นหาแบบเรียลไทม์ไปใช้

ใช้แนวทางปฏิบัติแนะนำต่อไปนี้เพื่อออกแบบการค้นหาแบบเรียลไทม์ที่ปรับขนาดได้

ทำความเข้าใจการเข้าชมการเขียนที่สูงในระบบ

ส่วนนี้ช่วยให้คุณเข้าใจวิธีที่ระบบตอบสนองต่อคำขอเขียนที่เพิ่มขึ้น

Cloud Firestore บันทึกการเปลี่ยนแปลงที่ขับเคลื่อนการค้นหาแบบเรียลไทม์จะปรับขนาดแนวนอนโดยอัตโนมัติเมื่อการเข้าชมการเขียนเพิ่มขึ้น เมื่ออัตราการเขียนสำหรับฐานข้อมูลเพิ่มขึ้นเกินกว่าที่เซิร์ฟเวอร์เดียวจะรองรับได้ ระบบจะแยกบันทึกการเปลี่ยนแปลงไปยังเซิร์ฟเวอร์หลายเครื่อง และการประมวลผลการค้นหาจะเริ่มใช้ข้อมูลจากตัวแฮนเดิลการสมัครใช้บริการหลายรายการแทนที่จะเป็น 1 รายการ จากมุมมองของไคลเอ็นต์และ SDK ทั้งหมดนี้แสดงความโปร่งใสและไม่จำเป็นต้องดำเนินการใดๆ เมื่อมีการแบ่งเกิดขึ้น แผนภาพต่อไปนี้จะแสดงให้เห็นว่าการค้นหาแบบเรียลไทม์มีการปรับขนาดอย่างไร

สถาปัตยกรรมของแฟนเอาต์บันทึกการเปลี่ยนแปลง

การปรับขนาดอัตโนมัติช่วยให้คุณเพิ่มปริมาณการเขียนได้แบบไม่จำกัด แต่ระบบอาจใช้เวลาสักครู่ในการตอบสนองเมื่อปริมาณการเขียนเพิ่มขึ้น ทำตามคำแนะนำของกฎ 5-5-5 ข้อเพื่อหลีกเลี่ยงการสร้างฮอตสปอตการเขียน Key Visualizer เป็นเครื่องมือที่มีประโยชน์สําหรับการวิเคราะห์ฮอตสปอตการเขียน

แอปจำนวนมากมีการเติบโตแบบทั่วไปที่คาดการณ์ได้ ซึ่ง Cloud Firestore สามารถรองรับได้โดยไม่ต้องใช้มาตรการป้องกัน อย่างไรก็ตาม ภาระงานแบบเป็นกลุ่ม เช่น การนําเข้าชุดข้อมูลขนาดใหญ่ อาจเพิ่มการเขียนได้เร็วเกินไป เมื่อออกแบบแอป ให้คำนึงถึงแหล่งที่มาของการเข้าชมที่เขียน

ทําความเข้าใจการโต้ตอบระหว่างการเขียนกับการอ่าน

คุณอาจมองระบบการค้นหาแบบเรียลไทม์เป็นไปป์ไลน์ที่เชื่อมต่อการดำเนินการเขียนกับผู้อ่าน ทุกครั้งที่มีการสร้าง อัปเดต หรือลบเอกสาร การเปลี่ยนแปลงจะแพร่กระจายจากระบบพื้นที่เก็บข้อมูลไปยัง Listener ที่ลงทะเบียนไว้ในปัจจุบัน โครงสร้างบันทึกการเปลี่ยนแปลงของ Cloud Firestore รับประกันความสอดคล้องที่แน่ชัด ซึ่งหมายความว่าแอปของคุณจะไม่ได้รับการแจ้งเตือนการอัปเดตที่ไม่เป็นไปตามลำดับเมื่อเทียบกับเวลาที่ฐานข้อมูลทำการเปลี่ยนแปลงข้อมูล วิธีนี้ช่วยให้การพัฒนาแอปง่ายขึ้นด้วยการนํากรณีขอบเขตด้านความสอดคล้องของข้อมูลออก

ไปป์ไลน์ที่เชื่อมต่อนี้หมายความว่าการดำเนินการเขียนที่ทำให้เกิดฮอตสปอตหรือการช่วงชิงล็อกอาจส่งผลเสียต่อการดำเนินการอ่าน เมื่อการดำเนินการเขียนไม่สำเร็จหรือมีการจำกัด การอ่านอาจหยุดชะงักเพื่อรอข้อมูลที่สอดคล้องกันจากบันทึกการเปลี่ยนแปลง หากเหตุการณ์นี้เกิดขึ้นในแอป คุณอาจเห็นทั้งการดำเนินการเขียนที่ช้าและเวลาในการตอบสนองช้าแบบสัมพันธ์กันสำหรับการค้นหา การหลีกเลี่ยงฮอตสปอตเป็นกุญแจสำคัญในการหลีกเลี่ยงปัญหานี้

เก็บเอกสารและการดำเนินการเขียนให้มีขนาดเล็ก

เมื่อสร้างแอปที่มี Listener ของสแนปชอต โดยทั่วไปคุณต้องการให้ผู้ใช้ดูข้อมูลเกี่ยวกับการเปลี่ยนแปลงข้อมูลได้อย่างรวดเร็ว พยายามทำให้สิ่งต่างๆ มีขนาดไม่ใหญ่ ระบบสามารถพุชเอกสารขนาดเล็กที่มีช่องข้อมูลหลายสิบฟิลด์ในระบบได้อย่างรวดเร็ว เอกสารขนาดใหญ่ที่มีช่องหลายร้อยช่องและข้อมูลขนาดใหญ่จะใช้เวลาประมวลผลนานกว่า

ในทํานองเดียวกัน ให้ใช้การคอมมิตและการเขียนที่สั้นและรวดเร็วเพื่อรักษาเวลาในการตอบสนองให้ต่ำ กลุ่มขนาดใหญ่อาจให้อัตราการส่งข้อมูลสูงขึ้นจากมุมมองของผู้เขียน แต่ก็อาจเพิ่มเวลาการแจ้งเตือนสำหรับผู้ฟังสแนปชอตด้วย ซึ่งมักจะขัดกับความรู้สึกเมื่อเทียบกับการใช้ระบบฐานข้อมูลอื่นๆ ที่อาจใช้การแยกกลุ่มเพื่อปรับปรุงประสิทธิภาพ

ใช้ Listener ที่มีประสิทธิภาพ

เมื่ออัตราการเขียนฐานข้อมูลเพิ่มขึ้น Cloud Firestore จะแยกการประมวลผลข้อมูลไปยังเซิร์ฟเวอร์หลายเครื่อง อัลกอริทึมการแยกส่วนข้อมูลของ Cloud Firestore จะพยายามจัดวางข้อมูลจากคอลเล็กชันหรือกลุ่มคอลเล็กชันเดียวกันไว้ในเซิร์ฟเวอร์บันทึกการเปลี่ยนแปลงเดียวกัน ระบบจะพยายามเพิ่มปริมาณการเขียนให้ได้สูงสุดในขณะที่รักษาจำนวนเซิร์ฟเวอร์ที่มีส่วนร่วมในการประมวลผลคำค้นหาให้ต่ำที่สุด

อย่างไรก็ตาม รูปแบบบางอย่างอาจยังทําให้ตัวฟังภาพรวมทํางานได้ไม่ดีเท่าที่ควร ตัวอย่างเช่น หากแอปของคุณจัดเก็บข้อมูลส่วนใหญ่ไว้ในคอลเล็กชันขนาดใหญ่ 1 ชุด ผู้ฟังอาจต้องเชื่อมต่อกับเซิร์ฟเวอร์จำนวนมากเพื่อรับข้อมูลทั้งหมดที่ต้องการ ซึ่งจะยังคงเป็นเช่นนี้อยู่แม้ว่าคุณจะใช้ตัวกรองข้อความค้นหาก็ตาม การเชื่อมต่อกับเซิร์ฟเวอร์หลายเครื่องจะเพิ่มความเสี่ยงที่การตอบกลับจะช้าลง

หากต้องการหลีกเลี่ยงการตอบกลับที่ช้าลง ให้ออกแบบสคีมาและแอปเพื่อให้ระบบแสดงผลผู้ฟังได้โดยไม่ต้องไปที่เซิร์ฟเวอร์หลายแห่ง คุณอาจต้องแบ่งข้อมูลออกเป็นคอลเล็กชันขนาดเล็กที่มีอัตราการเขียนน้อยลง

ซึ่งคล้ายกับการพิจารณาการค้นหาประสิทธิภาพในฐานข้อมูลเชิงสัมพันธ์ที่ต้องมีการสแกนตารางทั้งหมด ในฐานข้อมูลเชิงสัมพันธ์ การค้นหาที่ต้องมีการสแกนตารางทั้งหมดจะเทียบเท่ากับเครื่องมือรับฟังสแนปชอตที่คอยตรวจสอบคอลเล็กชันที่มีการเปลี่ยนแปลงสูง ซึ่งอาจทํางานช้าเมื่อเทียบกับการค้นหาที่ฐานข้อมูลสามารถแสดงโดยใช้ดัชนีที่เฉพาะเจาะจงมากขึ้น การค้นหาที่มีดัชนีที่เฉพาะเจาะจงมากขึ้นจะเหมือนกับ Listener สแนปชอตที่คอยตรวจสอบเอกสารหรือคอลเล็กชันรายการเดียวที่มีการเปลี่ยนแปลงไม่บ่อยนัก คุณควรโหลดทดสอบแอปเพื่อให้เข้าใจพฤติกรรมและความต้องการใน Use Case ของคุณมากที่สุด

ดำเนินการค้นหาแบบโพลอย่างรวดเร็ว

ส่วนสำคัญอีกอย่างของการค้นหาแบบเรียลไทม์ที่ปรับเปลี่ยนตามอุปกรณ์เกี่ยวข้องกับการตรวจสอบว่าการค้นหาเพื่อการสำรวจข้อมูลเพื่อเปิดทำงานได้อย่างรวดเร็วและมีประสิทธิภาพ เมื่อเชื่อมต่อครั้งแรก ผู้รับฟังภาพรวมใหม่ต้องโหลดชุดผลลัพธ์ทั้งหมดและส่งไปยังอุปกรณ์ของผู้ใช้ การค้นหาที่ช้าจะทำให้แอปตอบสนองช้าลง ซึ่งรวมถึงคำค้นหาที่พยายามอ่านเอกสารจำนวนมากหรือคำค้นหาที่ไม่ได้ใช้ดัชนีที่เหมาะสม

ในบางกรณี ผู้ฟังอาจเปลี่ยนกลับจากสถานะการฟังเป็นสถานะแบบสำรวจ ซึ่งจะเกิดขึ้นโดยอัตโนมัติและโปร่งใสต่อ SDK และแอปของคุณ เงื่อนไขต่อไปนี้อาจทริกเกอร์สถานะการโหวต

หากคำค้นหาในแบบสำรวจเร็วพอ สถานะแบบสำรวจจะโปร่งใสสำหรับผู้ใช้แอป

ชื่นชอบผู้ฟังเป็นระยะเวลานาน

การเปิดให้ผู้ใช้ฟังอย่างต่อเนื่องให้นานที่สุดคือวิธีที่คุ้มค่าที่สุดในการสร้างแอปที่ใช้ Cloud Firestore เมื่อใช้ Cloud Firestore ระบบจะเรียกเก็บเงินสำหรับเอกสารที่ส่งคืนไปยังแอป ไม่ใช่สำหรับการรักษาการเชื่อมต่อแบบเปิด Listener ของสแนปชอตที่มีอายุการใช้งานยาวนานจะอ่านเฉพาะข้อมูลที่จําเป็นต่อการแสดงคําค้นหาตลอดอายุการใช้งาน ซึ่งรวมถึงการดำเนินการสำรวจครั้งแรก ตามด้วยการแจ้งเตือนเมื่อข้อมูลมีการเปลี่ยนแปลงจริง ในทางกลับกัน การค้นหาแบบครั้งเดียวจะอ่านข้อมูลอีกครั้งซึ่งอาจไม่เปลี่ยนแปลงนับตั้งแต่ที่แอปเรียกใช้การค้นหาครั้งล่าสุด

ในกรณีที่แอปต้องใช้อินเทอร์เน็ตในอัตราสูง Listener ของสแนปชอตอาจไม่เหมาะสม ตัวอย่างเช่น หาก Use Case ของคุณส่งเอกสารหลายรายการต่อวินาทีผ่านการเชื่อมต่อเป็นระยะเวลานาน คุณอาจเลือกใช้การค้นหาแบบครั้งเดียวที่ทำงานด้วยความถี่ต่ำลง

ขั้นตอนถัดไป