เมื่อโปรเจ็กต์ของคุณใช้แผนการกำหนดราคา Spark แบบไม่มีค่าใช้จ่าย คุณจะไม่ถูกเรียกเก็บเงินสำหรับ การใช้งาน Realtime Database คุณจะได้รับการใช้งานแบบไม่มีค่าใช้จ่ายซึ่งรวมถึงพื้นที่เก็บข้อมูล 1 GB และการดาวน์โหลดข้อมูล 10 GB/เดือน
หากอัปเกรดเป็นแผนการกำหนดราคา Blaze แบบจ่ายตามการใช้งาน คุณจะยังคงได้รับการใช้งานแบบไม่มีค่าใช้จ่าย (พื้นที่เก็บข้อมูล 1 GB และการดาวน์โหลดข้อมูล 10 GB/เดือน) และ ระบบจะเรียกเก็บเงินสำหรับการใช้งานที่เกินจำนวนดังกล่าว เมื่อโปรเจ็กต์ของคุณใช้แผนการกำหนดราคา Blaze เราขอแนะนำให้ตั้งค่า การแจ้งเตือนงบประมาณ สำหรับโปรเจ็กต์
ส่วนที่เหลือของหน้านี้จะอธิบายรายละเอียดเพิ่มเติมเกี่ยวกับการเรียกเก็บเงิน
วิธีที่ Realtime Database คำนวณการเรียกเก็บเงิน
Firebase จะเรียกเก็บเงินสำหรับข้อมูลที่คุณจัดเก็บไว้ในฐานข้อมูลและการรับส่งข้อมูลเครือข่ายขาออกทั้งหมดที่เลเยอร์เซสชัน (เลเยอร์ 5) ของโมเดล OSI ระบบจะเรียกเก็บเงินค่าพื้นที่เก็บข้อมูลในอัตรา $5 ต่อ GB/เดือน โดยจะประเมินทุกวัน การเรียกเก็บเงินจะไม่ได้รับผลกระทบจากตำแหน่งของฐานข้อมูล การรับส่งข้อมูลขาออกรวมถึงส่วนเกินของการเชื่อมต่อและการเข้ารหัสจากการดำเนินการฐานข้อมูลทั้งหมดและข้อมูลที่ดาวน์โหลดผ่านการอ่านฐานข้อมูล ทั้งการอ่านและการเขียนฐานข้อมูลอาจทำให้เกิดค่าใช้จ่ายในการเชื่อมต่อในใบแจ้งหนี้ การรับส่งข้อมูลทั้งหมดที่เข้าและออกจากฐานข้อมูล รวมถึงการดำเนินการที่กฎความปลอดภัยปฏิเสธ จะทำให้เกิดค่าใช้จ่ายที่เรียกเก็บเงินได้
ตัวอย่างที่พบบ่อยของการรับส่งข้อมูลที่เรียกเก็บเงิน ได้แก่
- ข้อมูลที่ดาวน์โหลด: เมื่อไคลเอ็นต์รับข้อมูลจากฐานข้อมูล Firebase จะเรียกเก็บเงินสำหรับข้อมูลที่ดาวน์โหลด โดยปกติแล้ว ข้อมูลนี้จะเป็นค่าใช้จ่ายแบนด์วิดท์ส่วนใหญ่ แต่ก็ไม่ใช่ปัจจัยเดียวที่ส่งผลต่อใบแจ้งหนี้
- ส่วนเกินของโปรโตคอล: จำเป็นต้องมีการรับส่งข้อมูลเพิ่มเติมระหว่างเซิร์ฟเวอร์กับไคลเอ็นต์เพื่อสร้างและรักษาเซสชัน การรับส่งข้อมูลนี้อาจรวมถึงส่วนเกินของโปรโตคอลแบบเรียลไทม์ของฐานข้อมูลเรียลไทม์ของ Firebase, ส่วนเกินของ WebSocket และส่วนเกินของส่วนหัว HTTP ทั้งนี้ขึ้นอยู่กับโปรโตคอลพื้นฐาน ทุกครั้งที่มีการสร้างการเชื่อมต่อ ส่วนเกินนี้รวมกับส่วนเกินของการเข้ารหัส SSL จะทำให้เกิดค่าใช้จ่ายในการเชื่อมต่อ แม้ว่าการรับส่งข้อมูลนี้จะไม่มากนักสำหรับการขอครั้งเดียว แต่ก็อาจเป็นส่วนสำคัญของใบแจ้งหนี้หากเพย์โหลดมีขนาดเล็กมากหรือคุณทำการเชื่อมต่อสั้นๆ บ่อยครั้ง
- ส่วนเกินของการเข้ารหัส SSL: มีค่าใช้จ่ายที่เกี่ยวข้องกับส่วนเกินของการเข้ารหัส SSL ซึ่งจำเป็นสำหรับการเชื่อมต่อที่ปลอดภัย โดยเฉลี่ยแล้ว ค่าใช้จ่ายนี้จะอยู่ที่ประมาณ 3.5 KB สำหรับการเริ่มต้นการเชื่อมต่อ (Handshake) และประมาณสิบไบต์สำหรับส่วนหัวของบันทึก TLS ในข้อความขาออกแต่ละรายการ สำหรับแอปส่วนใหญ่ ค่าใช้จ่ายนี้จะเป็นเปอร์เซ็นต์ที่น้อยมากของใบแจ้งหนี้ อย่างไรก็ตาม ค่าใช้จ่ายนี้อาจกลายเป็นเปอร์เซ็นต์ที่สูงหากกรณีเฉพาะของคุณต้องมีการเชื่อมต่อ SSL จำนวนมาก เช่น อุปกรณ์ ที่ไม่รองรับ ตั๋วเซสชัน TLS อาจต้องมีการเชื่อมต่อ SSL จำนวนมาก
- Firebase ข้อมูลคอนโซล: แม้ว่าโดยปกติแล้วข้อมูลนี้จะไม่ใช่ส่วนสำคัญ ของ Realtime Database ค่าใช้จ่าย แต่ Firebase จะเรียกเก็บเงินสำหรับข้อมูลที่คุณอ่านและ เขียนจากคอนโซล Firebase
ประมาณการใช้งานที่เรียกเก็บเงิน
หากต้องการดูการเชื่อมต่อ Realtime Database และการใช้งานข้อมูลปัจจุบัน ให้ตรวจสอบแท็บ การใช้งาน ในคอนโซล Firebase คุณสามารถตรวจสอบการใช้งานในช่วงเวลาการเรียกเก็บเงินปัจจุบัน ช่วง 30 วันที่ผ่านมา หรือช่วง 24 ชั่วโมงที่ผ่านมา
Firebase จะแสดงสถิติการใช้งานสำหรับเมตริกต่อไปนี้
- การเชื่อมต่อ: จำนวนการเชื่อมต่อแบบเรียลไทม์พร้อมกันที่เปิดอยู่กับฐานข้อมูล ซึ่งรวมถึงการเชื่อมต่อแบบเรียลไทม์ต่อไปนี้ WebSocket, Long Polling และเหตุการณ์ที่เซิร์ฟเวอร์ส่ง (Server-Sent Events) ของ HTML แต่ไม่รวมคำขอ RESTful
- พื้นที่เก็บข้อมูล: ปริมาณข้อมูลที่จัดเก็บไว้ในฐานข้อมูล ซึ่งไม่รวมโฮสติ้งของ Firebase หรือข้อมูลที่จัดเก็บผ่านผลิตภัณฑ์อื่นๆ ของ Firebase
- การดาวน์โหลด: ไบต์ทั้งหมดที่ดาวน์โหลดจากฐานข้อมูล รวมถึงส่วนเกินของโปรโตคอลและการเข้ารหัส
- โหลด: กราฟนี้แสดงปริมาณฐานข้อมูลที่ใช้งานอยู่ในการประมวลผลคำขอในช่วงเวลา 1 นาทีที่กำหนด คุณอาจพบปัญหาด้านประสิทธิภาพเมื่อฐานข้อมูลใกล้ถึง 100%
เพิ่มประสิทธิภาพการใช้งาน
มีแนวทางปฏิบัติแนะนำบางอย่างที่คุณนำไปใช้เพื่อเพิ่มประสิทธิภาพการใช้งานฐานข้อมูลและลดค่าใช้จ่ายแบนด์วิดท์ได้
- ใช้ SDK ดั้งเดิม: ใช้ SDK ที่สอดคล้องกับแพลตฟอร์มของแอปแทน REST API ทุกครั้งที่ทำได้ SDK จะรักษาการเชื่อมต่อที่เปิดอยู่ ซึ่งจะช่วยลดค่าใช้จ่ายในการเข้ารหัส SSL ที่มักจะเพิ่มขึ้นเมื่อใช้ REST API
- ตรวจสอบข้อบกพร่อง: หากค่าใช้จ่ายแบนด์วิดท์สูงกว่าที่คาดไว้ ให้ตรวจสอบว่าแอปไม่ได้ซิงค์ข้อมูลมากขึ้นหรือซิงค์บ่อยกว่าที่คุณตั้งใจไว้ในตอนแรก หากต้องการระบุปัญหา ให้ใช้เครื่องมือโปรไฟล์เพื่อ วัดการดำเนินการอ่านและเปิดการบันทึกการดีบักใน Android, Objective-C, และ เว็บ SDK ตรวจสอบกระบวนการเบื้องหลังและการซิงค์ในแอปเพื่อให้แน่ใจว่าทุกอย่างทำงานตามที่คุณต้องการ
- ลดการเชื่อมต่อ: ลองเพิ่มประสิทธิภาพแบนด์วิดท์การเชื่อมต่อหากทำได้ คำขอ REST ขนาดเล็กที่ส่งบ่อยครั้งอาจมีค่าใช้จ่ายสูงกว่าการเชื่อมต่อต่อเนื่องครั้งเดียวโดยใช้ SDK ดั้งเดิม หากใช้ REST API ให้พิจารณาใช้ HTTP Keep-Alive หรือ เหตุการณ์ที่เซิร์ฟเวอร์ส่ง (Server-Sent Events) ซึ่งจะช่วยลดค่าใช้จ่ายจากการเชื่อมต่อ SSL
- ใช้ตั๋วเซสชัน TLS: ลดค่าใช้จ่ายส่วนเกินของการเข้ารหัส SSL ในการเชื่อมต่อที่กลับมาทำงานอีกครั้งโดยออก ตั๋วเซสชัน TLS วิธีนี้มีประโยชน์อย่างยิ่งหากคุณต้องการการเชื่อมต่อที่ปลอดภัยกับฐานข้อมูลบ่อยครั้ง
- การค้นหาดัชนี: การจัดทำดัชนีข้อมูล จะช่วยลดแบนด์วิดท์ทั้งหมดที่คุณใช้สำหรับการค้นหา ซึ่งมีประโยชน์ 2 ประการ คือช่วยลดค่าใช้จ่ายและเพิ่มประสิทธิภาพของฐานข้อมูล ใช้เครื่องมือ โปรไฟล์เพื่อ ค้นหาการค้นหาที่ไม่ได้จัดทำดัชนีใน ฐานข้อมูล
- เพิ่มประสิทธิภาพ Listener: เพิ่มการค้นหาเพื่อจำกัดข้อมูลที่การดำเนินการ Listen จะแสดงผล และใช้ Listener ที่ดาวน์โหลดเฉพาะการอัปเดตข้อมูล เช่น
on()แทนonce()นอกจากนี้ ให้วาง Listener ไว้ในเส้นทางที่ลึกที่สุดเท่าที่จะทำได้เพื่อจำกัดปริมาณข้อมูลที่จะซิงค์ - ลดค่าใช้จ่ายพื้นที่เก็บข้อมูล: เรียกใช้การล้างข้อมูลเป็นระยะและลดข้อมูลที่ซ้ำกันในฐานข้อมูล
- ใช้กฎ: ป้องกันการดำเนินการที่ไม่ได้รับอนุญาตซึ่งอาจมีค่าใช้จ่ายสูงในฐานข้อมูล เช่น การใช้ Firebase Realtime Database Security Rules อาจช่วยหลีกเลี่ยงสถานการณ์ ที่ผู้ใช้ที่เป็นอันตรายดาวน์โหลดฐานข้อมูลทั้งหมดของคุณซ้ำๆ ดูข้อมูลเพิ่มเติมเกี่ยวกับ การใช้กฎฐานข้อมูลเรียลไทม์ของ Firebase
แผนการเพิ่มประสิทธิภาพที่ดีที่สุดสำหรับแอปจะขึ้นอยู่กับกรณีการใช้งานเฉพาะของคุณ แม้ว่ารายการนี้จะไม่ใช่รายการแนวทางปฏิบัติแนะนำทั้งหมด แต่คุณสามารถดู คำแนะนำและเคล็ดลับเพิ่มเติมจากผู้เชี่ยวชาญของ Firebase ได้ใน ช่อง Slack หรือใน Stack Overflow