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

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

<span class=การแยกฐานข้อมูล 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 มีขนาดเล็ก อาจมีกรณีที่การแยกกลุ่มเดียวเป็นเจ้าของคีย์ทั้งหมดในการกลายพันธุ์ M1-M5 ในกรณีเช่นนี้ มีผู้เข้าร่วมในธุรกรรมเพียงรายเดียว และไม่จำเป็นต้องใช้การคอมมิตแบบ 2 เฟสที่กล่าวถึงก่อนหน้านี้ จึงทําให้การเขียนเร็วขึ้น

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

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

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

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

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

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

  1. การสแกนช่วงเดียวในตารางดัชนี
  2. การค้นหาจุดในตาราง Documents ตามผลการสแกนก่อนหน้านี้
การค้นหาบางรายการอาจต้องมีการประมวลผลน้อยลงหรือมากขึ้น (เช่น การค้นหา IN) ใน Cloud Firestore

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

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

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

ขั้นตอนถัดไป