Sunucusuz uygulamanızı saniyede binlerce işlem veya yüz binlerce eşzamanlı kullanıcının ötesine ölçeklendirmeyle ilgili yol gösterici bilgiler için bu dokümanı okuyun. Bu belge, sistemi ayrıntılı olarak anlamanıza yardımcı olacak ileri düzey konuları içerir. Cloud Firestore'ü kullanmaya yeni başladıysanız hızlı başlangıç kılavuzuna göz atın.
Cloud Firestore ve Firebase mobil/web SDK'ları, istemci tarafı kodun doğrudan veritabanına eriştiği sunucusuz uygulamalar geliştirmek için güçlü bir model sağlar. 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 uygulamayı kullanıma sunmak çok kolay olsa da Cloud Firestore'ü oluşturan sistemlerdeki kısıtlamaları anlamak, sunucusuz uygulamanızın trafik arttığında ölçeklenmesine ve iyi performans göstermesine yardımcı olur.
Uygulamanızı ölçeklendirmeyle ilgili öneriler 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ı kurarken bağlantı, veritabanınızın bulunduğu bölgede bir Cloud Firestore ön uç sunucusuna yönlendirilir. Örneğin, veritabanınız us-east1'teyse bağlantı, us-east1'te bulunan bir Cloud Firestore ön uçuna da gider. Bu bağlantılar uzun ömürlüdür ve uygulama tarafından açıkça kapatılana kadar açık kalır. Kullanıcı arayüzü, 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 yaşadığı gecikmeyi etkiler. Örneğin, Hindistan'da bulunan ve uygulaması Kuzey Amerika'daki Google Cloud bölgesindeki bir veritabanıyla iletişim kuran bir kullanıcı, veritabanı Hindistan veya Asya'nın başka bir bölgesinde olsaydı deneyimin daha yavaş ve uygulamanın daha hantal olduğunu görebilir.
Güvenilirlik için tasarım yapma
Aşağıdaki konular uygulamanızın güvenilirliğini iyileştirir veya etkiler:
Çevrimdışı modu etkinleştirme
Firebase SDK'ları çevrimdışı veri koruması sağlar. Kullanıcının cihazındaki uygulama Cloud Firestore'e bağlanamazsa uygulama, yerel olarak önbelleğe alınmış verilerle çalışarak kullanılabilir durumda kalır. Bu sayede, kullanıcılar internet bağlantısında kesinti yaşadığında veya birkaç saat ya da gün boyunca erişimi tamamen kaybettiğinde 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
İşlemleri yeniden denemek ve bozuk bağlantıları yeniden kurmak Firebase SDK'larının görevidir. Bu, sunucuların yeniden başlatılmasından veya istemci ile veritabanı arasındaki ağ sorunlarından kaynaklanan geçici hataları gidermenize 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 birkaç ödünleşme vardır. Aradaki temel fark, verilerin kopyalama şeklidir. Bu, uygulamanızın kullanılabilirlik garantilerini belirler. Çok bölgeli bir örnek, daha güçlü yayınlama güvenilirliği sağlar ve verilerinizin dayanıklılığını artırır ancak bunun karşılığında maliyet artar.
Gerçek zamanlı sorgu sistemini anlama
Anlık görüntü dinleyicileri olarak da bilinen gerçek zamanlı sorgular, uygulamanın veritabanındaki değişiklikleri dinlemesine ve veriler değişir değişmez düşük gecikmeli bildirimler almasına olanak tanır. Bir uygulama, güncellemeler için veritabanını düzenli olarak sorgulayarak da aynı sonucu elde edebilir ancak bu yöntem genellikle daha yavaş, daha pahalı ve daha fazla kod gerektirir. Gerçek zamanlı sorguların nasıl ayarlanacağı ve kullanılacağıyla ilgili örnekler için Anlık güncellemeler alma başlıklı makaleyi inceleyin. Aşağıdaki bölümlerde, anlık görüntü dinleyicilerinin işleyişine dair ayrıntılı bilgi verilmektedir ve performansı korurken gerçek zamanlı sorguları ölçeklendirmeyle ilgili en iyi uygulamalardan bazıları açıklanmaktadır.
Mobil SDK'lardan biriyle oluşturulmuş bir mesajlaşma uygulaması aracılığıyla Cloud Firestore'e bağlanan iki kullanıcıyı düşünün.
A istemcisi, chatroom adlı bir koleksiyona doküman eklemek ve 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'
Müşteri B, anlık görüntü dinleyicisi kullanarak aynı koleksiyondaki güncellemeleri dinler. Müşteri B, bir kullanıcı yeni mesaj oluşturduğunda hemen bildirim alır. Aşağıdaki şemada, anlık görüntü dinleyicisinin arkasındaki mimari gösterilmektedir:
B istemcisi veritabanına bir anlık görüntü dinleyicisi bağladığında aşağıdaki etkinlik sırası gerçekleşir:
- B müşterisi, Cloud Firestore ile bağlantı açar ve Firebase SDK'sı üzerinden
onSnapshot(collection("chatroom"))'a çağrı yaparak bir dinleyici kaydeder. Bu dinleyici saatlerce etkin kalabilir. - Cloud Firestore kullanıcı arayüzü, veri kümesini başlatmak için temel depolama sistemini sorgular. Eşleşen dokümanların sonuç kümesinin tamamını yükler. Buna anket sorgusu denir. Ardından sistem, kullanıcının bu verilere erişip erişemediğini doğrulamak için veritabanının Firebase Güvenlik Kurallarını değerlendirir. Kullanıcı yetkiliyse veritabanı verileri kullanıcıya döndürür.
- Ardından B istemcisinin sorgusu dinleme moduna geçer. Dinleyici, bir abonelik işleyicisine kaydedilir ve verilerde güncelleme olmasını bekler.
- A müşterisi, bir dokümanı değiştirmek için yazma işlemi gönderir.
- Veritabanı, doküman değişikliğini depolama sistemine gönderir.
- Sistem, aynı güncellemeyi işlemsel olarak dahili bir günlük kaydına kaydeder. Değişiklik günlüğü, değişikliklerin gerçekleştiği sırada katı bir sıralama oluşturur.
- Değişiklik günlüğü de güncellenmiş verileri bir abonelik işleyici havuzuna dağıtır.
- Güncellenen belgenin şu anda 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 çalıştırılır. Bu örnekte, belge Müşteri B'nin anlık görüntü dinleyicisiyle eşleşir. Adından da anlaşılacağı gibi, ters sorgu eşleştiriciyi normal bir veritabanı sorgusu olarak düşünebilirsiniz ancak ters yönde yapılır. Bir sorguyla eşleşen dokümanları bulmak için dokümanlar arasında arama yapmak yerine, gelen bir dokümayla eşleşen sorguları verimli bir şekilde arar. Sistem, eşleşme bulduğunda söz konusu dokümanı anlık görüntü dinleyicilerine iletir. Ardından sistem, yalnızca yetkili kullanıcıların verileri almasını sağlamak için veritabanının Firebase Güvenlik Kurallarını değerlendirir.
- Sistem, belge güncellemesini B istemcisinin cihazındaki SDK'ya yönlendirir ve
onSnapshotgeri çağırma işlevi tetiklenir. Yerel kalıcılık etkinse 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şleyicilerine ve ön uç sunucularına yapılan dağıtıma bağlıdır. Yayma, tek bir veri değişikliğinin milyonlarca gerçek zamanlı sorguyu ve bağlı kullanıcıyı sunmak için verimli bir şekilde dağıtılmasına olanak tanır. Cloud Firestore, tüm bu bileşenlerin birden fazla kopyasını birden fazla bölgede (veya çok bölgeli dağıtım durumunda birden fazla bölgede) ç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 belirtmek isteriz. Tutarlılık garantilerini korumak için bir anket 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 işlemlerini ve tek seferlik sorguları, performansla ilgili benzer kısıtlamalara sahip kısa ömürlü anlık görüntü dinleyicileri olarak düşünebilirsiniz.
Gerçek zamanlı sorguları ölçeklendirmeyle ilgili en iyi uygulamaları uygulama
Ölçeklenebilir gerçek zamanlı sorgular tasarlamak için aşağıdaki en iyi uygulamaları uygulayın.
Sistemdeki yüksek yazma trafiğini anlama
Bu bölüm, sistemin artan sayıda yazma isteğine nasıl yanıt verdiğini anlamanıza yardımcı olur.
Gerçek zamanlı sorguları yönlendiren Cloud Firestore günlük değişiklikleri, yazma trafiği arttıkça otomatik olarak yatay olarak ölçeklenir. Bir veritabanındaki yazma hızı tek bir sunucunun kaldırabileceğ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 kullanmaya başlar. İstemci ve SDK açısından bu işlemler şeffaftır ve bölünmeler gerçekleştiğinde uygulamanın herhangi bir işlem yapmasına gerek yoktur. Aşağıdaki şemada, gerçek zamanlı sorguların nasıl ölçeklendirildiği gösterilmektedir:
Otomatik ölçeklendirme, yazma trafiğinizi sınırsız olarak artırmanıza olanak tanır ancak trafik arttıkça sistemin yanıt vermesi biraz zaman alabilir. Yazma hotspot'u oluşturmamak için 5-5-5 kuralı'nın önerilerini uygulayın. Key Visualizer, yazma yoğun noktalarını analiz etmek için kullanışlı bir araçtır.
Birçok uygulamanın öngörülebilen organik büyümesi vardır. Cloud Firestore, bu büyümeyi önleme tedbirleri almadan 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şimde bulunduğunu anlama
Gerçek zamanlı sorgu sistemini, yazma işlemlerini okuyucularla 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ü bir tutarlılık sağlar. Bu sayede uygulamanız, veritabanının veri değişikliklerini taahhüt ettiği zamana kıyasla sıra dışı güncelleme bildirimleri almaz. Bu sayede, veri tutarlılığıyla ilgili uç durumları ortadan kaldırarak uygulama geliştirmeyi basitleştirebilirsiniz.
Bu bağlı ardışık düzen, sıcak noktalara veya kilit anlaşmazlığına neden olan bir yazma işleminin okuma işlemlerini olumsuz yönde etkileyebileceği anlamına gelir. Yazma işlemleri başarısız olduğunda veya akış kısıtlaması uygulandığında, bir okuma işlemi değişiklik günlüğünden tutarlı veriler beklerken duraklatılabilir. 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 anahtarı, hotspot'lardan kaçınmaktır.
Dokümanları ve yazma işlemlerini küçük tutun
Uygulama geliştirirken, genellikle kullanıcıların veri değişikliklerini hızlı bir şekilde öğrenmesini istersiniz. Bunu yapmak için öğeleri küçük tutmaya çalışın. Sistem, onlarca alana sahip küçük dokümanları sistemden çok hızlı bir şekilde geçirebilir. Yüzlerce alan ve büyük veriler 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ı taahhüt ve yazma işlemlerini tercih edin. Büyük gruplar, yazar açısından daha yüksek bir aktarım hızı sağlayabilir ancak anlık görüntü dinleyicileri için bildirim süresini artırabilir. Bu, performansı artırmak için toplu işlem kullanabileceğiniz diğer veritabanı sistemlerinin kullanılmasına kıyasla genellikle mantık dışıdır.
Verimli dinleyiciler kullanın
Veritabanınınızın yazma hızları arttıkça Cloud Firestore, veri işlemeyi birçok sunucuya dağıtır. Cloud Firestore'ün bölümleme algoritması, aynı koleksiyon veya koleksiyon grubundaki verileri aynı günlük kaydı 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 verimini en üst düzeye çıkarmaya çalışır.
Ancak belirli kalıplar, anlık görüntü dinleyicileri için yine de en uygun olmayan davranışa neden olabilir. Ö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. Bu durum, sorgu filtresi uygulasanız bile geçerlidir. Birçok sunucuya bağlanmak, yanıtların daha yavaş gelmesi riskini artırır.
Bu yavaş yanıtları önlemek için şemanızı ve uygulamanızı, sistemin birçok farklı sunucuya gitmeden dinleyicilere içerik sunabileceği şekilde tasarlayın. Verilerinizi daha küçük yazma hızlarına sahip daha küçük koleksiyonlara ayırmak en iyi çözüm olabilir.
Bu, ilişkisel bir veritabanındaki tam tablo taraması gerektiren performans sorgularını düşünmeye benzer. İlişkisel bir veritabanında, tam tablo taraması gerektiren bir sorgu, yüksek değişim oranına sahip bir koleksiyonu izleyen anlık görüntü dinleyicisine eşdeğerdir. Veritabanının daha spesifik bir dizin kullanarak sunabileceği bir sorguya kıyasla yavaş performans gösterebilir. Daha spesifik bir dizin içeren bir sorgu, tek bir dokümanı veya daha seyrek değişen bir koleksiyonu izleyen bir anlık görüntü dinleyici gibidir. Kullanım alanınızı ve ihtiyacınızı en iyi şekilde anlamak için uygulamanızı yükleyip test etmeniz gerekir.
Yoklama sorgularının hızlı olmasını sağlama
Yanıt veren gerçek zamanlı sorguların diğer önemli bir parçası, verileri başlatmak için kullanılan anket sorgusunun hızlı ve verimli olmasını sağlamaktır. Yeni bir anlık görüntü dinleyicisi ilk kez bağlandığında dinleyici, sonuç kümesinin tamamını yükleyip kullanıcının cihazına göndermelidir. Yavaş sorgular, uygulamanızın daha az duyarlı olmasına neden olur. Örneğin, çok sayıda belgeyi okumaya çalışan veya uygun dizinleri kullanmayan sorgular buna örnek gösterilebilir.
Dinleyiciler bazı durumlarda dinleme durumundan anket 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, anket durumunu tetikleyebilir:
- Sistem, yükteki değişiklikler nedeniyle değişiklik günlüğünü yeniden dengeler.
- Hotspot'lar, veritabanına yazma işlemlerinin başarısız olmasına veya gecikmesine neden olur.
- Geçici sunucu yeniden başlatmaları dinleyicileri geçici olarak etkiler.
Anket sorgularınız yeterince hızlıysa anket durumu uygulamanızın kullanıcıları için şeffaf hale gelir.
Uzun süreli dinleyicileri tercih edin
Dinleyicileri mümkün olduğunca uzun süre uygulamada tutmak, genellikle Cloud Firestore kullanan bir uygulama oluşturmanın en uygun maliyetli yoludur. Cloud Firestore kullanırken, açık bağlantıyı sürdürmek için değil, uygulamanıza döndürülen dokümanlar için ücretlendirilirsiniz. Uzun ömürlü bir anlık görüntü dinleyicisi, yaşam süresi boyunca yalnızca sorguyu sunmak için ihtiyaç duyduğu verileri okur. Bu işlem, ilk yoklama işlemini ve ardından veriler gerçekten değiştiğinde bildirim göndermeyi içerir. Tek seferlik sorgular ise uygulamanın sorguyu en son yürütmesinden bu yana değişmemiş olabilecek verileri yeniden okur.
Uygulamanızın yüksek oranda veri kullanması gerektiği durumlarda anlık görüntü dinleyicileri uygun olmayabilir. Örneğin, kullanım alanınızda uzun bir süre boyunca saniyede çok sayıda belge gönderiliyorsa daha düşük sıklıkta çalışan tek seferlik sorguları tercih etmek daha iyi olabilir.
Sonraki Adımlar
- Anlık görüntü dinleyicilerini nasıl kullanacağınızı öğrenin.
- Diğer en iyi uygulamalar hakkında bilgi edinin.