Firebase Realtime DB Performans Optimizasyonu

CLI ile database profile aracını kullanarak rapor oluşturup DB performansını iyileştireceğiz ve maliyetleri düşüreceğiz. Zaman içinde CLI aracını kullanarak yaklaşık x10 oranında performans/cost iyileştirmesi yaptık. Adım adım birlikte ilerleyelim.

Firebase CLI kurulu olmalı, değil ise ;

$ npm install -g firebase-tools

Alternatif kurulumlar için yönergeleri izleyebilirsiniz.

Login olalım

$ firebase login

Projeyi oluşturalım
Local de kullanabilmek için “init” yapmamız gerekiyor. “Use an existing project” seçeneği ile mevcut kullandığınız projenizi seçebilirsiniz.

$ firebase init

Instanceları listeleyelim

$ firebase database:instances:list

Ve aracı çalıştıralım;

$ firebase database:profile -instance demo

Enter yapılana kadar kayıtları almaya devam edecektir.

Aşağıdaki gibi bir rapor sizi karşılar. Verilerin okuma-yazma seviyelerini, hız ve trafik kullanımlarını görebilirsiniz. Tablo sayesinde zihmimizde tüm yapı canlandı bile. Yazının devamında raporun özet incelemesini ve önerilerini bulabilirsiniz.

Ama öncesinde iki önemli konumuz var;

• Verilerinizde iyileştirme yaparken “Data-Rules-Security” konusu önemli. Daha önce yazdığım makaleden yararlanabilirsiniz.
• Profil oluşturma aracı “faturalandırma” aracı değildir. Google resmi dökümanlarında yazdığı gibi bu amaçla kullanılmamalı. Örneğin; bant genişliği tahmini değerdir. Ancak x path’inde bulunan datayı, 19 kez download ediyorsa bu performans + maliyettir.

İpucu

Get Dinçer Demircioğlu’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Eğer instance üzerinde daha detaylı rapor istiyorsanız “raw” opsiyonunu kullanın.

firebase database:profile --instance demo --raw

IP adresi, user agent, path, süre ve diğer bilgileri içeren örnek çıktı.

{
    "name": "rest-read",
    "timestamp": 1711457543925,
    "client": {
    "remoteAddress": {
        "address": "1.2.3.4"
    },
    "userAgent": {
        "browser": "-",
        "os": "-",
        "platform": "-",
        "userAgentString": "-",
        "version": "-"
    }
    },
    "path": [
        "message"
    ],
    "pendingTime": 0,
    "millis": 0,
    "bytes": 0,
    "allowed": true
}

Report

3 ana başlıkta inceliyoruz; Speed (hız), Bandwidth (bant genişliği), Unindexed Queries (index eklenmemiş sorgular)

Speed

Read ve write olarak ayırılmış iki başlık da; işlem sayısı, süre ve yetki hatalarını görebilirsiniz.

Bandwidth

Bant genişliği, performans/maliyet data boyutuna bağlı olduğu için sadece ihtiyacınız olan veriyi Firebase den istemelisiniz.

Unindexed Queries

Verilerinizi indexleyerek, diğer veritabanların da olduğu gibi sorgulama performansını artırabilirsiniz. Önerilerde örnek kullanımı ekliyorum.

Optimizasyon Önerileri

• Veri modeli doğru kurgulanmalı. İhtiyacınız olan veriye tek seferde ulaşabilir olmalısınız. Örneğin: X path’inde A bilgisi size gerekli iken B-C-D aynı anda okumamalısınız. İhtiyacınız olmayan veriyi aldığınızda “download” artar. Süre + maliyet etkilenir.
• İşlem yoğunluğunu azaltmalısınız. X path’inde veriye ulaşmak için 5 alt kırılıma ihtiyaç duymamalı ya da 10 kez aynı veriyi okumamalısınız. Biz bu kontrolleri ekleyip, optimizasyonu yaparak yaklaşık $50 olan maliyetimizi $5 gibi bir rakama dönüştürmeyi başardık.
• Firebase Cloud Functions kullanın. Örneğin : trigger ile messages/{id}/{x}/{y} üzerinde ref.create olduğunda replyMessage çalıştırın diyebiliriz. Aynı trigger http request içinde geçerli. Kendiniz aynı yapıyı kurmak istediğiniz de daha maliyetli olabilir. Function ların ücretlendirmesi (invocations/memory-cpu second) olsa da performans anlamında kazandıracaktır. Tek DB üzerinde birçok farklı amaç için function trigger kullanabilirsiniz. Burası tek başına blog post olabilir ana fikri paylaşmak istedim.
• Kullanılmayan veya ihtiyacınız olmayan verileri temizleyin. (Tabi ki kullanım ve projenize göre değişen bir madde)
• SDK ları kullanmalısınız. Sizi doğru methodları kullanmak için yönlendirecektir.
• Limitleyin. UI’da 5 kayıt size gerekli iken onlarcasını read ediyor olabilirsiniz.

db.ref("messages").limitToFirst(10)
                  .orderByKey("key")

# or

.limitToLast(10)

• Firebase bağımsız, projenizde cache kullanın. Örneğin; mesajlaşma için socket kullanıyor ve her yeniliği event ile dinliyor bile olsanız, cache kullanarak trafik + hızdan kazanabilirsiniz.
• Yük altında çalıştığınızda, eş zamanlı 200.000 connection sınırı var. Farklı DB lere split ederek kullanabilirsiniz. CLI da “-instance db_name” ile ayrı ayrı raporlayabilirsiniz. Yukarıdaki ilk örneklerde kullanmıştık.
• Index eklemek için rules bölümünden data kırılımına aşağıdaki gibi tanımlama yapmanız yeterli.

"messages":{
  ".indexOn":[
    "type",
    "status"
  ]
}

Bonus olarak tüm iyileştirmelere rağmen Firebase maliyetiniz projenizin giderlerini etkiliyorsa open-source olarak RethinkDB bakmanızı önerebilirim.