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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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