แนวทางปฏิบัติแนะนำสำหรับ Cloud Firestore

ใช้แนวทางปฏิบัติแนะนำที่ระบุไว้ที่นี่เป็นข้อมูลอ้างอิงแบบย่อ เมื่อสร้างแอปพลิเคชันที่ใช้ Cloud Firestore

ตำแหน่งที่ตั้งของฐานข้อมูล

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

หากต้องการเพิ่มความพร้อมใช้งานและความคงทนของ แอปพลิเคชัน ให้เลือกสถานที่ตั้งแบบหลายภูมิภาคและ วางทรัพยากรการประมวลผลที่สำคัญในอย่างน้อย 2 ภูมิภาค

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

รหัสเอกสาร

• หลีกเลี่ยงรหัสเอกสาร . และ ..
• หลีกเลี่ยงการใช้เครื่องหมายทับ / ในรหัสเอกสาร

• อย่าใช้รหัสเอกสารที่เพิ่มขึ้นอย่างต่อเนื่อง เช่น

  • Customer1, Customer2, Customer3, ...
  • Product 1, Product 2, Product 3, ...

  รหัสที่ต่อเนื่องกันดังกล่าวอาจทำให้เกิดฮอตสปอตที่ส่งผลต่อเวลาในการตอบสนอง

ชื่อฟิลด์

• หลีกเลี่ยงการใช้อักขระต่อไปนี้ในชื่อฟิลด์เนื่องจากต้องมีการหลีกเพิ่มเติม

  • . จุด
  • [ วงเล็บเหลี่ยมเปิด
  • ] วงเล็บเหลี่ยมขวา
  • * เครื่องหมายดอกจัน
  • ` แบ็กทิก

ดัชนี

ลดเวลาในการตอบสนองของการเขียน

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

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

• ลดจำนวนเอกสารในธุรกรรม หากต้องการเขียนเอกสารจำนวนมาก ให้พิจารณาใช้เครื่องมือเขียนแบบกลุ่มแทนเครื่องมือเขียนแบบเป็นชุด

การยกเว้นดัชนี

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

การดำเนินการอ่านและเขียน

• อัตราสูงสุดที่แน่นอนซึ่งแอปสามารถอัปเดตเอกสารเดียวได้นั้นขึ้นอยู่กับปริมาณงานเป็นอย่างมาก ดูข้อมูลเพิ่มเติมได้ที่การอัปเดตเอกสารเดียว

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

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

การลองทำธุรกรรมอีกครั้ง

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

การอัปเดตแบบเรียลไทม์

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

การออกแบบเพื่อการปรับขนาด

แนวทางปฏิบัติแนะนำต่อไปนี้จะอธิบายวิธีหลีกเลี่ยงสถานการณ์ที่ ทำให้เกิดปัญหาการแย่งชิง

การอัปเดตเอกสารเดียว

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

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

อัตราการอ่าน เขียน และลบสูงในช่วงเอกสารที่แคบ

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

• สร้างเอกสารใหม่ในอัตราที่สูงมาก และจัดสรรรหัสที่เพิ่มขึ้นอย่างต่อเนื่องของตัวเอง

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

• สร้างเอกสารใหม่ในคอลเล็กชันที่มีเอกสารน้อยในอัตราสูง

• สร้างเอกสารใหม่ที่มีฟิลด์ที่เพิ่มขึ้นอย่างต่อเนื่อง เช่น การประทับเวลา ในอัตราที่สูงมาก

• ลบเอกสารในคอลเล็กชันในอัตราที่สูง

• เขียนไปยังฐานข้อมูลในอัตราที่สูงมาก โดยไม่ได้ค่อยๆ เพิ่มการเข้าชม

หลีกเลี่ยงการข้ามข้อมูลที่ถูกลบ

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

ตัวอย่างภาระงานที่อาจต้องข้ามข้อมูลที่ลบไปจำนวนมากคือ ภาระงานที่พยายามค้นหารายการงานที่คิวเก่าที่สุด คำค้นหาอาจมีลักษณะดังนี้

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

ทุกครั้งที่เรียกใช้คําค้นหานี้ ระบบจะสแกนรายการดัชนีสําหรับฟิลด์ created ในเอกสารที่เพิ่งลบไป ซึ่งจะทำให้การค้นหาช้าลง

หากต้องการปรับปรุงประสิทธิภาพ ให้ใช้วิธี start_at เพื่อค้นหาจุดเริ่มต้นที่ดีที่สุด เช่น

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

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

เพิ่มการเข้าชม

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

การย้ายข้อมูลการเข้าชมไปยังคอลเล็กชันใหม่

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

ปัญหาที่คล้ายกันอาจเกิดขึ้นหากคุณเปลี่ยนรหัสเอกสารของเอกสารหลายฉบับ ภายในคอลเล็กชันเดียวกัน

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

การอ่านแบบขนาน

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

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

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

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

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

ความเป็นส่วนตัว

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

ป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ Cloud Firestore Security Rules