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

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

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