Cloud Firestore, Google'ın NoSQL, belge-tabanlı bir veritabanıdır ve modern, ölçeklenebilir uygulamaların temel veri depolama ihtiyacını karşılamak üzere tasarlanmıştır. Geleneksel ilişkisel veritabanlarından (SQL) radikal bir kopuşu temsil eder; burada veriler, satırlar ve sütunlarla düzenlenmiş tablolarda değil, JSON benzeri belgeler içinde saklanır. Bu belgeler, birim olarak okunur ve yazılır, bu da karmaşık sorgular için parçalı veri getirmenin önüne geçer. Bu yapı, esnek ve hiyerarşik veri modellemesine izin verirken, uygulama mantığı ile veri katmanı arasındaki eşlemenin doğal olmasını sağlar.
Firestore'un organizasyonel hiyerarşisi, koleksiyonlar ve belgeler etrafında kuruludur. En üst düzeyde, bir veritabanı örneği bulunur. Bu veritabanı, koleksiyonları barındırır. Her koleksiyon ise belgelerden oluşur. Kritik olan nokta, bir belgenin kendi içinde alt koleksiyonlar barındırabilmesidir. Bu, sonsuz bir iç içe geçme döngüsü oluşturarak, ilgili verileri mantıksal bir şekilde gruplamak için güçlü bir mekanizma sunar. Örneğin, bir "kullanıcılar" koleksiyonundaki her belge (her kullanıcı), "gönderiler" adında bir alt koleksiyona sahip olabilir. Bu model, veriyi normalleştirmek veya bir araya getirmek arasındaki dengeyi belirlerken, doğrudan ve tahmin edilebilir erişim yolları sağlar.
Veri Modeli Tasarım İlkeleri
Firestore'da etkili bir veri modeli tasarlamak, uygulamanın performansı, maliyeti ve bakım kolaylığı üzerinde doğrudan etkiye sahiptir. Tasarım, verinin nasıl okunacağına ve yazılacağına dair senaryolar derinlemesine düşünülerek yapılmalıdır. İlişkisel veritabanlarında yaygın olan normalizasyon, Firestore'da genellikle pahalı ve verimsiz sorgulara yol açar. Bunun yerine, denormalizasyon ve veri tekrarlama temel tasarım araçları haline gelir. Sık birlikte erişilen veriler, okuma performansını en üst düzeye çıkarmak ve sorgu sayısını en aza indirmek için aynı belgeye yerleştirilmelidir.
Belge yapısını planlarken, belgelerin derinliği ve büyüklüğü dikkate alınmalıdır. Firestore, bir belgenin maksimum 1 MB boyutunda olmasını şart koşar. Bu nedenle, sonsuz büyüyen diziler (örneğin, sınırsız sayıda mesaj kaydı) tek bir belgede saklanmamalıdır. Bunun yerine, bu tür veriler alt koleksiyonlara taşınmalıdır. Ayrıca, uygulamanın ihtiyaç duyduğu sorguları destekleyecek şekilde dizinlerin etkinleştirilmesi gerekir. Firestore, çoğu sorgu için otomatik olarak dizin oluşturur, ancak bileşik sorgular için özel dizinlerin `firestore.indexes` dosyasında tanımlanması gerekebilir.
İlişkisel verileri modellemek, Firestore'da özel bir dikkat gerektirir. Çok-çok ilişkileri, genellikle ara belgeler veya referans alanları kullanılarak yönetilir. Örneğin, öğrenciler ve dersler arasındaki bir ilişki, her biri öğrenci ve ders referansları içeren bir "kayıtlar" koleksiyonu ile temsil edilebilir. Bu yaklaşım, "Hangi öğrenciler bu derse kayıtlı?" veya "Bu öğrenci hangi dersleri alıyor?" gibi sorguları kolaylaştırır. Anahtar, verileri, uygulamanın ekranlarına ve kullanım durumlarına mümkün olduğunca yakın bir şekilde yapılandırmaktır. Bu, okuma verimliliğini artırır ve maliyetli sorgu birleştirmelerinden kaçınır.
Bir veri modeli tasarım kararlarını özetlemek için aşağıdaki tablo faydalı bir rehber sunar:
| Senaryo | Önerilen Tasarım | Mantık |
|---|---|---|
| Bir kullanıcının profil bilgileri | Tek bir belge | Sık birlikte okunan, küçük ve güncellenen veri. |
| Bir blog gönderisinin yorumları | Alt koleksiyon ("comments") | Veri kümesi sınırsız büyüyebilir ve ayrıca sayfalandırma gerektirir. |
| Ürün kategorileri ve ürünler | Koleksiyonlar ("categories", "products") ve ürün belgesinde kategori referansı. | Kategoriler değişirken ürün bağımsızdır, çok sayıda sorgu gerektirebilir. |
| Sayaçlar (beğeni sayısı, takipçi) | Belge içinde bir alan veya ayrı "sayac" belgesi (sharding ile). | Yüksek yazma hızlarını karşılamak için parçalama (sharding) gerekebilir. |
Veri Erişim Desenleri
Firestore'da veri almanın verimliliği, kullanılan erişim desenlerine doğrudan bağlıdır. Temel okuma işlemleri, tek bir belgeyi, bir koleksiyondaki tüm belgeleri veya sorgulanmış bir sonuç kümesini getirebilir. Belge referansları kullanmak, belirli bir belgeyi doğrudan yolunu bilerek almak için en hızlı yoldur. Koleksiyon referansları üzerinde ise filtreler (`where`), sıralamalar (`orderBy`), limitler (`limit`) ve sayfalama (`startAfter`) kullanılarak karmaşık sorgular oluşturulabilir. Verilerin yapılandırılma şekli, bu sorguların performansını ve hatta geçerliliğini belirler.
Firestore'un güçlü yanlarından biri, gerçek zamanlı dinleyicilerdir. `onSnapshot` metodu, bir belge veya sorgu sonucuna abone olmanızı ve verilerde herhangi bir değişiklik olduğunda anında güncellenen bir sonuç almanızı sağlar. Bu, kullanıcı arayüzlerinin sunucudan gelen verilerle otomatik olarak senkronize kalmasını sağlayarak, anlık etkileşimli uygulamaların temelini oluşturur. Ancak, bu dinleyicilerin dikktli yönetilmesi gerekir; gereksiz dinleyicilerin kapatılmaması, bellek sızıntılarına ve artan fatura maliyetlerine neden olabilir. Her ekran veya bileşen kapatıldığında, ilgili dinleyicileri temizlemek temel bir gerekliliktir.
Toplu okuma işlemleri için `getAll` gibi yöntemler, bir dizi belge referansını tek bir istekte getirerek ağ gidiş-geliş sayısını azaltır. Bu, ilişkisel verileriniz dağıtılmış farklı belgelerde saklandığında ve hepsini aynı anda yüklemeniz gerektiğinde özellikle kullanışlıdır. Öte yandan, toplu yazma işlemleri `batch` veya `transaction` kullanılarak gerçekleştirilir. Bir toplu işlem (`batch`), birden fazla yazma işlemini (silme, ayarlama, güncelleme) atomik olarak, yani hepsinin başarılı olması veya hepsinin başarısız olması şartıyla gruplamanıza olanak tanır. İşlemler (`transaction`), aynı anda birden fazla istemcinin değiştirebileceği ve okuma-yazma tutarlılığı gerektiren belgeler üzerinde karmaşık güncellemeler için kullanılır.
Ölçeklenebilirlik ve Maliyet
Firestore'un ölçeklenebilir doğası, tasarım kararlarının doğrudan maliyetleri ve uzun vadeli performansı nasıl etkilediğini anlamayı gerektirir. Firestore, okuma, yazma, silme işlemleri ve ağdan aktarılan veri miktarı üzerinden fiyatlandırılır. Bu nedenle, verimsiz bir sorgu veya aşırı büyük belge yapısı, beklenmedik şekilde yüksek faturalara yol açabilir. Maliyet optimizasyonunun ilk adımı, veri modelinin, uygulamanın en yaygın erişim modelleri için okuma sayısını en aza indirecek şekilde olmasını sağlamaktır. Örneğin, bir blog uygulamasında, yalnızca özet bilgilerin listelendiği ana sayfa için tüm gönderi içeriğini değil, yalnızca başlık, özet ve yazar gibi alanları getiren bir sorgu kullanmak daha verimlidir.
Yazma işlemleri de aynı derecede kritiktir. Saniyede yalnızca bir kez güncellenmesi gereken bir belgeye, saniyede binlerce yazma girişimi (örneğin, viral bir sosyal medya gönderisindeki beğeni sayacı), kotaları aşabilir ve hatalara neden olabilir. Bu sorunu çözmek için Firestore, sayac parçalama (sharding) gibi desenler önerir. Bu desende, sayac, rastgele seçilmiş birden fazla belgeye dağıtılır, böylece yazma yükü birden fazla belge arasında paylaştırılır ve tek bir belge üzerindeki yazma baskısı azaltılır. Bu, saniyede binlerce güncellemeyi karşılayacak şekilde ölçeklenebilir bir sayaç oluşturmanın temel yöntemidir.
Firestore'un otomatik ölçeklendirme özelliği, geliştiriciden altyapı yönetimi yükünü kaldırırken, dizin yönetimi gibi konularda dikkat gerektirir. Her yeni bileşik sorgu kombinasyonu, arka planda otomatik olarak bir dizin oluşturabilir. Kontrolsüz bir şekilde büyüyen dizin koleksiyonları, depolama maliyetlerini artırabilir ve hatta yazma performansını etkileyebilir. `firestore.indexes.json` dosyası ile dizin oluşturmayı otomatik yerine manuel moda alarak, yalnızca kesinlikle gerekli olan bileşik dizinleri tanımlamak ve bu maliytleri kontrol altında tutmak mümkündür. Ayrıca, verilerin yaşam döngüsünü yönetmek için TTL (Time-To-Live) politikaları kullanılabilir; bu, belirli bir süre sonra otomatik olarak silinecek geçici veriler (oturumlar, önbellek girdileri) için idealdir ve depolama maliyetlerini düşürür.
Ölçeklenebilir ve maliyet açısından verimli bir Firestore veritabanı tasarlamak, sürekli bir izleme ve iyileştirme süreci gerektirir. Aşağıdaki tablo, temel optimizasyon alanlarını ve bunlara yönelik stratejileri özetlemektedir:
| Optimizasyon Hedefi | Strateji | Etkisi |
|---|---|---|
| Okuma Maliyetini Azaltma | Denormalizasyon, daha küçük belgeler, sorgu filtreleme. | Getirilen belge sayısını ve boyutunu düşürür. |
| Yazma Ölçeklenebilirliği | Sayac parçalama (sharding), toplu yazma işlemleri. | Tek belge üzerindeki yazma baskısını dağıtır, hata oranlarını düşürür. |
| Depolama Maliyetini Kontrol | TTL politikaları, gereksiz dizinleri kaldırma, eski verileri arşivleme. | Depolanan toplam veri miktarını azaltır. |
| Sorgu Performansı | Gerekli dizinleri tanımlama, eşitlik filtrelerini sıralamadan önce kullanma. | Sorgu yanıt sürelerini hızlandırır. |
Güvenlik ve Performans
Firestore güvenliği, esnek ve ifade gücü yüksek Güvenlik Kuralları (Security Rules) ile sağlanır. Bu kurallar, veritabanı katmanında kimlik doğrulama ve yetkilendirmeyi zorunlu kılar, sunucusuz mimariler için kritik bir koruma katmanı oluşturur. Kurallar, erişimi kullanıcının kimliğine, belgenin mevcut verilerine ve gelen isteğin niteliğine göre tanımlamanıza olanak tanır. Örneğin, yalnızca bir belgenin sahibinin onu güncelleyebilmesini veya belirli alanların herkese açık okunabilir olmasını sağlamak mümkündür. Kuralların doğru yazılması ve test edilmesi, veri sızıntılarını veya yetkisiz değişiklikleri önlemenin temelidir. Ayrıca, kurallar performansı doğrudan etkilemez; tüm doğrulamalar Firestore altyapısında yüksek hızda gerçekleştirilir.
Performans optimizasyonu, güvenlik kadar önemli bir operasyonel konudur. İstemci tarafı önbellekleme, Firestore SDK'larının temel bir özelliğidir. Çevrimdışı veri erişimini mümkün kılar ve ağ gecikmelerini azaltmak için önbelleğe alınmış verileri kullanır. Ancak, bu önbelleğin boyutunun yönetimi önemlidir. Büyük sorgu sonuçlarının önbelleğe alınması, cihaz depolamasını hızla doldurabilir. Gereksiz verilerin önbelleğe alınmasını önlemek için sorgularda `source` seçeneği (`server`, `cache` veya `default`) kullanılabilir. Ayrıca, `persistenceCacheSizeBytes` ayarı ile önbellek boyutu sınırlanabilir, böylece uygulamanın bellek kullanımı kontrol altında tutulur.
Sorgu performansı, tasarım ve dizinleme ile doğrudan ilişkilidir. Bir sorgunun etkinliği, kullandığı dizin türüne ve getirdiği belge sayısına bağlıdır. Bileşik sorgular için özel dizinlerin tanımlanmaması, "index eksik" hatalarına ve zaman aşımlarına yol açar. Performansı artırmak için, mümkün olduğunca dar kapsamlı filtreler kullanmak ve `limit()` yan tümcesi ile getirilen belge sayısını kısıtlamak esastır. Ayrıca, sorgu birleştirme işlemlerinin Firestore'da bulunmaması, verilerin önceden birleştirilmiş şekilde (denormalize) yapılandırılmasını gerektirir; bu da okuma performansını en üst düzeye çıkarırken, yazma işlemlerini daha karmaşık hale getirir.
Gerçek zamanlı güncellemelerin performans üzerinde de etkisi vardır. Çok sayıda aktif `onSnapshot` dinleyicisi, hem istemci hem de sunucu kaynaklarını tüketebilir. Dinleyiciler yalnızca kesinlikle gerekli olduğunda kullanılmalı ve bileşen yaşam döngüsüne uygun şekilde temizlenmelidir. Dinamik sorgular (kullanıcı girişine göre değişen) kullanırken, dinleyicinin yeniden oluşturulmasından önce eski dinleyicinin kaldırılması, kaynak çakışmalarını ve bellek sızıntılarını önler. Firestore'un yayın-üyelik modeli verimli olsa da, kontrolsüz abonelikler maliyeti artırır.
Güvenlik ve performans birbirini tamamlayan disiplinlerdir. Aşırı karmaşık güvenlik kuralları, teorik olarak istek işleme süresini milisaniye düzeyinde etkileyebilse de, asıl etki yanlış kuralların neden olduğu gereksiz veri okumaları veya reddedilen geçerli isteklerde ortaya çıkar. Bu nedenle, kurallar yalnızca güvenli değil, aynı zamanda verimli erişim desenlerine izin verecek şekilde yazılmalıdır. Örneğin, bir koleksiyondaki tüm belgeleri listelemek için yapılan bir okuma isteğinde, kural motorunun her bir belgeyi ayrı ayrı değerlendirmek yerine, koleksiyon düzeyinde bir genel izin vermesi daha verimlidir. Düzenli güvenlik kuralı denetimleri ve Firestore Emülatörü ile performans testleri, güvenli ve hızlı bir uygulamanın sürdürülebilirliğini sağlar.