คู่มือนี้ครอบคลุมแนวคิดหลักบางประการในสถาปัตยกรรมข้อมูลและแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดโครงสร้างข้อมูล JSON ใน Firebase Realtime Database
การสร้างฐานข้อมูลที่มีโครงสร้างเหมาะสมนั้นต้องใช้ความรอบคอบไม่น้อย สิ่งสำคัญที่สุดคือคุณต้องวางแผนว่าข้อมูลจะถูกบันทึกและเรียกใช้ในภายหลังอย่างไร เพื่อให้กระบวนการนั้นง่ายที่สุด
โครงสร้างข้อมูลเป็นอย่างไร: เป็นแผนผัง JSON
ข้อมูล Firebase Realtime Database ทั้งหมดจัดเก็บเป็นออบเจ็กต์ JSON คุณสามารถคิดว่าฐานข้อมูลเป็นต้นไม้ JSON ที่โฮสต์บนคลาวด์ ไม่เหมือนกับฐานข้อมูล SQL คือไม่มีตารางหรือระเบียน เมื่อคุณเพิ่มข้อมูลไปยังแผนผัง JSON ข้อมูลนั้นจะกลายเป็นโหนดในโครงสร้าง JSON ที่มีอยู่พร้อมกับคีย์ที่เกี่ยวข้อง คุณสามารถระบุคีย์ของคุณเอง เช่น ID ผู้ใช้หรือชื่อความหมาย หรือสามารถระบุให้คุณโดยใช้ childByAutoId
หากคุณสร้างคีย์ของคุณเอง คีย์เหล่านั้นจะต้องเข้ารหัส UTF-8 มีความยาวได้สูงสุด 768 ไบต์ และไม่สามารถมี . , $ , # , [ , ] , / , หรืออักขระควบคุม ASCII 0-31 หรือ 127 คุณไม่สามารถใช้อักขระควบคุม ASCII ในค่าต่างๆ ได้เช่นกัน
ตัวอย่างเช่น พิจารณาแอปพลิเคชันแชทที่อนุญาตให้ผู้ใช้จัดเก็บโปรไฟล์พื้นฐานและรายชื่อผู้ติดต่อ โปรไฟล์ผู้ใช้ทั่วไปจะอยู่ที่พาธ เช่น /users/$uid ผู้ใช้ alovelace อาจมีรายการฐานข้อมูลที่มีลักษณะดังนี้:
{
"users": {
"alovelace": {
"name": "Ada Lovelace",
"contacts": { "ghopper": true },
},
"ghopper": { ... },
"eclarke": { ... }
}
}
แม้ว่าฐานข้อมูลจะใช้แผนผัง JSON แต่ข้อมูลที่จัดเก็บในฐานข้อมูลสามารถแสดงเป็นประเภทดั้งเดิมบางประเภทที่สอดคล้องกับประเภท JSON ที่มีอยู่เพื่อช่วยให้คุณเขียนโค้ดที่บำรุงรักษาได้มากขึ้น
แนวปฏิบัติที่ดีที่สุดสำหรับโครงสร้างข้อมูล
หลีกเลี่ยงการซ้อนข้อมูล
เนื่องจาก Firebase Realtime Database อนุญาตให้ซ้อนข้อมูลได้ลึกถึง 32 ระดับ คุณอาจถูกล่อลวงให้คิดว่านี่ควรเป็นโครงสร้างเริ่มต้น อย่างไรก็ตาม เมื่อคุณดึงข้อมูลในตำแหน่งที่ตั้งในฐานข้อมูลของคุณ คุณจะดึงโหนดย่อยทั้งหมดด้วย นอกจากนี้ เมื่อคุณให้สิทธิ์การอ่านหรือเขียนแก่ใครบางคนที่โหนดในฐานข้อมูลของคุณ คุณยังให้สิทธิ์เข้าถึงข้อมูลทั้งหมดภายใต้โหนดนั้นด้วย ดังนั้น ในทางปฏิบัติ จึงควรรักษาโครงสร้างข้อมูลให้เรียบที่สุดเท่าที่จะทำได้
สำหรับตัวอย่างว่าทำไมข้อมูลที่ซ้อนกันจึงไม่ดี ให้พิจารณาโครงสร้างที่ซ้อนกันแบบทวีคูณต่อไปนี้:
{
// This is a poorly nested data architecture, because iterating the children
// of the "chats" node to get a list of conversation titles requires
// potentially downloading hundreds of megabytes of messages
"chats": {
"one": {
"title": "Historical Tech Pioneers",
"messages": {
"m1": { "sender": "ghopper", "message": "Relay malfunction found. Cause: moth." },
"m2": { ... },
// a very long list of messages
}
},
"two": { ... }
}
}
ด้วยการออกแบบที่ซ้อนกันนี้ การวนซ้ำข้อมูลจะกลายเป็นปัญหา ตัวอย่างเช่น การแสดงรายการหัวข้อการสนทนาจำเป็นต้องดาวน์โหลดโครงสร้าง chats ทั้งหมด รวมถึงสมาชิกและข้อความทั้งหมดไปยังไคลเอนต์
แผ่โครงสร้างข้อมูล
หากข้อมูลถูกแยกออกเป็นเส้นทางที่แยกจากกัน หรือที่เรียกว่า denormalization จะสามารถดาวน์โหลดได้อย่างมีประสิทธิภาพในการเรียกแยกกันตามความจำเป็น พิจารณาโครงสร้างแบบแบนนี้:
{
// Chats contains only meta info about each conversation
// stored under the chats's unique ID
"chats": {
"one": {
"title": "Historical Tech Pioneers",
"lastMessage": "ghopper: Relay malfunction found. Cause: moth.",
"timestamp": 1459361875666
},
"two": { ... },
"three": { ... }
},
// Conversation members are easily accessible
// and stored by chat conversation ID
"members": {
// we'll talk about indices like this below
"one": {
"ghopper": true,
"alovelace": true,
"eclarke": true
},
"two": { ... },
"three": { ... }
},
// Messages are separate from data we may want to iterate quickly
// but still easily paginated and queried, and organized by chat
// conversation ID
"messages": {
"one": {
"m1": {
"name": "eclarke",
"message": "The relay seems to be malfunctioning.",
"timestamp": 1459361875337
},
"m2": { ... },
"m3": { ... }
},
"two": { ... },
"three": { ... }
}
}
ตอนนี้คุณสามารถวนซ้ำรายการห้องโดยดาวน์โหลดเพียงไม่กี่ไบต์ต่อการสนทนา เรียกข้อมูลเมตาอย่างรวดเร็วสำหรับการแสดงรายการหรือแสดงห้องใน UI สามารถดึงข้อความแยกจากกันและแสดงเมื่อมาถึง ทำให้ UI ยังคงตอบสนองและรวดเร็ว
สร้างข้อมูลที่ปรับขนาดได้
เมื่อสร้างแอป การดาวน์โหลดชุดย่อยของรายการมักจะดีกว่า โดยเฉพาะอย่างยิ่งหากรายการประกอบด้วยเรคคอร์ดนับพันรายการ เมื่อความสัมพันธ์นี้เป็นแบบคงที่และเป็นทิศทางเดียว คุณสามารถซ้อนออบเจกต์ย่อยภายใต้พาเรนต์ได้
ในบางครั้ง ความสัมพันธ์นี้มีไดนามิกมากกว่า หรืออาจจำเป็นต้องทำให้ข้อมูลนี้เป็นปกติ หลายครั้งคุณสามารถทำให้ข้อมูลไม่ปกติได้โดยใช้คิวรีเพื่อดึงชุดย่อยของข้อมูล ดังที่กล่าวไว้ใน ดึงข้อมูล
แต่สิ่งนี้อาจไม่เพียงพอ ตัวอย่างเช่น พิจารณาความสัมพันธ์แบบสองทางระหว่างผู้ใช้และกลุ่ม ผู้ใช้สามารถอยู่ในกลุ่ม และกลุ่มประกอบด้วยรายชื่อผู้ใช้ เมื่อถึงเวลาต้องตัดสินใจว่าผู้ใช้อยู่ในกลุ่มใด สิ่งต่างๆ จะซับซ้อนขึ้น
สิ่งที่จำเป็นคือวิธีที่สวยงามในการแสดงรายการกลุ่มที่ผู้ใช้เป็นสมาชิก และดึงเฉพาะข้อมูลสำหรับกลุ่มเหล่านั้น ดัชนี ของกลุ่มสามารถช่วยได้มากที่นี่:
// An index to track Ada's memberships
{
"users": {
"alovelace": {
"name": "Ada Lovelace",
// Index Ada's groups in her profile
"groups": {
// the value here doesn't matter, just that the key exists
"techpioneers": true,
"womentechmakers": true
}
},
...
},
"groups": {
"techpioneers": {
"name": "Historical Tech Pioneers",
"members": {
"alovelace": true,
"ghopper": true,
"eclarke": true
}
},
...
}
}
คุณอาจสังเกตเห็นว่าสิ่งนี้ทำซ้ำข้อมูลบางส่วนโดยการจัดเก็บความสัมพันธ์ภายใต้ทั้งบันทึกของ Ada และภายใต้กลุ่ม ตอนนี้ alovelace ได้รับการจัดทำดัชนีภายใต้กลุ่ม และ techpioneers อยู่ในโปรไฟล์ของ Ada ดังนั้นหากต้องการลบ Ada ออกจากกลุ่ม จะต้องอัปเดตในสองแห่ง
นี่เป็นความซ้ำซ้อนที่จำเป็นสำหรับความสัมพันธ์แบบสองทาง ช่วยให้คุณสามารถดึงข้อมูลการเป็นสมาชิกของ Ada ได้อย่างรวดเร็วและมีประสิทธิภาพ แม้ว่ารายชื่อผู้ใช้หรือกลุ่มจะมีขนาดเป็นล้าน หรือเมื่อกฎความปลอดภัยของฐานข้อมูลเรียลไทม์ป้องกันการเข้าถึงเรคคอร์ดบางส่วน
วิธีการนี้เป็นการสลับข้อมูลโดยระบุ ID เป็นคีย์และตั้งค่าเป็น True ทำให้การตรวจสอบคีย์ทำได้ง่ายเพียงแค่อ่าน /users/$uid/groups/$group_id และตรวจสอบว่าเป็น null หรือไม่ ดัชนีเร็วกว่าและมีประสิทธิภาพมากกว่าการสืบค้นหรือสแกนข้อมูล