پرداخت بیدرنگ پایگاه داده را درک کنید

صورتحساب Firebase برای داده هایی که در پایگاه داده خود ذخیره می کنید و تمام ترافیک شبکه خروجی در لایه جلسه (لایه 5) مدل OSI. هزینه ذخیره سازی 5 دلار برای هر گیگابایت در ماه محاسبه می شود که روزانه ارزیابی می شود. صورتحساب تحت تأثیر موقعیت پایگاه داده شما قرار نمی گیرد. ترافیک خروجی شامل سربار اتصال و رمزگذاری از کلیه عملیات پایگاه داده و داده های دانلود شده از طریق خواندن پایگاه داده است. هم خواندن و هم نوشتن پایگاه داده می تواند منجر به هزینه های اتصال در صورتحساب شما شود. تمام ترافیک به و از پایگاه داده شما، از جمله عملیاتی که توسط قوانین امنیتی رد شده است، منجر به هزینه های قابل پرداخت می شود.

برخی از نمونه های رایج ترافیک صورتحساب عبارتند از:

  • داده‌های بارگیری‌شده: وقتی مشتریان داده‌ها را از پایگاه داده شما دریافت می‌کنند، Firebase هزینه داده‌های دانلود شده را دریافت می‌کند. به طور معمول، این بخش عمده هزینه های پهنای باند شما را تشکیل می دهد، اما این تنها عامل در صورتحساب شما نیست.
  • سربار پروتکل: مقداری ترافیک اضافی بین سرور و کلاینت ها برای ایجاد و نگهداری یک جلسه ضروری است. بسته به پروتکل زیربنایی، این ترافیک ممکن است شامل موارد زیر باشد: سربار پروتکل بیدرنگ پایگاه داده Firebase، سربار WebSocket و سربار هدر HTTP. هر بار که یک اتصال برقرار می شود، این سربار، همراه با هر سربار رمزگذاری SSL، به هزینه های اتصال کمک می کند. اگرچه این پهنای باند زیادی برای یک درخواست واحد نیست، اما اگر بارهای شما کوچک باشد یا اتصالات مکرر و کوتاه داشته باشید، می تواند بخش قابل توجهی از صورتحساب شما باشد.
  • سربار رمزگذاری SSL: هزینه های مربوط به سربار رمزگذاری SSL برای اتصالات ایمن ضروری است. به طور متوسط، این هزینه تقریباً 3.5 کیلوبایت برای دست دادن اولیه و تقریباً ده ها بایت برای سرصفحه های ضبط TLS در هر پیام ارسالی است. برای اکثر برنامه ها، این درصد کمی از صورت حساب شما است. با این حال، اگر مورد خاص شما نیاز به دست دادن های SSL زیادی داشته باشد، این می تواند درصد زیادی داشته باشد. برای مثال، دستگاه‌هایی که از بلیط‌های جلسه TLS پشتیبانی نمی‌کنند ممکن است به تعداد زیادی دست دادن اتصال SSL نیاز داشته باشند.
  • داده‌های کنسول Firebase : اگرچه این معمولاً بخش قابل‌توجهی از هزینه‌های Realtime Database نیست، Firebase برای داده‌هایی که از کنسول Firebase می‌خوانید و می‌نویسید هزینه‌ای را دریافت می‌کند.

مصرف صورتحساب خود را تخمین بزنید

برای مشاهده اتصالات کنونی Realtime Database و مصرف داده، برگه Usage را در کنسول Firebase بررسی کنید. می‌توانید میزان استفاده را در دوره صورت‌حساب فعلی، 30 روز گذشته یا 24 ساعت گذشته بررسی کنید.

Firebase آمار استفاده را برای معیارهای زیر نشان می دهد:

  • اتصالات: تعداد اتصالات همزمان، در حال حاضر باز و بیدرنگ به پایگاه داده شما. این شامل اتصالات بیدرنگ زیر است: WebSocket، نظرسنجی طولانی، و رویدادهای ارسال شده توسط سرور HTML. این شامل درخواست های RESTful نیست.
  • ذخیره سازی: چه مقدار داده در پایگاه داده شما ذخیره می شود. این شامل میزبانی Firebase یا داده های ذخیره شده از طریق سایر محصولات Firebase نمی شود.
  • دانلودها: تمام بایت های دانلود شده از پایگاه داده شما، از جمله سربار پروتکل و رمزگذاری.
  • بارگذاری: این نمودار نشان می دهد که چه مقدار از پایگاه داده شما در یک بازه زمانی 1 دقیقه ای در حال پردازش است، درخواست ها را پردازش می کند. با نزدیک شدن به 100% پایگاه داده شما ممکن است مشکلات عملکرد را مشاهده کنید.

استفاده را بهینه کنید

چند روش وجود دارد که می توانید برای بهینه سازی استفاده از پایگاه داده و هزینه های پهنای باند خود از آنها استفاده کنید.

  • از SDK های بومی استفاده کنید: در صورت امکان، به جای REST API از SDK هایی استفاده کنید که با پلتفرم برنامه شما مطابقت دارند. SDK ها اتصالات باز را حفظ می کنند و هزینه های رمزگذاری SSL را که معمولاً با REST API جمع می شود، کاهش می دهند.
  • اشکالات را بررسی کنید: اگر هزینه‌های پهنای باند شما به طور غیرمنتظره‌ای بالا است، بررسی کنید که برنامه شما داده‌های بیشتری را همگام‌سازی نمی‌کند یا بیشتر از آنچه در نظر داشتید همگام‌سازی نمی‌کند. برای مشخص کردن مشکلات، از ابزار نمایه ساز برای اندازه‌گیری عملیات خواندن خود استفاده کنید و ثبت اشکال‌زدایی را در Android ، Objective-C و Web SDK روشن کنید. پس‌زمینه و فرآیندهای همگام‌سازی را در برنامه خود بررسی کنید تا مطمئن شوید همه چیز همانطور که می‌خواهید کار می‌کند.
  • کاهش اتصالات: در صورت امکان، سعی کنید پهنای باند اتصال خود را بهینه کنید. درخواست های مکرر و کوچک REST می تواند پرهزینه تر از یک اتصال منفرد و مداوم با استفاده از SDK بومی باشد. اگر از REST API استفاده می‌کنید، استفاده از رویدادهای HTTP حفظ زنده یا ارسال‌شده توسط سرور را در نظر بگیرید، که می‌تواند هزینه‌های دست دادن SSL را کاهش دهد.
  • از بلیط‌های جلسه TLS استفاده کنید: با صدور بلیط‌های جلسه TLS، هزینه‌های سربار رمزگذاری SSL در اتصالات از سر گرفته شده را کاهش دهید. اگر به اتصالات مکرر و ایمن به پایگاه داده نیاز دارید، این به ویژه مفید است.
  • پرس و جوهای شاخص: نمایه سازی داده های شما کل پهنای باندی را که برای پرس و جوها استفاده می کنید کاهش می دهد، که این مزیت مضاعف کاهش هزینه ها و افزایش عملکرد پایگاه داده شما دارد. از ابزار profiler برای یافتن پرس و جوهای فهرست نشده در پایگاه داده خود استفاده کنید.
  • شنوندگان خود را بهینه کنید: برای محدود کردن داده‌هایی که عملیات گوش دادن شما برمی‌گرداند، درخواست‌هایی اضافه کنید و از شنونده‌هایی استفاده کنید که فقط به‌روزرسانی‌های داده‌ها را دانلود می‌کنند - برای مثال، on() به جای once() . علاوه بر این، شنوندگان خود را تا جایی که می توانید در پایین مسیر قرار دهید تا میزان داده های همگام سازی آنها را محدود کنید.
  • کاهش هزینه های ذخیره سازی: کارهای پاکسازی دوره ای را اجرا کنید و داده های تکراری را در پایگاه داده خود کاهش دهید.
  • قوانین استفاده: از هر گونه عملیات بالقوه پرهزینه و غیرمجاز در پایگاه داده خود جلوگیری کنید. به عنوان مثال، استفاده از Firebase Realtime Database Security Rules می تواند از سناریویی جلوگیری کند که در آن یک کاربر مخرب به طور مکرر کل پایگاه داده شما را دانلود می کند. درباره استفاده از قوانین پایگاه داده بیدرنگ Firebase بیشتر بیاموزید.

بهترین طرح بهینه سازی برای برنامه شما به مورد استفاده خاص شما بستگی دارد. اگرچه این فهرست جامعی از بهترین روش‌ها نیست، می‌توانید توصیه‌ها و نکات بیشتری را از کارشناسان Firebase در کانال Slack یا Stack Overflow بیابید.