ใช้แนวทางปฏิบัติแนะนำที่ระบุไว้ที่นี่เป็นข้อมูลอ้างอิงอย่างรวดเร็ว เมื่อสร้างแอปพลิเคชันที่ใช้ 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 การใช้ออฟเซ็ตเพียงแค่ช่วยเลี่ยง ส่งคืนเอกสารที่ถูกข้ามไป ไปยังแอปพลิเคชันของคุณ แต่เอกสารเหล่านี้ ที่ยังมีการเรียกคืนเป็นการภายใน เอกสารที่ถูกข้ามจะมีผลต่อเวลาในการตอบสนองของ และแอปพลิเคชันของคุณจะถูกเรียกเก็บเงินสำหรับการดำเนินการอ่านที่จำเป็นต้องดำเนินการ เพื่อเรียกดูข้อมูล
การลองทำธุรกรรมซ้ำ
Cloud Firestore SDK และไคลเอ็นต์ ไลบรารีลองอีกครั้งโดยอัตโนมัติไม่สำเร็จ ธุรกรรมเพื่อจัดการกับข้อผิดพลาดชั่วคราว หากแอปพลิเคชันของคุณเข้าถึง 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 อาจไม่สามารถเตรียมความพร้อมของคอลเล็กชันใหม่ เพื่อรองรับการเข้าชมที่เพิ่มขึ้น โดยเฉพาะเมื่อมีเอกสารจำนวนน้อย
ปัญหาที่คล้ายกันนี้อาจเกิดขึ้นได้ถ้าคุณเปลี่ยนรหัสของเอกสารหลายฉบับ ภายในคอลเล็กชันเดียวกัน
กลยุทธ์ที่ดีที่สุดสำหรับการย้ายการเข้าชมไปยังคอลเล็กชันใหม่จะขึ้นอยู่กับข้อมูลของคุณ โมเดล ด้านล่างคือตัวอย่างกลยุทธ์ที่เรียกว่าการอ่านพร้อมกัน คุณจะต้องทำดังนี้ คุณจะพิจารณาว่ากลยุทธ์นี้ มีประสิทธิภาพสำหรับข้อมูลของคุณไหม และ ข้อควรพิจารณาที่สำคัญคือผลกระทบด้านต้นทุนของการดำเนินงานพร้อมกันในระหว่าง การย้ายข้อมูล
การอ่านพร้อมกัน
หากต้องการใช้การอ่านพร้อมกันเมื่อคุณย้ายข้อมูลการจราจรของข้อมูลไปยังคอลเล็กชันใหม่ โปรดอ่าน จากคอลเล็กชันเก่าก่อน หากเอกสารหายไป ให้อ่านจาก คอลเล็กชันใหม่ อัตราการอ่านเอกสารที่ไม่มีอยู่สูงอาจทำให้เกิด ดังนั้น โปรดค่อยๆ เพิ่มภาระงานให้แก่ คอลเล็กชัน กลยุทธ์ที่ดีกว่าคือการคัดลอกเอกสารเก่าไปยังคอลเล็กชันใหม่ จากนั้นให้ลบเอกสารเก่า ค่อยๆ เพิ่มการอ่านพร้อมกันเพื่อให้แน่ใจว่า Cloud Firestore จะจัดการการเข้าชมคอลเล็กชันใหม่ได้
กลยุทธ์ที่เป็นไปได้ในการค่อยๆ เพิ่มการอ่านหรือการเขียนในคอลเล็กชันใหม่ คือการใช้แฮชเชิงกำหนดของรหัสผู้ใช้เพื่อเลือกเปอร์เซ็นต์แบบสุ่มของ ผู้ใช้ที่พยายามเขียนเอกสารใหม่ ตรวจสอบว่าผลลัพธ์ของผู้ใช้ แฮชรหัสต้องไม่บิดเบือนจากฟังก์ชันหรือพฤติกรรมของผู้ใช้
ในขณะเดียวกัน ให้เรียกใช้งานแบบกลุ่มที่คัดลอกข้อมูลทั้งหมดของคุณจากเอกสารเก่าไปยัง คอลเล็กชันใหม่ งานแบบกลุ่มควรหลีกเลี่ยงการเขียนในเอกสารตามลำดับ รหัสเพื่อป้องกันฮอตสปอต เมื่องานแบบกลุ่มเสร็จสิ้น คุณจะอ่านได้อย่างเดียว จากคอลเล็กชันใหม่
การปรับแต่งกลยุทธ์นี้คือการย้ายข้อมูลผู้ใช้กลุ่มเล็กๆ ในแต่ละครั้ง เพิ่มช่องลงในเอกสารของผู้ใช้ที่ติดตามสถานะการย้ายข้อมูลของผู้ใช้นั้น เลือกกลุ่มผู้ใช้ที่จะย้ายข้อมูลตามแฮชของรหัสผู้ใช้ ใช้ งานแบบกลุ่มเพื่อย้ายข้อมูลเอกสารสำหรับผู้ใช้กลุ่มนั้น และใช้ ในการอ่านพร้อมกันสำหรับผู้ใช้ ในระหว่างการย้ายข้อมูล
โปรดทราบว่าคุณไม่สามารถย้อนกลับได้ง่ายๆ เว้นแต่คุณจะเขียนทั้ง 2 ข้อความเก่า และเอนทิตีใหม่ในระยะการย้ายข้อมูล วิธีนี้จะเพิ่ม เกิดค่าใช้จ่าย Cloud Firestore
ความเป็นส่วนตัว
- หลีกเลี่ยงการจัดเก็บข้อมูลที่ละเอียดอ่อนไว้ในรหัสโปรเจ็กต์ที่อยู่ในระบบคลาวด์ รหัสโปรเจ็กต์ที่อยู่ในระบบคลาวด์ อาจคงอยู่นอกระยะเวลาของโครงการ
- ตามแนวทางปฏิบัติแนะนำในการปฏิบัติตามข้อกำหนดด้านข้อมูล เราขอแนะนำไม่ให้จัดเก็บข้อมูลที่ละเอียดอ่อน ข้อมูลในชื่อของเอกสารและชื่อช่องของเอกสาร
ป้องกันการเข้าถึงที่ไม่ได้รับอนุญาต
ป้องกันการดำเนินการที่ไม่ได้รับอนุญาตในฐานข้อมูลด้วย Cloud Firestore Security Rules ตัวอย่างเช่น การใช้กฎอาจหลีกเลี่ยงสถานการณ์ที่ ผู้ใช้ที่มีเจตนาร้ายดาวน์โหลดฐานข้อมูลทั้งหมดซ้ำๆ
ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ Cloud Firestore Security Rules