ทำความเข้าใจการเรียกเก็บเงินใน Realtime Database

Firebase จะเรียกเก็บเงินตามข้อมูลที่คุณจัดเก็บไว้ในฐานข้อมูลและเครือข่ายขาออกทั้งหมด การเข้าชมที่เลเยอร์เซสชัน (เลเยอร์ 5) ของโมเดล OSI พื้นที่เก็บข้อมูลมีการเรียกเก็บเงินที่ $5 ต่อ GB/เดือน โดยประเมินทุกวัน การเรียกเก็บเงินจะไม่ได้รับผลกระทบจากตำแหน่งที่ตั้งดังกล่าว ฐานข้อมูลของคุณ การรับส่งข้อมูลขาออกรวมถึงการเชื่อมต่อและค่าใช้จ่ายในการเข้ารหัส จากการดำเนินการฐานข้อมูลทั้งหมดและข้อมูลที่ดาวน์โหลดผ่านการอ่านฐานข้อมูล ทั้ง 2 อย่าง การอ่านและเขียนฐานข้อมูลอาจทำให้เกิดค่าใช้จ่ายการเชื่อมต่อในใบเรียกเก็บเงิน ทั้งหมด การรับส่งข้อมูลไปยังและจากฐานข้อมูลของคุณ รวมถึงการดำเนินการที่ระบบรักษาความปลอดภัยปฏิเสธ กฎเหล่านี้จะนำไปสู่ค่าใช้จ่ายที่เรียกเก็บเงินได้

ตัวอย่างทั่วไปของการเข้าชมที่มีการเรียกเก็บเงิน ได้แก่

  • ข้อมูลที่ดาวน์โหลด: เมื่อลูกค้าได้รับข้อมูลจากฐานข้อมูล Firebase ของคุณ เรียกเก็บเงินสำหรับข้อมูลที่ดาวน์โหลด โดยทั่วไป รายได้ประเภทนี้คือ ค่าใช้จ่ายเกี่ยวกับแบนด์วิดท์ แต่นี่ไม่ใช่ปัจจัยเดียวในการเรียกเก็บเงิน
  • โอเวอร์เฮดของโปรโตคอล: การรับส่งข้อมูลเพิ่มเติมบางอย่างระหว่างเซิร์ฟเวอร์และไคลเอ็นต์ ที่จำเป็นต่อการสร้างและรักษาเซสชัน ขึ้นอยู่กับปัจจัยพื้นฐาน ซึ่งอาจรวมถึงการเข้าชมแบบเรียลไทม์ของ Firebase Realtime Database โอเวอร์เฮดของโปรโตคอล, โอเวอร์เฮดของ WebSocket และส่วนหัว HTTP ทุกครั้งที่ สร้างการเชื่อมต่อแล้ว ค่าใช้จ่ายในการดำเนินการนี้ รวมกับการเข้ารหัส SSL ทำให้มีค่าใช้จ่ายในการเชื่อมต่อด้วย แม้ว่านี่จะไม่ถือว่าเป็น แบนด์วิดท์สำหรับคำขอเดียว นี่สามารถเป็นส่วนสำคัญในการเรียกเก็บเงิน หากเพย์โหลดของคุณมีขนาดเล็ก หรือการเชื่อมต่อที่สั้นหรือบ่อยครั้ง
  • ส่วนเกินของการเข้ารหัส SSL: มีค่าใช้จ่ายที่เกี่ยวข้องกับ SSL ค่าใช้จ่ายในการดำเนินการเข้ารหัสที่จำเป็นสำหรับการเชื่อมต่อที่ปลอดภัย โดยเฉลี่ย ค่าใช้จ่ายนี้ ประมาณ 3.5 KB สำหรับแฮนด์เชคครั้งแรก และประมาณ 10 ไบต์สำหรับส่วนหัวของระเบียน TLS ในข้อความขาออกแต่ละฉบับ สำหรับแอปส่วนใหญ่ จะเป็น ในการเรียกเก็บเงินไม่กี่เปอร์เซ็นต์ อย่างไรก็ตาม อัตราดังกล่าวอาจกลายเป็น หากกรณีของคุณจำเป็นต้องมีแฮนด์เชค SSL จำนวนมาก ตัวอย่างเช่น อุปกรณ์ ที่ไม่รองรับตั๋วเซสชัน TLS อาจต้องใช้แฮนด์เชคการเชื่อมต่อ SSL จำนวนมาก
  • ข้อมูลคอนโซล Firebase: แม้ว่ามักจะไม่ใช่ข้อมูลที่สำคัญ ส่วนของค่าใช้จ่าย Realtime Database และ Firebase สำหรับข้อมูลที่คุณอ่านและ เขียนจากคอนโซล Firebase

ประมาณการใช้งานที่เรียกเก็บเงิน

หากต้องการดูการเชื่อมต่อและปริมาณการใช้อินเทอร์เน็ตของ Realtime Database ปัจจุบัน ให้เลือก การใช้งาน ในคอนโซล Firebase คุณสามารถตรวจสอบการใช้งานการเรียกเก็บเงินปัจจุบัน ช่วง 30 วันที่ผ่านมา หรือ 24 ชั่วโมงที่ผ่านมา

Firebase จะแสดงสถิติการใช้งานสำหรับเมตริกต่อไปนี้

  • การเชื่อมต่อ: จำนวนการเชื่อมต่อในเวลาเดียวกัน เปิดอยู่ และแบบเรียลไทม์ เชื่อมต่อกับฐานข้อมูลของคุณ ซึ่งรวมถึงแบบเรียลไทม์ต่อไปนี้ การเชื่อมต่อ: WebSocket, การสำรวจแบบใช้เวลานาน และเหตุการณ์ที่เซิร์ฟเวอร์ส่ง HTML ใช่เลย ไม่รวมคำขอ RESTful
  • พื้นที่เก็บข้อมูล: ปริมาณข้อมูลที่จัดเก็บไว้ในฐานข้อมูลของคุณ ลักษณะที่ไม่เข้าข่าย โฮสติ้งของ Firebase หรือข้อมูลที่จัดเก็บผ่านผลิตภัณฑ์อื่นๆ ของ Firebase
  • การดาวน์โหลด: ไบต์ทั้งหมดที่ดาวน์โหลดจากฐานข้อมูล รวมถึงโปรโตคอล และค่าใช้จ่ายในการเข้ารหัส
  • โหลด: กราฟนี้แสดงปริมาณการใช้งานฐานข้อมูลของคุณ รวมถึงกำลังประมวลผล ในช่วงเวลา 1 นาทีที่กำหนด คุณอาจเห็นปัญหาด้านประสิทธิภาพ เมื่อฐานข้อมูลของคุณเข้าใกล้ 100%

เพิ่มประสิทธิภาพการใช้งาน

มีแนวทางปฏิบัติแนะนำ 2-3 ข้อที่คุณสามารถใช้เพื่อเพิ่มประสิทธิภาพการใช้งานฐานข้อมูล และต้นทุนแบนด์วิดท์

  • ใช้ SDK แบบเนทีฟ: หากเป็นไปได้ ให้ใช้ SDK ที่สอดคล้องกับ แพลตฟอร์มของแอปของคุณ แทนที่จะเป็น REST API SDK ยังคงเปิดกว้าง ให้กับการเชื่อมต่อโดยตรง ซึ่งช่วยลดต้นทุนการเข้ารหัส SSL ซึ่งมักบวกกับ REST API
  • ตรวจหาข้อบกพร่อง: หากต้นทุนแบนด์วิดท์สูงโดยไม่คาดคิด ให้ยืนยัน การที่แอปไม่ได้ซิงค์ข้อมูลมากกว่าเดิมหรือซิงค์บ่อยกว่าเดิม อย่างที่ควรจะเป็น หากต้องการระบุปัญหา ให้ใช้เครื่องมือสร้างโปรไฟล์เพื่อ วัดการดำเนินการอ่านและเปิดการบันทึกการแก้ไขข้อบกพร่องใน Android Objective-C และเว็บ SDK ตรวจสอบการทำงานเบื้องหลังและกระบวนการซิงค์ในแอปเพื่อให้แน่ใจว่า ทุกอย่างทำงาน อย่างที่คุณตั้งใจไว้
  • ลดการเชื่อมต่อ: หากเป็นไปได้ ลองเพิ่มประสิทธิภาพการเชื่อมต่อ แบนด์วิดท์ คำขอ REST สั้นๆ ที่เกิดขึ้นบ่อยๆ อาจมีค่าใช้จ่ายมากกว่าคำขอเดียว อย่างต่อเนื่องโดยใช้ SDK แบบเนทีฟ หากคุณใช้ REST API พิจารณาใช้ HTTP Keep-alive หรือ เหตุการณ์ที่เซิร์ฟเวอร์ส่ง ซึ่งจะช่วยลดต้นทุนจากแฮนด์เชค SSL
  • ใช้ตั๋วเซสชัน TLS: ลดค่าใช้จ่ายในการดำเนินการเข้ารหัส SSL เมื่อกลับมาทำงานอีกครั้ง เชื่อมต่อได้ด้วยการออก ตั๋วเซสชัน TLS ซึ่งจะเป็นประโยชน์อย่างยิ่งหากคุณต้องการการเชื่อมต่อที่ปลอดภัยและบ่อยครั้ง ไปยังฐานข้อมูล
  • การค้นหาดัชนี: การจัดทำดัชนีข้อมูลของคุณ ช่วยลดแบนด์วิดท์รวมที่คุณใช้สำหรับการค้นหา ซึ่งมีประโยชน์ถึง 2 เท่า ในการลดต้นทุนและเพิ่มประสิทธิภาพของฐานข้อมูล ใช้เมนู เครื่องมือสร้างโปรไฟล์เพื่อค้นหาคำค้นหาที่ไม่ได้จัดทำดัชนีใน ฐานข้อมูลของคุณ
  • เพิ่มประสิทธิภาพผู้ฟัง: เพิ่มคำค้นหาเพื่อจำกัดข้อมูลที่คุณฟัง การดำเนินการจะแสดงผลและใช้ Listener ที่ดาวน์โหลดเฉพาะการอัปเดตข้อมูลเท่านั้น เช่น on() แทนที่จะเป็น once() นอกจากนี้ ให้วาง Listener ของคุณเป็น ให้ไกลที่สุดเท่าที่จะทำได้เพื่อจำกัดปริมาณข้อมูลที่ซิงค์
  • ลดค่าใช้จ่ายของพื้นที่เก็บข้อมูล: เรียกใช้งานการทำความสะอาดเป็นระยะและลดความซ้ำซ้อน ในฐานข้อมูลของคุณ
  • ใช้กฎ: ป้องกันการดำเนินการที่ไม่ได้รับอนุญาตซึ่งอาจมีค่าใช้จ่ายสูง ฐานข้อมูลของคุณ ตัวอย่างเช่น การใช้กฎความปลอดภัยของฐานข้อมูลเรียลไทม์ของ Firebase ช่วยหลีกเลี่ยงสถานการณ์นี้ได้ ซึ่งผู้ใช้ที่เป็นอันตรายจะดาวน์โหลดฐานข้อมูลทั้งหมดซ้ำๆ ดูข้อมูลเพิ่มเติมเกี่ยวกับ โดยใช้กฎฐานข้อมูลเรียลไทม์ของ Firebase

แผนการเพิ่มประสิทธิภาพที่ดีที่สุดสําหรับแอปของคุณจะขึ้นอยู่กับกรณีการใช้งานของคุณ แม้ว่านี่ไม่ใช่รายการแนวทางปฏิบัติแนะนำอย่างละเอียด แต่คุณจะพบ คำแนะนำและเคล็ดลับเพิ่มเติมจากผู้เชี่ยวชาญ Firebase ได้ที่ ช่อง Slack หรือใน Stack Overflow