Firestore JOIN Tuzağı
Yaygın bir Firestore sorunuyla karşılaşıyorsunuz. Firebase fonksiyonunuz bir maksimum batch size hatası veriyor. Bir panel (dashboard) için siparişleri ve müşterileri birleştirmeniz (join) gerekiyor. Bunu düzeltmek için genellikle verileri kopyalıyorsunuz (duplicate). Ancak şimdi verileriniz güncelliğini yitirmiş ve tutarsız.
Google bunu çözmek için Pipelines API'yi duyurdu. Verileri kopyalamadan koleksiyonlar arasında JOIN işlemlerine olanak tanır. Bazı geliştiriciler küçük testlerde hızlı sorgu süreleri rapor ediyor.
Bu API'yi ağır yük altında test etmek için bir hafta harcadım. İşte dokümantasyonun size söylemediği şeyler.
Yüksek Maliyetler Her pipeline yürütmesi, ilgili tüm koleksiyonlardan okuma yapar. İki koleksiyon arasındaki bir JOIN işlemi, her iki koleksiyondaki okumalar için de faturalandırılır. 50.000 dokümanlık iki koleksiyonu birleştirirseniz, maliyetleriniz kötü ölçeklenir. Bu basit, doğrusal bir maliyet değildir.
Performans Limitleri Testlerimde, 10.000 dokümana karşı yapılan bir pipeline 380ms sürdü. 100.000 dokümanı test ettiğimde, sorgu 30 saniyede zaman aşımına uğradı. Sorunu çözmüyorsunuz. Sadece bir batch hatasını bir timeout hatasına dönüştürüyorsunuz.
Cold Start Sorunları Pipelines ayrı bir yürütme bağlamı (execution context) oluşturur. Cloud Functions gibi sunucusuz (serverless) ortamlarda bu, 2 ila 4 saniyelik bir gecikme ekler. Kullanıcılarınız uygulamanızın yavaş olduğunu düşünecektir.
Pipelines API, prototipleme veya 5.000 dokümanın altındaki küçük koleksiyonlar için bir araçtır. İlişkisel bir veritabanının yerini tutmaz. Google bunu, PostgreSQL veya Spanner'a geçmek yerine Firebase ekosisteminde kalmanıza yardımcı olmak için sunuyor.
Eğer Pipelines kullanıyorsanız, şu kurallara uyun:
• Koleksiyon boyutunuzu denetleyin. Bir koleksiyon 20.000 dokümanı aşarsa, önce JOIN maliyetini hesaplayın. • Karmaşıklığı sınırlayın. Üç veya daha fazla koleksiyon arasında yapılan bir JOIN kötü bir işarettir. • Okuma maliyetlerini haftalık olarak takip edin. Pipeline okumaları faturanızda farklı görünür. • Denormalize edilmiş verilerinizi koruyun. Pipelines'ı tamamen bir ikame olarak değil, bir tamamlayıcı olarak kullanın. • Gerçek trafikle test edin. Sakin koleksiyonlar üzerindeki kıyaslamalar (benchmarks), üretim ortamı gerçekliğini yansıtmaz.
Gerçek bir mimari karardan kaçınmak için yara bandı kullanmayın.
Firestore'da ilişkileri nasıl yönetiyorsunuz? Denormalizasyon mu yoksa istemci tarafı (client-side) join işlemleri mi kullanıyorsunuz? Yorumlarda bana bildirin.