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

อ่านเอกสารนี้เพื่อรับคำแนะนำเกี่ยวกับการปรับขนาดแอปแบบ 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 อุปกรณ์เคลื่อนที่อันใดอันหนึ่ง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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