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

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

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

บริการคลาวด์ไฟร์สโตร์

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

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

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

ช่วงสำคัญและการแยก

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

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

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

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

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

เค้าโครงข้อมูล

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การอ่านที่แข็งแกร่ง

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

อ่านแยกเดี่ยว

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

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

• คำขออ่านไปที่แบบจำลองผู้นำ (โซน A)
  • เนื่องจากผู้นำมีความทันสมัยอยู่เสมอ การอ่านจึงสามารถดำเนินการได้โดยตรง
• คำขออ่านไปที่แบบจำลองที่ไม่ใช่ผู้นำ (เช่น โซน B)
  • Split 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% ทุกๆ ห้านาที กระบวนการนี้เรียกว่ากฎ 500/50/5 และกำหนดตำแหน่งฐานข้อมูลให้ปรับขนาดได้อย่างเหมาะสมที่สุดเพื่อให้เหมาะกับปริมาณงานของคุณ

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

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

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

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

การแก้ไขปัญหา

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

อะไรต่อไป

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