ทำความเข้าใจการสืบค้นตามเวลาจริงตามขนาด ทำความเข้าใจการสืบค้นแบบเรียลไทม์ตามขนาด

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

เลือกระหว่างสถานที่ตั้งในระดับภูมิภาคและหลายภูมิภาค

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

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

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

ลองนึกภาพผู้ใช้สองคนที่เชื่อมต่อกับ 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 จะได้รับการแจ้งเตือนทันทีทุกครั้งที่มีคนสร้างข้อความใหม่ แผนภาพต่อไปนี้แสดงสถาปัตยกรรมเบื้องหลัง Listener สแน็ปช็อต:

สถาปัตยกรรมของการเชื่อมต่อผู้ฟังสแน็ปช็อต

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

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

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

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

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

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

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

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

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

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

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

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

ทำความเข้าใจว่าการเขียนและการอ่านโต้ตอบกันอย่างไร

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

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

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

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

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

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

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

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

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

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

ทำการสอบถามแบบสำรวจความคิดเห็นอย่างรวดเร็ว

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

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

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

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

โปรดปรานผู้ฟังที่มีอายุยืนยาว

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

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

อะไรต่อไป