ใช้ Cloud Firestore กับฐานข้อมูล Firebase Realtime

คุณสามารถใช้ทั้ง Firebase Realtime Database และ Cloud Firestore ในแอปของคุณ และใช้ประโยชน์จากโซลูชันฐานข้อมูลแต่ละรายการเพื่อให้เหมาะกับความต้องการของคุณ ตัวอย่างเช่น คุณอาจต้องการใช้ประโยชน์จากการรองรับฐานข้อมูลเรียลไทม์เพื่อการแสดงตน ดังที่ระบุไว้ใน Build Presence ใน Cloud Firestore

เรียนรู้เพิ่มเติมเกี่ยวกับ ความแตกต่างระหว่างฐานข้อมูล

การย้ายข้อมูลไปยัง Cloud Firestore

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

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

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

3. มิเรอร์ข้อมูลใหม่ไปยัง Firestore แบบเรียลไทม์ ใช้ฟังก์ชันคลาวด์เพื่อเขียนข้อมูลใหม่ไปยังฐานข้อมูล Cloud Firestore ใหม่ของคุณเมื่อมีการเพิ่มลงในฐานข้อมูลเรียลไทม์

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

ตรวจสอบให้แน่ใจว่าคุณเป็นผู้รับผิดชอบ ค่าใช้จ่ายการเรียกเก็บเงิน สำหรับทั้ง Realtime Database และ Cloud Firestore

จัดทำแผนที่ข้อมูลของคุณ

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

ความแตกต่างที่สำคัญที่ต้องพิจารณา

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

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

แนวทางปฏิบัติที่ดีที่สุดในการดำเนินการ

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

ลองใช้แอปแนะนำเมืองที่ช่วยให้ผู้ใช้ค้นหาสถานที่สำคัญที่โดดเด่นในเมืองต่างๆ ทั่วโลก เนื่องจาก Realtime Database ขาดการอ่านแบบตื้น คุณอาจต้องจัดโครงสร้างข้อมูลในโหนดระดับบนสุดสองโหนด ดังนี้:

// /cities/$CITY_KEY
{
  name: "New York",
  population: 8000000,
  capital: False
}

// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
  name: "Empire State Building",
  category: "Architecture"
}

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

// /cities/$CITY_ID
{
  name: "New York",
  population: 8000000,
  capital: False,
  landmarks: [... subcollection ...]
}

เอกสารมีขนาดสูงสุด 1MB ซึ่งเป็นอีกเหตุผลหนึ่งที่ต้องจัดเก็บจุดสังเกตเป็นคอลเลกชันย่อย ทำให้เอกสารแต่ละเมืองมีขนาดเล็ก แทนที่จะทำให้เอกสารมีรายการที่ซ้อนกัน

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

{
   cities: {
    // ...
   },

   capital-cities: {
     // ...
   }
}

ใน Cloud Firestore คุณสามารถแสดงรายการเมืองหลวงตามลำดับประชากรเป็นคำค้นหาเดียวได้:

db.collection('cities')
    .where('capital', '==', true)
    .orderBy('population')

อ่านเพิ่มเติมเกี่ยวกับ โมเดลข้อมูล Cloud Firestore และดู โซลูชัน ของเราเพื่อดูแนวคิดเพิ่มเติมเกี่ยวกับวิธีจัดโครงสร้างฐานข้อมูล Cloud Firestore ของคุณ

รักษาความปลอดภัยข้อมูลของคุณ

ไม่ว่าคุณจะใช้ กฎการรักษาความปลอดภัยของ Cloud Firestore สำหรับ Android, Apple หรือเว็บไคลเอ็นต์ หรือ Identity Access Management (IAM) สำหรับเซิร์ฟเวอร์ โปรดตรวจสอบให้แน่ใจว่าคุณได้รักษาความปลอดภัยข้อมูลของคุณใน Cloud Firestore รวมถึง Realtime Database การตรวจสอบสิทธิ์ผู้ใช้จะได้รับการจัดการโดยการตรวจสอบสิทธิ์สำหรับทั้งสองฐานข้อมูล ดังนั้นคุณจึงไม่จำเป็นต้องเปลี่ยนการใช้งานการตรวจสอบสิทธิ์เมื่อคุณเริ่มใช้ Cloud Firestore

ความแตกต่างที่สำคัญที่ต้องพิจารณา

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

ย้ายข้อมูลประวัติไปยัง Cloud Firestore

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

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

หากต้องการย้ายข้อมูลประวัติไปยัง Cloud Firestore ให้ทำตามขั้นตอนเหล่านี้:

1. ส่งออกข้อมูลของคุณจากฐานข้อมูลเรียลไทม์หรือ ใช้การสำรองข้อมูลล่าสุด
   1. ไปที่ ส่วนฐานข้อมูลเรียลไทม์ ในคอนโซล Firebase
   2. จากแท็บ ข้อมูล เลือกโหนดระดับรากของฐานข้อมูลของคุณ และเลือก ส่งออก JSON จากเมนู

2. สร้างฐานข้อมูลใหม่ใน Cloud Firestore และ เพิ่มข้อมูลของคุณ

   พิจารณากลยุทธ์ต่อไปนี้เมื่อคุณย้ายข้อมูลบางส่วนไปยัง Cloud Firestore:

   • เขียนสคริปต์แบบกำหนดเองที่พอร์ตข้อมูลของคุณให้กับคุณ แม้ว่าเราจะไม่สามารถเสนอเทมเพลตสำหรับสคริปต์นี้ได้ เนื่องจากทุกฐานข้อมูลจะมีความต้องการเฉพาะ ผู้เชี่ยวชาญ Cloud Firestore บน ช่องทาง Slack ของเราหรือบน Stack Overflow สามารถตรวจสอบสคริปต์ของคุณหรือเสนอคำแนะนำสำหรับสถานการณ์เฉพาะของคุณได้
   • ใช้เซิร์ฟเวอร์ SDK (Node.js, Java, Python หรือ Go) เพื่อเขียนข้อมูลโดยตรงไปยัง Cloud Firestore สำหรับคำแนะนำในการตั้งค่าเซิร์ฟเวอร์ SDK โปรดดู เริ่มต้นใช้งาน
   • หากต้องการเร่งการย้ายข้อมูลขนาดใหญ่ ให้ใช้ การเขียนเป็นชุด และส่งการดำเนินการได้มากถึง 500 รายการในคำขอเครือข่ายเดียว
   • หากต้องการอยู่ภายใต้ ขีดจำกัดอัตราของ Cloud Firestore ให้จำกัดการดำเนินการไว้ที่ 500 การเขียน/วินาทีสำหรับแต่ละคอลเลกชัน

เพิ่มข้อมูลใหม่ลงใน Cloud Firestore

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

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

ทำให้ Cloud Firestore เป็นฐานข้อมูลหลักสำหรับข้อมูลที่ย้าย

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

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

2. ตรวจสอบว่าข้อมูลของคุณมีความปลอดภัยอย่างเหมาะสม ตรวจสอบกฎความปลอดภัยของ Cloud Firestore หรือการตั้งค่า IAM