ใช้ Cloud Firestore กับฐานข้อมูลเรียลไทม์ของ Firebase

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

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

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

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

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

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

  3. มิเรอร์ข้อมูลใหม่ไปยัง Firestore แบบเรียลไทม์ ใช้ Cloud Functions เพื่อเขียนข้อมูลใหม่ลงในฐานข้อมูล Cloud Firestore ใหม่เมื่อมีการเพิ่มข้อมูลลงใน Realtime Database

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

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

แมปข้อมูล

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

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

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

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

แนวทางปฏิบัติแนะนำในการใช้งาน

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

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

// /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 ...]
}

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

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

{
   cities: {
    // ...
   },

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

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

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

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

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

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

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

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

ย้ายข้อมูลย้อนหลังไปยัง Cloud Firestore

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

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

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

  1. ส่งออกข้อมูลจาก Realtime Database หรือใช้ข้อมูลสำรองล่าสุด
    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

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

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

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

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

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

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