Sunucusuz uygulamanızı saniyede binlerce işlem veya yüz binlerce eşzamanlı kullanıcıya ölçeklendirme konusunda rehberlik için bu dokümanı okuyun. Bu belgede, sistemi ayrıntılı bir şekilde anlamanıza yardımcı olacak ileri düzey konular yer almaktadır. Cloud Firestore kullanmaya yeni başlıyorsanız hızlı başlangıç kılavuzuna göz atın.
Cloud Firestore ve Firebase mobil/web SDK'ları, istemci tarafı kodun veritabanına doğrudan eriştiği sunucusuz uygulamalar geliştirmek için güçlü bir model sunar. SDK'lar, istemcilerin verilerdeki güncellemeleri gerçek zamanlı olarak dinlemesine olanak tanır. Sunucu altyapısı gerektirmeyen duyarlı uygulamalar oluşturmak için gerçek zamanlı güncellemeleri kullanabilirsiniz. Bir şeyi çalışır hale getirmek çok kolay olsa da Cloud Firestore'ı oluşturan sistemlerdeki kısıtlamaları anlamak, sunucusuz uygulamanızın ölçeklenmesine ve trafik arttığında iyi performans göstermesine yardımcı olur.
Uygulamanızı ölçeklendirmeyle ilgili tavsiyeler için aşağıdaki bölümlere bakın.
Kullanıcılarınıza yakın bir veritabanı konumu seçme
Aşağıdaki şemada, gerçek zamanlı bir uygulamanın mimarisi gösterilmektedir:
Kullanıcının cihazında (mobil veya web) çalışan bir uygulama Cloud Firestore ile bağlantı kurduğunda bağlantı, veritabanınızın bulunduğu bölgedeki bir Cloud Firestore ön uç sunucusuna yönlendirilir. Örneğin, veritabanınız us-east1 bölgesindeyse bağlantı, yine us-east1 bölgesinde bulunan bir Cloud Firestore ön ucuna gider. Bu bağlantılar uzun ömürlüdür ve uygulama tarafından açıkça kapatılana kadar açık kalır. Ön uç, temel Cloud Firestore depolama sistemlerinden veri okur.
Kullanıcının fiziksel konumu ile Cloud Firestore veritabanı konumu arasındaki mesafe, kullanıcının deneyimlediği gecikmeyi etkiler. Örneğin, Hindistan'daki bir kullanıcının uygulaması Kuzey Amerika'daki bir Google Cloud bölgesinde bulunan veritabanıyla iletişim kuruyorsa kullanıcı, veritabanının Hindistan veya Asya'nın başka bir yerinde olduğu duruma kıyasla daha yavaş bir deneyim yaşayabilir ve uygulamanın daha yavaş çalıştığını hissedebilir.
Güvenilirliği göz önünde bulundurarak tasarım yapma
Aşağıdaki konular uygulamanızın güvenilirliğini artırır veya etkiler:
Çevrimdışı modu etkinleştirme
Firebase SDK'ları, çevrimdışı veri kalıcılığı sağlar. Kullanıcının cihazındaki uygulama Cloud Firestore hizmetine bağlanamazsa yerel olarak önbelleğe alınmış verilerle çalışarak kullanılabilir durumda kalır. Bu sayede, kullanıcılar internet bağlantısı kesintileri yaşasa veya birkaç saat ya da gün boyunca erişimi tamamen kaybetse bile verilere erişebilir. Çevrimdışı mod hakkında daha fazla bilgi için Çevrimdışı verileri etkinleştirme başlıklı makaleyi inceleyin.
Otomatik yeniden denemeleri anlama
Firebase SDK'ları, işlemleri yeniden dener ve kopan bağlantıları yeniden kurar. Bu, sunucuların yeniden başlatılmasından veya istemci ile veritabanı arasındaki ağ sorunlarından kaynaklanan geçici hataların giderilmesine yardımcı olur.
Bölgesel ve çok bölgeli konumlar arasında seçim yapma
Bölgesel ve çok bölgeli konumlar arasında seçim yaparken göz önünde bulundurulması gereken birkaç nokta vardır. Temel fark, verilerin nasıl kopyalandığıdır. Bu, uygulamanızın kullanılabilirlik garantilerini belirler. Çok bölgeli bir örnek, daha güçlü sunum güvenilirliği sağlar ve verilerinizin dayanıklılığını artırır ancak maliyet açısından dezavantajlıdır.
Gerçek zamanlı sorgu sistemini anlama
Anlık görüntü dinleyicileri olarak da adlandırılan gerçek zamanlı sorgular, uygulamanın veritabanındaki değişiklikleri dinlemesine ve veriler değiştiğinde düşük gecikmeli bildirimler almasına olanak tanır. Bir uygulama, güncellemeler için veritabanını düzenli olarak sorgulayarak aynı sonucu elde edebilir ancak bu genellikle daha yavaş ve daha pahalıdır, ayrıca daha fazla kod gerektirir. Gerçek zamanlı sorguların nasıl ayarlanacağı ve kullanılacağıyla ilgili örnekler için Gerçek zamanlı güncellemeler alma başlıklı makaleyi inceleyin. Aşağıdaki bölümlerde, anlık görüntü dinleyicilerin işleyiş şekli ayrıntılı olarak açıklanmakta ve performansı korurken gerçek zamanlı sorguları ölçeklendirmeyle ilgili en iyi uygulamalardan bazıları anlatılmaktadır.
Mobil SDK'lardan biriyle oluşturulmuş bir mesajlaşma uygulaması aracılığıyla Cloud Firestore hizmetine bağlanan iki kullanıcı düşünün.
A istemcisi, chatroom adlı koleksiyona doküman eklemek ve koleksiyondaki dokümanları güncellemek için veritabanına yazar:
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
B istemcisi, anlık görüntü dinleyici kullanarak aynı koleksiyondaki güncellemeleri dinler. B müşterisi, bir kullanıcı yeni mesaj oluşturduğunda anında bildirim alır. Aşağıdaki şemada, anlık görüntü dinleyicinin arkasındaki mimari gösterilmektedir:
B istemcisi veritabanına bir anlık görüntü dinleyici bağladığında aşağıdaki etkinlik sırası gerçekleşir:
- B istemcisi, Cloud Firestore ile bağlantı kurar ve Firebase SDK'sı üzerinden
onSnapshot(collection("chatroom"))yöntemini çağırarak bir dinleyici kaydeder. Bu dinleyici saatlerce etkin kalabilir. - Cloud Firestore ön ucu, veri kümesini başlatmak için temel depolama sistemini sorgular. Eşleşen dokümanların tüm sonuç kümesini yükler. Buna yoklama sorgusu denir. Sistem daha sonra, kullanıcının bu verilere erişebildiğini doğrulamak için veritabanının Firebase Güvenlik Kuralları'nı değerlendirir. Kullanıcı yetkilendirilmişse veritabanı, verileri kullanıcıya döndürür.
- B müşterisinin sorgusu daha sonra dinleme moduna geçer. Dinleyici, bir abonelik işleyiciye kaydolur ve verilerle ilgili güncellemeleri bekler.
- A istemcisi, bir dokümanı değiştirmek için yazma işlemi gönderir.
- Veritabanı, doküman değişikliğini depolama sistemine kaydeder.
- İşlem açısından sistem, aynı güncellemeyi dahili bir değişiklik günlüğüne kaydeder. Değişiklik günlüğü, değişiklikleri gerçekleştikleri sıraya göre katı bir şekilde sıralar.
- Değişiklik günlüğü de güncellenen verileri bir abonelik işleyici havuzuna dağıtır.
- Güncellenen belgenin kayıtlı anlık görüntü dinleyicileriyle eşleşip eşleşmediğini görmek için bir ters sorgu eşleştirici yürütülür. Bu örnekte doküman, B istemcisinin anlık görüntü dinleyicisiyle eşleşir. Adından da anlaşılacağı üzere, ters sorgu eşleştiriciyi normal bir veritabanı sorgusunun tersine çevrilmiş hali olarak düşünebilirsiniz. Bir sorguyla eşleşen dokümanları bulmak için dokümanlar arasında arama yapmak yerine, gelen bir dokümanla eşleşen sorguları bulmak için sorgular arasında verimli bir şekilde arama yapar. Eşleşme bulunduğunda sistem, söz konusu dokümanı anlık görüntü dinleyicilerine yönlendirir. Ardından sistem, yalnızca yetkili kullanıcıların verileri aldığından emin olmak için veritabanının Firebase Güvenlik Kuralları'nı değerlendirir.
- Sistem, doküman güncellemesini B istemcisinin cihazındaki SDK'ya yönlendirir ve
onSnapshotgeri çağırma işlevi tetiklenir. Yerel kalıcılık etkinleştirilirse SDK, güncellemeyi yerel önbelleğe de uygular.
Cloud Firestore'ın ölçeklenebilirliğinin önemli bir kısmı, değişiklik günlüğünden abonelik işleyicilere ve ön uç sunucularına yapılan fan-out işlemine bağlıdır. Fan-out, tek bir veri değişikliğinin milyonlarca gerçek zamanlı sorguya ve bağlı kullanıcıya hizmet verecek şekilde verimli bir şekilde yayılmasını sağlar. Cloud Firestore, tüm bu bileşenlerin birden fazla alt bölgede (veya çok bölgeli dağıtım söz konusuysa birden fazla bölgede) birçok replikasını çalıştırarak yüksek kullanılabilirlik ve ölçeklenebilirlik sağlar.
Mobil ve web SDK'larından gönderilen tüm okuma işlemlerinin yukarıdaki modeli izlediğini belirtmekte fayda var. Tutarlılık garantilerini sürdürmek için bir yoklama sorgusu ve ardından dinleme modu gerçekleştirirler. Bu durum, gerçek zamanlı dinleyiciler, belge alma çağrıları ve tek seferlik sorgular için de geçerlidir. Tek belge alma ve tek seferlik sorguları, performansla ilgili benzer kısıtlamalara sahip kısa süreli anlık görüntü dinleyiciler olarak düşünebilirsiniz.
Gerçek zamanlı sorguları ölçeklendirmeyle ilgili en iyi uygulamalardan yararlanın
Ölçeklenebilir gerçek zamanlı sorgular tasarlamak için aşağıdaki en iyi uygulamaları kullanın.
Sistemdeki yüksek yazma trafiğini anlama
Bu bölüm, sistemin artan yazma isteklerine nasıl yanıt verdiğini anlamanıza yardımcı olur.
Anlık sorguları yönlendiren Cloud Firestore değişiklik günlükleri, yazma trafiği arttıkça otomatik olarak yatay ölçeklendirilir. Bir veritabanının yazma hızı, tek bir sunucunun işleyebileceğinden daha fazla arttığında değişiklik günlüğü birden fazla sunucuya bölünür ve sorgu işleme, bir yerine birden fazla abonelik işleyiciden veri tüketmeye başlar. İstemci ve SDK açısından bu durum tamamen şeffaftır ve bölme işlemi gerçekleştiğinde uygulamada herhangi bir işlem yapılması gerekmez. Aşağıdaki şemada, gerçek zamanlı sorguların nasıl ölçeklendirildiği gösterilmektedir:
Otomatik ölçeklendirme, yazma trafiğinizi sınırlama olmaksızın artırmanıza olanak tanır ancak trafik arttıkça sistemin yanıt vermesi biraz zaman alabilir. Yazma etkin nokta oluşturmaktan kaçınmak için 5-5-5 kuralının önerilerini uygulayın. Key Visualizer, yazma yoğunluklarını analiz etmek için kullanışlı bir araçtır.
Birçok uygulamanın öngörülebilir organik büyümesi vardır ve Cloud Firestore, önlem almadan bu büyümeyi karşılayabilir. Ancak büyük bir veri kümesini içe aktarma gibi toplu iş yükleri, yazma işlemlerini çok hızlı bir şekilde artırabilir. Uygulamanızı tasarlarken yazma trafiğinizin nereden geldiğini göz önünde bulundurun.
Yazma ve okuma işlemlerinin nasıl etkileşim kurduğunu anlama
Gerçek zamanlı sorgu sistemini, yazma işlemlerini okuyuculara bağlayan bir ardışık düzen olarak düşünebilirsiniz. Bir doküman oluşturulduğunda, güncellendiğinde veya silindiğinde değişiklik, depolama sisteminden kayıtlı dinleyicilere yayılır. Cloud Firestore'ın değişiklik günlüğü yapısı, güçlü tutarlılık sağlar. Bu sayede uygulamanız, veritabanının veri değişikliklerini kaydettiği zamana kıyasla sırasız olan güncellemelerle ilgili bildirimleri hiçbir zaman almaz. Bu sayede, veri tutarlılığıyla ilgili uç durumlar ortadan kaldırılarak uygulama geliştirme süreci basitleştirilir.
Bu bağlı ardışık düzen, etkin noktalara veya kilit çekişmesine neden olan bir yazma işleminin okuma işlemlerini olumsuz etkileyebileceği anlamına gelir. Yazma işlemleri başarısız olduğunda veya kısıtlama yaşandığında okuma işlemi, değişiklik günlüğünden tutarlı veriler gelmesini beklerken durabilir. Uygulamanızda bu durum yaşanırsa hem yavaş yazma işlemleri hem de sorgular için ilişkili yavaş yanıt süreleri görebilirsiniz. Bu sorundan kaçınmanın yolu, etkin noktalardan uzak durmaktır.
Belgeleri ve yazma işlemlerini küçük tutun
Anlık görüntü dinleyicilerle uygulama geliştirirken genellikle kullanıcıların veri değişikliklerini hızlı bir şekilde öğrenmesini istersiniz. Bunu başarmak için her şeyi küçük tutmaya çalışın. Sistem, onlarca alan içeren küçük belgeleri sistem üzerinden çok hızlı bir şekilde gönderebilir. Yüzlerce alan ve büyük miktarda veri içeren daha büyük dokümanların işlenmesi daha uzun sürer.
Benzer şekilde, gecikmeyi düşük tutmak için kısa ve hızlı kaydetme ve yazma işlemlerini tercih edin. Büyük gruplar, yazma açısından daha yüksek işleme hızı sağlayabilir ancak anlık görüntü dinleyicilerinin bildirim süresini artırabilir. Bu, performansı artırmak için toplu işlem kullanabileceğiniz diğer veritabanı sistemlerini kullanmaya kıyasla genellikle sezgisel değildir.
Verimli dinleyiciler kullanma
Veritabanınızın yazma hızları arttıkça Cloud Firestore, veri işlemeyi birçok sunucuya böler. Cloud Firestore'ın parçalama algoritması, aynı koleksiyondan veya koleksiyon grubundan gelen verileri aynı değişiklik günlüğü sunucusunda birlikte konumlandırmaya çalışır. Sistem, bir sorgunun işlenmesinde yer alan sunucu sayısını mümkün olduğunca düşük tutarken olası yazma işleme hızını en üst düzeye çıkarmaya çalışır.
Ancak bazı kalıplar, anlık görüntü dinleyiciler için yine de ideal olmayan davranışlara yol açabilir. Örneğin, uygulamanız verilerinin çoğunu tek bir büyük koleksiyonda depoluyorsa dinleyicinin ihtiyaç duyduğu tüm verileri almak için birçok sunucuya bağlanması gerekebilir. Sorgu filtresi uygulasanız bile bu durum geçerlidir. Çok sayıda sunucuya bağlanmak, yanıtların yavaşlaması riskini artırır.
Bu yavaş yanıtları önlemek için şemanızı ve uygulamanızı, sistemin birçok farklı sunucuya gitmeden dinleyicilere hizmet verebileceği şekilde tasarlayın. Verilerinizi daha düşük yazma hızlarına sahip daha küçük koleksiyonlara bölmek en iyi sonucu verebilir.
Bu, ilişkisel veritabanında tam tablo taraması gerektiren performans sorgularını düşünmeye benzer. İlişkisel veritabanında, tam tablo taraması gerektiren bir sorgu, yüksek düzeyde kayıp içeren bir koleksiyonu izleyen anlık görüntü dinleyiciye eşdeğerdir. Veritabanının daha spesifik bir dizin kullanarak sunabileceği bir sorguya kıyasla yavaş çalışabilir. Daha spesifik bir dizine sahip sorgu, tek bir dokümanı veya daha az sıklıkta değişen bir koleksiyonu izleyen anlık görüntü dinleyiciye benzer. Kullanım alanınızın davranışını ve ihtiyacını en iyi şekilde anlamak için uygulamanızı yük testine tabi tutmanız gerekir.
Sorguları hızlı bir şekilde yoklamaya devam etme
Duyarlı gerçek zamanlı sorguların bir diğer önemli parçası da verileri önyüklemek için kullanılan yoklama sorgusunun hızlı ve verimli olmasını sağlamaktır. Yeni bir anlık görüntü dinleyici ilk kez bağlandığında, dinleyicinin tüm sonuç kümesini yüklemesi ve kullanıcının cihazına göndermesi gerekir. Yavaş sorgular, uygulamanızın yanıt verme hızını düşürür. Örneğin, çok sayıda belgeyi okumaya çalışan sorgular veya uygun dizinleri kullanmayan sorgular bu kapsamdadır.
Dinleyici, bazı durumlarda dinleme durumundan yoklama durumuna da geri dönebilir. Bu işlem otomatik olarak gerçekleşir ve SDK'lar ile uygulamanız için şeffaftır. Aşağıdaki koşullar, yoklama durumunu tetikleyebilir:
- Sistem, yükteki değişiklikler nedeniyle değişiklik günlüğünü yeniden dengeler.
- Yoğunluklar, veritabanına yazma işlemlerinin başarısız olmasına veya gecikmesine neden olur.
- Geçici sunucu yeniden başlatma işlemleri, dinleyicileri geçici olarak etkiler.
Sorgularınız yeterince hızlıysa yoklama durumu, uygulamanızın kullanıcıları için şeffaf hale gelir.
Uzun süreli dinleyicileri tercih etme
Dinleyicileri açmak ve mümkün olduğunca uzun süre canlı tutmak, genellikle Cloud Firestore kullanan bir uygulama oluşturmanın en uygun maliyetli yoludur. Cloud Firestore kullanırken açık bir bağlantıyı sürdürmek için değil, uygulamanıza döndürülen belgeler için faturalandırılırsınız. Uzun ömürlü bir anlık görüntü dinleyici, yalnızca kullanım ömrü boyunca sorguyu sunmak için ihtiyaç duyduğu verileri okur. Bu, ilk yoklama işlemini ve ardından veriler gerçekten değiştiğinde bildirimleri içerir. Tek seferlik sorgular ise uygulamanın sorguyu son yürütmesinden bu yana değişmemiş olabilecek verileri yeniden okur.
Uygulamanızın yüksek oranda veri tüketmesi gereken durumlarda anlık görüntü dinleyiciler uygun olmayabilir. Örneğin, kullanım alanınız uzun bir süre boyunca bir bağlantı üzerinden saniyede çok sayıda belge gönderiyorsa daha düşük sıklıkta çalışan tek seferlik sorguları tercih etmek daha iyi olabilir.
Sonraki Adımlar
- Anlık görüntü dinleyicileri nasıl kullanacağınızı öğrenin.
- Diğer en iyi uygulamalar hakkında bilgi edinin.