มีวิธีต่างๆ ในการปรับปรุงFirebase Realtime Database ประสิทธิภาพในแอปของคุณ หากต้องการทราบว่าคุณทำอะไรได้บ้างเพื่อเพิ่มประสิทธิภาพRealtime Database ให้รวบรวมข้อมูลผ่านRealtime Database เครื่องมือตรวจสอบต่างๆ จากนั้นทำการเปลี่ยนแปลงในแอปหรือRealtime Databaseใช้ตามนั้น
ตรวจสอบRealtime Databaseประสิทธิภาพ
คุณสามารถรวบรวมข้อมูลเกี่ยวกับRealtime Databaseประสิทธิภาพผ่านเครื่องมือต่างๆ ได้ 2-3 อย่าง ขึ้นอยู่กับระดับความละเอียดที่คุณต้องการ
- ภาพรวมระดับสูง: ใช้เครื่องมือโปรไฟล์ เพื่อดูรายการคำค้นหาที่ไม่ได้จัดทำดัชนีและภาพรวมแบบเรียลไทม์ของการอ่าน/เขียน
- ค่าประมาณการใช้งานที่เรียกเก็บเงิน: ใช้เมตริกการใช้งาน ที่มีอยู่ใน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 ได้
แบ่งข้อมูลในฐานข้อมูลหลายรายการ
การแยกข้อมูลในRealtime Database หลายอินสแตนซ์ หรือที่เรียกว่าการแบ่งฐานข้อมูลออกเป็นส่วนๆ มีประโยชน์ 3 ประการดังนี้
- เพิ่มการเชื่อมต่อที่ใช้งานอยู่พร้อมกันทั้งหมดที่อนุญาตในแอปโดย แยกการเชื่อมต่อเหล่านั้นไปยังอินสแตนซ์ฐานข้อมูล
- กระจายภาระงานในอินสแตนซ์ฐานข้อมูล
- หากคุณมีกลุ่มผู้ใช้ที่ไม่ขึ้นต่อกันซึ่งต้องการเข้าถึงชุดข้อมูลที่แยกกันเท่านั้น ให้ใช้อินสแตนซ์ฐานข้อมูลที่แตกต่างกันเพื่อให้มีปริมาณงานสูงขึ้นและเวลาในการตอบสนองต่ำลง
หากใช้แพ็กเกจราคา Blaze คุณจะสร้างอินสแตนซ์ฐานข้อมูลหลายรายการภายในโปรเจ็กต์ Firebase เดียวกันได้ โดยใช้วิธีการตรวจสอบสิทธิ์ผู้ใช้ทั่วไปในอินสแตนซ์ฐานข้อมูล
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีและเวลาที่ควรแบ่งข้อมูล
สร้างโครงสร้างข้อมูลที่มีประสิทธิภาพ
เนื่องจาก Realtime Database จะดึงข้อมูลจากโหนดลูกของเส้นทาง รวมถึงเส้นทางด้วย จึงควรเก็บโครงสร้างข้อมูลให้เรียบง่ายที่สุด วิธีนี้จะช่วยให้คุณดึงข้อมูลที่ต้องการได้โดยไม่ต้องดาวน์โหลดข้อมูลที่ไม่จำเป็นไปยังไคลเอ็นต์ด้วย
โดยเฉพาะอย่างยิ่ง ให้พิจารณาการเขียนและการลบเมื่อจัดโครงสร้างข้อมูล เช่น เส้นทางที่มีใบไม้หลายพันใบอาจมีค่าใช้จ่ายสูงในการลบ การแยกออกเป็นเส้นทางที่มีหลายซับทรีและมีลีฟโหนดน้อยลง จะช่วยให้การลบเร็วขึ้น
นอกจากนี้ การเขียนแต่ละครั้งอาจใช้การใช้ฐานข้อมูลทั้งหมด 0.1%
จัดโครงสร้างข้อมูลในลักษณะที่ช่วยให้คุณเขียนแบบเป็นกลุ่มลงในการดำเนินการเดียวได้เป็นการอัปเดตแบบหลายเส้นทางผ่านupdate()เมธอดใน SDK หรือคำขอ RESTful PATCH
ทําตามแนวทางปฏิบัติแนะนําสําหรับโครงสร้างข้อมูลเพื่อเพิ่มประสิทธิภาพและปรับโครงสร้างข้อมูล
ป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต
ป้องกันการดำเนินการที่ไม่ได้รับอนุญาตในฐานข้อมูลด้วย Realtime Database Security Rules เช่น การใช้กฎจะช่วยหลีกเลี่ยงสถานการณ์ที่ผู้ใช้ที่เป็นอันตรายดาวน์โหลดทั้งฐานข้อมูลของคุณซ้ำๆ
ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้กฎของ Firebase Realtime Database
ใช้กฎตามคำค้นหาเพื่อจำกัดการดาวน์โหลด
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 ซึ่งจะเป็นประโยชน์อย่างยิ่งหากคุณต้องการการเชื่อมต่อที่ปลอดภัยกับฐานข้อมูลบ่อยๆ
ปรับปรุงประสิทธิภาพของผู้ฟัง
วางผู้ฟังไว้ในเส้นทางให้ไกลที่สุดเท่าที่จะทำได้เพื่อจำกัดปริมาณข้อมูลที่ซิงค์ ผู้ฟังควรอยู่ใกล้กับข้อมูลที่คุณต้องการให้ผู้ฟังได้รับ อย่าฟังที่รูทของฐานข้อมูล เนื่องจากจะทำให้ดาวน์โหลดฐานข้อมูลทั้งหมด
เพิ่มการค้นหาเพื่อจำกัดข้อมูลที่การดำเนินการฟังจะแสดงผล และใช้โปรแกรมฟังที่ดาวน์โหลดเฉพาะการอัปเดตข้อมูล เช่น on() แทน once() สงวน .once() ไว้สำหรับการดำเนินการที่ไม่จำเป็นต้องอัปเดตข้อมูลจริงๆ
นอกจากนี้ ให้จัดเรียงการค้นหาโดยใช้ orderByKey() เมื่อเป็นไปได้เพื่อ
ประสิทธิภาพที่ดีที่สุด การจัดเรียงด้วย orderByChild() อาจช้าลง 6-8 เท่า และ
การจัดเรียงด้วย orderByValue() อาจช้ามากสำหรับชุดข้อมูลขนาดใหญ่ เนื่องจากต้อง
อ่านทั้งตำแหน่งจากเลเยอร์ความคงทน
อย่าลืมเพิ่ม Listener แบบไดนามิกและนำออกเมื่อไม่จำเป็นอีกต่อไป
ล้างข้อมูลที่ไม่ได้ใช้
นำข้อมูลที่ไม่ได้ใช้หรือข้อมูลที่ซ้ำกันในฐานข้อมูลออกเป็นระยะๆ คุณสามารถ เรียกใช้การสำรองข้อมูลเพื่อตรวจสอบข้อมูลด้วยตนเอง หรือ สำรองข้อมูลเป็นระยะๆ ไปยังที่เก็บข้อมูล Google Cloud Storage นอกจากนี้ โปรดพิจารณาโฮสต์ข้อมูลที่จัดเก็บผ่าน Cloud Storage for Firebase
ส่งโค้ดที่ปรับขนาดได้ซึ่งคุณอัปเดตได้
แอปที่สร้างไว้ในอุปกรณ์ IoT ควรมีโค้ดที่ปรับขนาดได้ซึ่งคุณ อัปเดตได้อย่างง่ายดาย อย่าลืมทดสอบกรณีการใช้งานอย่างละเอียด พิจารณาสถานการณ์ ที่คุณอาจขยายฐานผู้ใช้แบบทวีคูณ และสร้างความสามารถ ในการติดตั้งใช้งานการอัปเดตโค้ด พิจารณาการเปลี่ยนแปลงที่สำคัญที่คุณอาจต้องทำในอนาคตอย่างรอบคอบ เช่น หากคุณตัดสินใจที่จะแยกข้อมูล