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

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

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

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

• SDK บนอุปกรณ์เคลื่อนที่และเว็บใช้ Cloud Firestore Security Rules ส่วน SDK ของเซิร์ฟเวอร์ใช้ Identity Access Management (IAM) เพื่อรักษาความปลอดภัยของข้อมูล
• Cloud Firestore Security Rules จะไม่ทํางานแบบ Cascade เว้นแต่คุณจะใช้ไวลด์การ์ด เอกสารและคอลเล็กชันจะไม่รับค่ากฎจากส่วนกลาง
• คุณไม่จําเป็นต้องตรวจสอบข้อมูลแยกต่างหากอีกต่อไป (เหมือนที่เคยทําใน 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. จากแท็บข้อมูล ให้เลือกโหนดระดับรูทของฐานข้อมูล แล้วเลือกส่งออก JSON จากเมนู

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

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

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