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

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

ส่วนหน้าของ Google (GFE)

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

บริการ Cloud Firestore

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

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

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

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

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

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

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

สิ่งสำคัญที่ควรทราบคือฐานข้อมูลจะมีการจำลองซ้ำโดยอัตโนมัติและพร้อมกันเสมอ การแยกข้อมูลมีตัวจำลองในโซนต่างๆ กันเพื่อให้ใช้งานต่อได้แม้ว่าจะเข้าถึงโซนไม่ได้ก็ตาม การจำลองที่เหมือนกันกับสำเนาที่แตกต่างกันของการแยกได้รับการจัดการโดยอัลกอริทึม Paxos เพื่อหาฉันทามติ ตัวจำลองของการแยกแต่ละครั้งได้รับเลือกให้ทำหน้าที่เป็นผู้นำ 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 (แอตทริบิวต์ของ 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 จะค้นหาการแยกที่เป็นเจ้าของคีย์ของแถวที่จะเปลี่ยน ลองพิจารณากรณีที่ Split 3 ให้บริการ M1 และ Split 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 แสดงผลข้อมูลเวอร์ชันล่าสุดซึ่งแสดงการเขียนทั้งหมดที่ดำเนินการไปแล้วจนกระทั่งการอ่าน

การอ่านแบบ Single Split

ไคลเอ็นต์พื้นที่เก็บข้อมูลใน Cloud Firestore จะค้นหาการแยกที่เป็นเจ้าของคีย์ของแถวที่จะอ่าน สมมติว่าโมเดลจำเป็นต้องอ่านจาก Split 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 จะแบ่งช่วงคีย์ได้จนกว่าจะแสดงเอกสารเดียวโดยใช้ชุดเซิร์ฟเวอร์พื้นที่เก็บข้อมูลจำลองโดยเฉพาะ ด้วยเหตุนี้ การดำเนินการพร้อมกันที่มีปริมาณมากและต่อเนื่องในเอกสาร 1 ฉบับจึงอาจทำให้เกิดฮอตสปอตในเอกสารนั้น หากพบเวลาในการตอบสนองสูงอย่างต่อเนื่องในเอกสารเดียว คุณควรพิจารณาแก้ไขโมเดลข้อมูลเพื่อแบ่งหรือทำสำเนาข้อมูลในเอกสารหลายฉบับ

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

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

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

การแก้ปัญหา

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

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