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

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

3. มิเรอร์ข้อมูลใหม่ไปยัง Firestore แบบเรียลไทม์ ใช้ฟังก์ชันระบบคลาวด์เพื่อเขียนข้อมูลใหม่ไปยัง 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 การตรวจสอบสิทธิ์ผู้ใช้จะจัดการโดยการตรวจสอบสิทธิ์สำหรับฐานข้อมูลทั้งสอง คุณจึงไม่จำเป็นต้องเปลี่ยนการใช้งานการตรวจสอบสิทธิ์เมื่อคุณเริ่มต้น ด้วย 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. ไปที่หน้า ส่วน Realtime Database ในคอนโซล Firebase
   2. จากแท็บ Data ให้เลือกโหนดระดับรากของฐานข้อมูลและเลือก ส่งออก 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 เพื่อรักษาความสอดคล้องระหว่างฐานข้อมูล โปรดตรวจสอบว่าคุณไม่ได้เขียนซ้ำกันในฐานข้อมูลทั้ง 2 แหล่ง วนซ้ำ เปลี่ยนฟังก์ชันเพื่อเขียนไปยังฐานข้อมูลเดียว หรือนำฟังก์ชัน อย่างสมบูรณ์และเริ่มเลิกใช้งานการเขียนฟังก์ชันสำหรับ ข้อมูลที่ย้ายในแอปยังคงเชื่อมโยงกับ Realtime Database คุณจะจัดการกับเรื่องนี้อย่างไร แอปของคุณขึ้นอยู่กับความต้องการเฉพาะและผู้ใช้

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