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

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

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

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

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

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

รหัสเอกสาร

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

• อย่าใช้รหัสเอกสารที่เพิ่มซ้ำๆ เช่น

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

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

ชื่อช่อง

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

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

ดัชนี

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

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

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

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

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

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

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

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

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

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

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

การลองทำธุรกรรมซ้ำ

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

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

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

การออกแบบสำหรับการปรับขนาด

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 อาจไม่สามารถเตรียมความพร้อมของคอลเล็กชันใหม่ เพื่อรองรับการเข้าชมที่เพิ่มขึ้น โดยเฉพาะเมื่อมีเอกสารจำนวนน้อย

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

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

การอ่านพร้อมกัน

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

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

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

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

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

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

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

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

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้กฎความปลอดภัยของ Cloud Firestore