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

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

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

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

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

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

รหัสเอกสาร

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

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

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

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

ชื่อฟิลด์

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

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

ดัชนี

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

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

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

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

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

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

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

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

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

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

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

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

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