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

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

Cloud Firestore และ SDK บนอุปกรณ์เคลื่อนที่/เว็บของ Firebase เป็นโมเดลอันทรงพลังในการพัฒนาแอปแบบ 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 อุปกรณ์เคลื่อนที่ตัวใดตัวหนึ่ง

ไคลเอ็นต์ ก จะเขียนฐานข้อมูลเพื่อเพิ่มและอัปเดตเอกสารในคอลเล็กชันที่ชื่อ chatroom

collection chatroom:
    document message1:
      from: 'Sparky'
      message: 'Welcome to Cloud Firestore!'

    document message2:
      from: 'Santa'
      message: 'Presents are coming'

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

สถาปัตยกรรมของการเชื่อมต่อ Listener ของสแนปชอต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ใช้การฟังที่มีประสิทธิภาพ

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

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

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

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

ทำให้การสำรวจความคิดเห็นรวดเร็ว

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

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

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

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

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

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

ขั้นต่อไปคืออะไร