คุณสามารถปรับปรุงประสิทธิภาพ Firebase Realtime Database ในแอปได้หลายวิธี หากต้องการทราบว่าคุณสามารถทำอะไรได้บ้างเพื่อเพิ่มประสิทธิภาพ Realtime Database ให้รวบรวมข้อมูลผ่านเครื่องมือตรวจสอบ Realtime Database ต่างๆ จากนั้นทำการเปลี่ยนแปลงในแอปหรือ Realtime Database ใช้ตามความเหมาะสม
ตรวจสอบประสิทธิภาพของ Realtime Database
คุณสามารถรวบรวมข้อมูลเกี่ยวกับประสิทธิภาพของ Realtime Database ผ่านเครื่องมือต่างๆ ได้ โดยขึ้นอยู่กับระดับความละเอียดที่คุณต้องการ ดังนี้
- ภาพรวมระดับสูง: ใช้เครื่องมือวิเคราะห์เพื่อดูรายการคำค้นหาที่ไม่ได้จัดทำดัชนีและภาพรวมแบบเรียลไทม์ของการดำเนินการอ่าน/เขียน
- ค่าประมาณการใช้งานที่เรียกเก็บเงิน: ใช้เมตริกการใช้งานที่มีอยู่ในคอนโซล Firebase เพื่อดูการใช้งานที่เรียกเก็บเงินและเมตริกประสิทธิภาพระดับสูง
- รายละเอียดแบบเจาะลึก: ใช้ Cloud Monitoring เพื่อดูประสิทธิภาพของฐานข้อมูลเมื่อเวลาผ่านไปอย่างละเอียดยิ่งขึ้น
ปรับปรุงประสิทธิภาพตามเมตริก
เมื่อรวบรวมข้อมูลแล้ว ให้สำรวจแนวทางปฏิบัติแนะนำและกลยุทธ์ต่อไปนี้ตามด้านประสิทธิภาพที่ต้องการปรับปรุง
| กลยุทธ์การปรับปรุงประสิทธิภาพโดยสรุป | ||
|---|---|---|
| เมตริก | คำอธิบาย | แนวทางปฏิบัติแนะนำ |
| โหลด/การใช้งาน | เพิ่มประสิทธิภาพปริมาณความจุของฐานข้อมูลที่ใช้ในการประมวลผลคำขอ ณ เวลาใดก็ตาม (แสดงในเมตริก **Load** หรือ **io/database_load**) |
เพิ่มประสิทธิภาพโครงสร้างข้อมูล ชาร์ดข้อมูลในฐานข้อมูล ปรับปรุงประสิทธิภาพ Listener จำกัดการดาวน์โหลดด้วยกฎที่อิงตามการค้นหา เพิ่มประสิทธิภาพการเชื่อมต่อ |
| การเชื่อมต่อที่ใช้งานอยู่ | ปรับสมดุลจำนวนการเชื่อมต่อที่ใช้งานอยู่พร้อมกันกับฐานข้อมูลเพื่อให้อยู่ภายใต้ขีดจำกัดการเชื่อมต่อ 200,000 รายการ |
ชาร์ดข้อมูลในฐานข้อมูล ลดการเชื่อมต่อใหม่ |
| แบนด์วิดท์ขาออก | หากการดาวน์โหลดจากฐานข้อมูลดูเหมือนจะสูงกว่าที่คุณต้องการ คุณสามารถปรับปรุงประสิทธิภาพของการดำเนินการอ่านและลดภาระงานในการเข้ารหัสได้ |
เพิ่มประสิทธิภาพการเชื่อมต่อ เพิ่มประสิทธิภาพโครงสร้างข้อมูล จำกัดการดาวน์โหลดด้วยกฎที่อิงตามการค้นหา ใช้เซสชัน SSL ซ้ำ เพิ่มประสิทธิภาพ Listener จำกัดการเข้าถึงข้อมูล |
| พื้นที่เก็บข้อมูล | ตรวจสอบว่าคุณไม่ได้จัดเก็บข้อมูลที่ไม่ได้ใช้ หรือปรับสมดุลข้อมูลที่จัดเก็บไว้ในฐานข้อมูลอื่นๆ และ/หรือผลิตภัณฑ์ Firebase เพื่อให้อยู่ภายใต้โควต้า |
ล้างข้อมูลที่ไม่ได้ใช้ เพิ่มประสิทธิภาพโครงสร้างข้อมูล ชาร์ดข้อมูลในฐานข้อมูลต่างๆ ใช้ Cloud Storage for Firebase |
เพิ่มประสิทธิภาพการเชื่อมต่อ
คำขอ RESTful เช่น GET และ PUT ยังคงต้องใช้การเชื่อมต่อ แม้ว่าการเชื่อมต่อนั้นจะมีอายุสั้นก็ตาม การเชื่อมต่อสั้นๆ ที่เกิดขึ้นบ่อยครั้งเหล่านี้อาจทำให้ต้นทุนการเชื่อมต่อ ภาระงานของฐานข้อมูล และแบนด์วิดท์ขาออกเพิ่มขึ้นอย่างมากเมื่อเทียบกับการเชื่อมต่อที่ใช้งานอยู่แบบเรียลไทม์กับฐานข้อมูล
ใช้ SDK แบบเนทีฟสำหรับแพลตฟอร์มของแอปแทน REST API ทุกครั้งที่ทำได้ SDK จะรักษาการเชื่อมต่อแบบเปิดไว้ ซึ่งช่วยลดค่าใช้จ่ายในการเข้ารหัส SSL และภาระงานของฐานข้อมูลที่อาจเพิ่มขึ้นเมื่อใช้ REST API
หากคุณใช้ REST API ให้พิจารณาใช้ HTTP Keep-Alive เพื่อรักษาการเชื่อมต่อแบบเปิดหรือใช้เหตุการณ์ที่เซิร์ฟเวอร์ส่ง ซึ่งจะช่วยลดค่าใช้จ่ายจาก SSL Handshake ได้
ชาร์ดข้อมูลในฐานข้อมูลหลายรายการ
การแยกข้อมูลของคุณในอินสแตนซ์ Realtime Database หลายรายการ หรือที่เรียกว่าการชาร์ดดิ้งฐานข้อมูล มีประโยชน์ 3 ประการดังนี้
- เพิ่มจำนวนการเชื่อมต่อที่ใช้งานอยู่พร้อมกันทั้งหมดที่อนุญาตในแอปโดยแยกการเชื่อมต่อเหล่านั้นออกเป็นอินสแตนซ์ฐานข้อมูลต่างๆ
- กระจายภาระงานในอินสแตนซ์ฐานข้อมูล
- หากคุณมีกลุ่มผู้ใช้อิสระที่ต้องการเข้าถึงเฉพาะชุดข้อมูลที่แยกกัน ให้ใช้อินสแตนซ์ฐานข้อมูลที่แตกต่างกันเพื่อให้ได้อัตราการส่งข้อมูลที่สูงขึ้นและเวลาในการตอบสนองที่ต่ำลง
หากใช้แพ็กเกจราคา Blaze คุณจะสร้างอินสแตนซ์ฐานข้อมูลหลายรายการภายในโปรเจ็กต์ Firebase เดียวกันได้ โดยใช้วิธีการตรวจสอบสิทธิ์ผู้ใช้ทั่วไปในอินสแตนซ์ฐานข้อมูลต่างๆ
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีและเวลาที่ควรชาร์ดข้อมูล
สร้างโครงสร้างข้อมูลที่มีประสิทธิภาพ
เนื่องจาก Realtime Database ดึงข้อมูลจากโหนดระดับย่อยของเส้นทางและเส้นทางด้วย จึงควรทำให้โครงสร้างข้อมูลแบนราบที่สุดเท่าที่จะเป็นไปได้ วิธีนี้ช่วยให้คุณเลือกดึงข้อมูลที่ต้องการได้โดยไม่ต้องดาวน์โหลดข้อมูลที่ไม่จำเป็นไปยังไคลเอ็นต์ด้วย
โดยเฉพาะอย่างยิ่ง ให้พิจารณาการเขียนและการลบเมื่อคุณจัดโครงสร้างข้อมูล ตัวอย่างเช่น เส้นทางที่มีโหนดปลายทางหลายพันโหนดอาจมีค่าใช้จ่ายสูงในการลบ การแยกออกเป็นเส้นทางที่มีแผนผังย่อยหลายรายการและมีโหนดปลายทางน้อยลงต่อโหนดจะช่วยให้ลบได้เร็วขึ้น
นอกจากนี้ การเขียนแต่ละครั้งอาจใช้การใช้งานฐานข้อมูลทั้งหมด 0.1%
จัดโครงสร้างข้อมูลในลักษณะที่ช่วยให้คุณสามารถเขียนเป็นกลุ่มในการดำเนินการเดียวเป็นการอัปเดตหลายเส้นทางผ่านเมธอด update() ใน SDK หรือคำขอ RESTful PATCH
หากต้องการเพิ่มประสิทธิภาพโครงสร้างข้อมูลและปรับปรุงประสิทธิภาพ ให้ทำตามแนวทางปฏิบัติแนะนำสำหรับโครงสร้างข้อมูล
ป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต
ป้องกันการดำเนินการที่ไม่ได้รับอนุญาตในฐานข้อมูลด้วย Realtime Database Security Rules ตัวอย่างเช่น การใช้กฎจะช่วยหลีกเลี่ยงสถานการณ์ที่ผู้ใช้ที่เป็นอันตรายดาวน์โหลดฐานข้อมูลทั้งหมดของคุณซ้ำๆ
ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้กฎฐานข้อมูลเรียลไทม์ของ Firebase
ใช้กฎที่อิงตามการค้นหาเพื่อจำกัดการดาวน์โหลด
Realtime Database Security Rules จำกัดการเข้าถึงข้อมูลในฐานข้อมูล แต่ยังทำหน้าที่เป็นขีดจำกัดของข้อมูลที่แสดงผลผ่านการดำเนินการอ่านได้ด้วย เมื่อคุณใช้กฎที่อิงตามการค้นหา ซึ่งกำหนดโดยนิพจน์ query. เช่น query.limitToFirst การค้นหาจะดึงข้อมูลที่ถูกจำกัดโดยกฎเท่านั้น
ตัวอย่างเช่น กฎต่อไปนี้จำกัดสิทธิ์การอ่านไว้ที่ผลลัพธ์ 1,000 รายการแรกของคำค้นหาเท่านั้น โดยเรียงตามลำดับความสำคัญ
messages: {
".read": "query.orderByKey &&
query.limitToFirst <= 1000"
}
// Example query:
db.ref("messages").limitToFirst(1000)
.orderByKey("value")
เรียนรู้เพิ่มเติมเกี่ยวกับ Realtime Database Security Rules
การค้นหาดัชนี
การจัดทำดัชนีข้อมูลจะช่วยลดแบนด์วิดท์ทั้งหมดที่คุณใช้สำหรับการค้นหาแต่ละครั้งที่แอปเรียกใช้
ใช้เซสชัน SSL ซ้ำ
ลดค่าใช้จ่ายในการเข้ารหัส SSL สำหรับการเชื่อมต่อที่กลับมาทำงานอีกครั้งโดยการออกตั๋วเซสชัน TLS ซึ่งจะเป็นประโยชน์อย่างยิ่งหากคุณต้องการการเชื่อมต่อกับฐานข้อมูลที่ปลอดภัยและบ่อยครั้ง
ปรับปรุงประสิทธิภาพของผู้ฟัง
วาง Listener ไว้ที่ปลายเส้นทางให้มากที่สุดเพื่อจำกัดปริมาณข้อมูลที่ซิงค์ Listener ควรอยู่ใกล้กับข้อมูลที่คุณต้องการให้ Listener ได้รับ อย่าฟังที่รูทของฐานข้อมูล เนื่องจากจะส่งผลให้มีการดาวน์โหลดฐานข้อมูลทั้งหมด
เพิ่มการค้นหาเพื่อจำกัดข้อมูลที่การดำเนินการฟังแสดงผลและใช้ Listener ที่ดาวน์โหลดเฉพาะการอัปเดตข้อมูล เช่น on() แทน once() สงวน .once() ไว้สำหรับการดำเนินการที่ไม่จำเป็นต้องอัปเดตข้อมูลจริงๆ
นอกจากนี้ ให้จัดเรียงการค้นหาโดยใช้ orderByKey() ทุกครั้งที่ทำได้เพื่อให้ได้ประสิทธิภาพสูงสุด การจัดเรียงด้วย orderByChild() อาจช้าลง 6-8 เท่า และการจัดเรียงด้วย orderByValue() อาจช้ามากสำหรับชุดข้อมูลขนาดใหญ่ เนื่องจากต้องอ่านตำแหน่งทั้งหมดจากเลเยอร์ความคงอยู่
อย่าลืมเพิ่ม Listener แบบไดนามิกด้วย และนำออกเมื่อไม่จำเป็นต้องใช้อีกต่อไป
ล้างข้อมูลที่ไม่ได้ใช้
นำข้อมูลที่ไม่ได้ใช้หรือข้อมูลที่ซ้ำกันในฐานข้อมูลออกเป็นระยะๆ คุณสามารถเรียกใช้การสำรองข้อมูลเพื่อตรวจสอบข้อมูลด้วยตนเองหรือสำรองข้อมูลเป็นระยะๆ ไปยังที่เก็บข้อมูล Google Cloud Storage นอกจากนี้ ให้พิจารณาโฮสต์ข้อมูลที่จัดเก็บไว้ผ่าน Cloud Storage for Firebase ด้วย
ส่งโค้ดที่ปรับขนาดได้ซึ่งคุณอัปเดตได้
แอปที่ติดตั้งมาในอุปกรณ์ IoT ควรมีโค้ดที่ปรับขนาดได้ซึ่งคุณสามารถอัปเดตได้ง่าย อย่าลืมทดสอบ Use Case อย่างละเอียด โดยพิจารณาสถานการณ์ที่คุณอาจเพิ่มฐานผู้ใช้แบบทวีคูณ และสร้างความสามารถในการติดตั้งใช้งานการอัปเดตโค้ด พิจารณาการเปลี่ยนแปลงครั้งใหญ่ที่คุณอาจต้องทำในอนาคตอย่างรอบคอบ เช่น หากคุณตัดสินใจที่จะชาร์ดข้อมูล