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

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

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

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

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

ทําความเข้าใจคอมโพเนนต์ระดับสูง

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

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

Cloud Firestore รองรับ SDK และไลบรารีไคลเอ็นต์สำหรับแพลตฟอร์มต่างๆ แม้ว่าแอปจะเรียก HTTP และ RPC ไปยัง Cloud Firestore API ได้โดยตรง แต่ไลบรารีของไคลเอ็นต์จะทำหน้าที่เป็นเลเยอร์การแยกแยะเพื่อลดความซับซ้อนในการใช้ 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 ตารางในชั้นพื้นที่เก็บข้อมูล ดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เมื่อคำนวณการกลายพันธุ์แล้ว Cloud Firestore จะรวบรวมการกลายพันธุ์เหล่านั้นไว้ในธุรกรรม แล้วจึงทําการคอมมิต

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

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

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

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

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

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

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

1. สร้างธุรกรรมแบบอ่าน/เขียน
2. อ่านเอกสาร restaurant1 ในคอลเล็กชัน Restaurants จากตารางเอกสารจากเลเยอร์พื้นที่เก็บข้อมูล
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 เป็นผู้เข้าร่วมในธุรกรรมนี้ เลือกผู้เข้าร่วมคนใดคนหนึ่งเป็นผู้ประสานงาน เช่น กลุ่มที่ 3 หน้าที่ของผู้ประสานงานคือตรวจสอบว่าธุรกรรมจะดำเนินการเสร็จสมบูรณ์หรือยกเลิกโดยสมบูรณ์กับผู้เข้าร่วมทุกคน
   • รีเพลิกาของผู้นำของกลุ่มย่อยเหล่านี้มีหน้าที่รับผิดชอบต่องานที่ผู้เข้าร่วมและผู้ประสานงานทำ
3. ผู้เข้าร่วมและผู้ประสานงานแต่ละรายจะเรียกใช้อัลกอริทึม Paxos กับข้อมูลจำลองของตน
   • ผู้นำจะเรียกใช้อัลกอริทึม Paxos กับโหนดสํารอง ตัวจำลองจะบรรลุผลถ้าตัวจำลองส่วนใหญ่ตอบกลับด้วยการตอบสนอง ok to commit ไปยังตัวแปรที่ได้
   • จากนั้นผู้เข้าร่วมแต่ละรายจะแจ้งให้ผู้ประสานงานทราบเมื่อพร้อม (ระยะแรกของการคอมมิตแบบ 2 ระยะ) หากผู้เข้าร่วมรายใดไม่สามารถยืนยันธุรกรรม ธุรกรรมทั้งหมดจะaborts
4. เมื่อทราบว่าผู้เข้าร่วมทุกคน รวมถึงตัวผู้ประสานงานเองพร้อมแล้ว ก็จะแจ้งผลการทำธุรกรรม accept ให้ผู้เข้าร่วมทุกคนทราบ (ระยะที่ 2 ของการทำธุรกรรมแบบ 2 ระยะ) ในระยะนี้ ผู้เข้าร่วมแต่ละรายจะบันทึกการตัดสินใจที่จะทําธุรกรรมลงในพื้นที่เก็บข้อมูลแบบถาวรและทําธุรกรรม
5. ผู้ประสานงานจะตอบกลับไคลเอ็นต์พื้นที่เก็บข้อมูลใน Cloud Firestore ว่ามีการทำธุรกรรมแล้ว ในขณะเดียวกัน ผู้ประสานงานและผู้เข้าร่วมทุกคนจะนำการเปลี่ยนแปลงไปใช้กับข้อมูล

เมื่อฐานข้อมูล Cloud Firestore มีขนาดเล็ก ก็อาจมีการแยกเดี่ยวที่เป็นเจ้าของคีย์ทั้งหมดใน Mutations 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 อาจทราบจากสถานะภายในว่ามีข้อมูลเพียงพอที่จะแสดงการอ่าน และแยกก็ดำเนินการดังกล่าว
  • กลุ่มที่ 3 ไม่แน่ใจว่าเห็นข้อมูลล่าสุดหรือไม่ โดยจะส่งข้อความถึงผู้นำเพื่อขอการประทับเวลาของธุรกรรมล่าสุดที่ต้องนำมาใช้เพื่อแสดงการอ่าน เมื่อใช้ธุรกรรมดังกล่าวแล้ว การอ่านจะดําเนินการต่อได้

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

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

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

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

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

ในกรณีเช่นนี้ ไคลเอ็นต์อาจเลือกรับการอ่านที่ล้าสมัยโดยใช้ตัวเลือกการอ่าน 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 ในฐานะเครื่องมือวินิจฉัยที่ออกแบบมาเพื่อวิเคราะห์รูปแบบการใช้งานและแก้ปัญหาฮอตสปอต

ขั้นต่อไปคืออะไร

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