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

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

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

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

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

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

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

สมมติว่าผู้ใช้ 2 รายเชื่อมต่อกับ Cloud Firestore ผ่านแอปรับส่งข้อความที่สร้างขึ้นด้วย SDK บนอุปกรณ์เคลื่อนที่

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

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

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

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

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

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

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

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

ให้ความสำคัญกับ Listener ที่ทำงานได้นาน

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

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

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