ทำความเข้าใจการอ่านและเขียนในวงกว้าง

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

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

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

ดูแนวทางปฏิบัติแนะนำในส่วนต่อไปนี้ก่อนออกแบบสถาปัตยกรรมแอปพลิเคชัน

ทำความเข้าใจองค์ประกอบระดับสูง

แผนภาพต่อไปนี้แสดงคอมโพเนนต์ระดับสูงที่เกี่ยวข้องกับคำขอ Cloud Firestore API

SDK และไลบรารีของไคลเอ็นต์ Cloud Firestore

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

Google Front End (GFE)

ซึ่งเป็นบริการโครงสร้างพื้นฐานที่ใช้ร่วมกันในบริการระบบคลาวด์ทั้งหมดของ Google GFE จะยอมรับคำขอที่เข้ามาและส่งต่อไปยังบริการที่เกี่ยวข้องของ Google (บริการ Cloud Firestore ในบริบทนี้) นอกจากนี้ ยังมีฟังก์ชันที่สำคัญอื่นๆ เช่น การป้องกันการโจมตีแบบปฏิเสธการให้บริการ

Cloud Firestore บริการ

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

เลเยอร์พื้นที่เก็บข้อมูล Cloud Firestore

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

ช่วงคีย์และการแยกคีย์

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

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

การจำลองแบบซิงโครนัส

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

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

เลย์เอาต์ข้อมูล

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

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

แผนภาพต่อไปนี้แสดงลักษณะของตารางสำหรับฐานข้อมูล Cloud Firestore ที่มีการแยกข้อมูล ระบบจะจำลองการแยกข้อมูลใน 3 โซนที่แตกต่างกัน และการแยกข้อมูลแต่ละรายการจะมี Paxos Leader ที่ได้รับมอบหมาย

ภูมิภาคเดียวเทียบกับหลายภูมิภาค

เมื่อสร้างฐานข้อมูล คุณต้องเลือกภูมิภาคหรือหลายภูมิภาค

สถานที่ตั้งระดับภูมิภาคแห่งเดียวคือสถานที่ตั้งทางภูมิศาสตร์ที่เฉพาะเจาะจง เช่น us-west1 การแยกข้อมูลของฐานข้อมูล Cloud Firestore จะมีตัวจำลองในโซนต่างๆ ภายในภูมิภาคที่เลือก ตามที่อธิบายไว้ก่อนหน้านี้

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับสถานที่ตั้งของภูมิภาคได้ที่สถานที่ตั้งของ Cloud Firestore

ทำความเข้าใจวงจรชีวิตของการเขียนใน Cloud Firestore

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

สำหรับการเขียนทุกประเภท Cloud Firestore จะมีคุณสมบัติ ACID (Atomicity, Consistency, Isolation และ Durability) ของฐานข้อมูลเชิงสัมพันธ์ นอกจากนี้ Cloud Firestore ยังมีความสามารถในการจัดลำดับ ซึ่งหมายความว่าธุรกรรมทั้งหมดจะปรากฏราวกับว่าดำเนินการตามลำดับอนุกรม

ขั้นตอนระดับสูงในธุรกรรมการเขียน

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

ในขั้นตอนแรกของธุรกรรม Cloud Firestore จะอ่านเอกสารที่มีอยู่ และกำหนดการเปลี่ยนแปลงที่จะทำกับข้อมูลในตาราง Documents

ซึ่งรวมถึงการอัปเดตที่จำเป็นในตารางดัชนีดังต่อไปนี้

• ฟิลด์ที่เพิ่มลงในเอกสารต้องมีการแทรกที่สอดคล้องกันในตารางดัชนี
• ฟิลด์ที่ถูกนำออกจากเอกสารจะต้องมีการลบที่สอดคล้องกันในตาราง Indexes
• ฟิลด์ที่กำลังแก้ไขในเอกสารต้องมีทั้งการลบ (สำหรับค่าเก่า) และการแทรก (สำหรับค่าใหม่) ในตารางดัชนี

ในการคำนวณการเปลี่ยนแปลงที่กล่าวถึงก่อนหน้านี้ Cloud Firestore จะอ่านการกำหนดค่าการจัดทำดัชนีสำหรับฐานข้อมูล การกำหนดค่าการจัดทำดัชนีจะจัดเก็บข้อมูลเกี่ยวกับดัชนีสำหรับฐานข้อมูล Cloud Firestore ใช้ดัชนี 2 ประเภท ได้แก่ ฟิลด์เดียวและแบบผสม ดูข้อมูลโดยละเอียดเกี่ยวกับดัชนีที่สร้างใน Cloud Firestore ได้ที่ประเภทดัชนีใน Cloud Firestore

เมื่อคำนวณการเปลี่ยนแปลงแล้ว Cloud Firestore จะรวบรวมการเปลี่ยนแปลงไว้ในธุรกรรมแล้วจึงคอมมิต

ทำความเข้าใจธุรกรรมการเขียนในเลเยอร์พื้นที่เก็บข้อมูล

ตามที่ได้อธิบายไปก่อนหน้านี้ การเขียนใน Cloud Firestore เกี่ยวข้องกับธุรกรรมการอ่าน-เขียนในเลเยอร์พื้นที่เก็บข้อมูล การเขียนอาจเกี่ยวข้องกับการแยกข้อมูลอย่างน้อย 1 รายการตามที่เห็นในเลย์เอาต์ข้อมูล ทั้งนี้ขึ้นอยู่กับเลย์เอาต์ของข้อมูล

ในแผนภาพต่อไปนี้ ฐานข้อมูล Cloud Firestore มีการแยกข้อมูล 8 รายการ (ทำเครื่องหมาย 1-8) ซึ่งโฮสต์อยู่ในเซิร์ฟเวอร์พื้นที่เก็บข้อมูล 3 แห่งที่แตกต่างกันในโซนเดียว และการแยกข้อมูลแต่ละรายการจะจำลองในโซนที่แตกต่างกัน 3 โซน(หรือมากกว่า) การแยกแต่ละรายการจะมี Paxos Leader ซึ่งอาจอยู่ในโซนที่แตกต่างกันสำหรับการแยกที่แตกต่างกัน

การแยกฐานข้อมูล Cloud Firestore">

พิจารณาฐานข้อมูล Cloud Firestore ที่มีคอลเล็กชัน Restaurants ดังนี้

ไคลเอ็นต์ Cloud Firestore ขอให้ทำการเปลี่ยนแปลงต่อไปนี้กับเอกสารในคอลเล็กชัน Restaurant โดยอัปเดตค่าของช่อง priceCategory

ขั้นตอนระดับสูงต่อไปนี้อธิบายสิ่งที่เกิดขึ้นในระหว่างการเขียน

1. สร้างธุรกรรมการอ่าน-เขียน
2. อ่านเอกสาร restaurant1 ในคอลเล็กชัน Restaurants จากตาราง Documents จากเลเยอร์พื้นที่เก็บข้อมูล
3. อ่านดัชนีของเอกสารจากตารางดัชนี
4. คำนวณการเปลี่ยนแปลงที่จะทำกับข้อมูล ในกรณีนี้ มีการกลายพันธุ์ 5 แบบ ดังนี้
   • M1: อัปเดตแถวสำหรับ restaurant1 ในตารางเอกสารเพื่อให้สอดคล้องกับการเปลี่ยนแปลงค่าของช่อง priceCategory
   • M2 และ M3: ลบแถวสำหรับค่าเก่าของ priceCategory ในตารางดัชนีสำหรับดัชนีจากมากไปน้อยและจากน้อยไปมาก
   • M4 และ M5: แทรกแถวสำหรับค่าใหม่ของ priceCategory ในตารางดัชนีสำหรับดัชนีจากมากไปน้อยและจากน้อยไปมาก
5. คอมมิตการเปลี่ยนแปลงเหล่านี้

ไคลเอ็นต์พื้นที่เก็บข้อมูลในบริการ Cloud Firestore จะค้นหาการแยกที่เป็นเจ้าของคีย์ของแถวที่จะเปลี่ยนแปลง ลองพิจารณากรณีที่กลุ่ม 3 แสดง M1 และกลุ่ม 6 แสดง M2-M5 มีธุรกรรมแบบกระจายที่เกี่ยวข้องกับการแยกทั้งหมดเหล่านี้ในฐานะผู้เข้าร่วม การแยกข้อมูลของผู้เข้าร่วมอาจรวมถึงการแยกข้อมูลอื่นๆ ที่มีการอ่านข้อมูลก่อนหน้านี้โดยเป็นส่วนหนึ่งของธุรกรรมการอ่าน-เขียนด้วย

ขั้นตอนต่อไปนี้จะอธิบายสิ่งที่เกิดขึ้นเมื่อมีการคอมมิต

1. ไคลเอ็นต์พื้นที่เก็บข้อมูลจะส่งการคอมมิต คอมมิตประกอบด้วยการเปลี่ยนแปลง M1-M5
2. ส่วนที่ 3 และ 6 เป็นผู้เข้าร่วมในธุรกรรมนี้ ระบบจะเลือกผู้เข้าร่วม 1 รายเป็นผู้ประสานงาน เช่น Split 3 หน้าที่ของผู้ประสานงานคือตรวจสอบว่าธุรกรรมคอมมิตหรือยกเลิกแบบอะตอมมิกในผู้เข้าร่วมทั้งหมด
   • ตัวจำลองผู้นำของส่วนเหล่านี้มีหน้าที่รับผิดชอบงานที่ผู้เข้าร่วมและผู้ประสานงานทำ
3. ผู้เข้าร่วมและผู้ประสานงานแต่ละรายจะเรียกใช้อัลกอริทึม Paxos กับตัวจำลองของตน
   • ผู้นำจะเรียกใช้อัลกอริทึม Paxos กับตัวจำลอง ระบบจะบรรลุข้อตกลงร่วมกันหากตัวจำลองส่วนใหญ่ตอบกลับผู้นำด้วยการตอบกลับ ok to commit
   • จากนั้นผู้เข้าร่วมแต่ละรายจะแจ้งให้ผู้ประสานงานทราบเมื่อเตรียมพร้อม (ระยะแรกของคอมมิตแบบ 2 ระยะ) หากผู้เข้าร่วมรายใดไม่สามารถทำธุรกรรมได้ ธุรกรรมทั้งหมดจะaborts
4. เมื่อผู้ประสานงานทราบว่าผู้เข้าร่วมทั้งหมด รวมถึงตัวผู้ประสานงานเองพร้อมแล้ว ก็จะสื่อสารผลลัพธ์ของธุรกรรม accept ไปยังผู้เข้าร่วมทั้งหมด (ระยะที่ 2 ของการคอมมิตแบบ 2 ระยะ) ในระยะนี้ ผู้เข้าร่วมแต่ละรายจะบันทึกการตัดสินใจคอมมิตลงในพื้นที่เก็บข้อมูลที่เสถียรและคอมมิตธุรกรรม
5. ผู้ประสานงานจะตอบกลับไคลเอ็นต์พื้นที่เก็บข้อมูลใน Cloud Firestore ว่าธุรกรรมได้รับการยืนยันแล้ว ในขณะเดียวกัน ผู้ประสานงานและผู้เข้าร่วมทั้งหมดจะใช้การเปลี่ยนแปลงกับข้อมูล

เมื่อฐานข้อมูล Cloud Firestore มีขนาดเล็ก อาจเป็นไปได้ว่าการแยกรายการเดียวเป็นเจ้าของคีย์ทั้งหมดในการกลายพันธุ์ M1-M5 ในกรณีนี้ จะมีผู้เข้าร่วมเพียงรายเดียวในธุรกรรม และไม่จำเป็นต้องใช้การคอมมิตแบบ 2 เฟสที่กล่าวถึงก่อนหน้านี้ จึงทำให้เขียนได้เร็วขึ้น

การเขียนในหลายภูมิภาค

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

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

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

ทำความเข้าใจอายุการใช้งานของอุปกรณ์อ่านใน Cloud Firestore

ส่วนนี้จะเจาะลึกเกี่ยวกับการอ่านแบบสแตนด์อโลนที่ไม่ใช่แบบเรียลไทม์ใน Cloud Firestore ภายในเซิร์ฟเวอร์ Cloud Firestore จะจัดการคำค้นหาส่วนใหญ่เหล่านี้ใน 2 ขั้นตอนหลักๆ ดังนี้

1. การสแกนช่วงเดียวในตารางดัชนี
2. การค้นหาจุดในตารางเอกสารตามผลลัพธ์ของการสแกนก่อนหน้า

อาจมีการค้นหาบางรายการที่ต้องใช้การประมวลผลน้อยลงหรือมากขึ้น (เช่น การค้นหา IN) ใน Cloud Firestore

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

ทำความเข้าใจธุรกรรมการอ่านในเลเยอร์พื้นที่เก็บข้อมูล

ส่วนนี้จะอธิบายประเภทของการอ่านและวิธีประมวลผลในเลเยอร์พื้นที่เก็บข้อมูลใน Cloud Firestore

เนื้อหาที่น่าสนใจ

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

การอ่านแบบแยกหน้าจอเดียว

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

ณ จุดนี้ กรณีต่อไปนี้อาจเกิดขึ้นโดยขึ้นอยู่กับตัวจำลองที่เลือก

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

จากนั้น Cloud Firestore จะส่งคำตอบกลับไปยังไคลเอ็นต์

การอ่านแบบแยกหลายส่วน

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

การอ่านข้อมูลที่ล้าสมัย

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

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

หลีกเลี่ยงฮอตสปอต

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

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

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

ข้อผิดพลาดจากการช่วงชิงทรัพยากรจะเกิดขึ้นเมื่อมีการดำเนินการหลายอย่างที่พยายามอ่านและ/หรือเขียนเอกสารเดียวกันพร้อมกัน

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

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

การแก้ปัญหา

Cloud Firestore มี Key Visualizer เป็นเครื่องมือวินิจฉัยที่ออกแบบมาเพื่อวิเคราะห์รูปแบบการใช้งานและแก้ปัญหาฮอตสปอต

ต้องทำอะไรต่อไป

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