Geniş ölçekte gerçek zamanlı sorguları anlama

Sunucusuz uygulamanızı saniyede binlerce işlem veya yüz binlerce eşzamanlı kullanıcıya göre ölçeklendirme konusunda rehberlik için bu belgeyi okuyun. Bu belgede, sistemi ayrıntılı olarak anlamanıza yardımcı olacak ileri düzey konular yer almaktadır. Cloud Firestore'yı yeni kullanmaya başladıysanız bunun yerine hızlı başlangıç kılavuzuna bakın.

Cloud Firestore ve Firebase mobil/web SDK'ları, istemci tarafı kodunun doğrudan veritabanına 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 kullanıma hazır hale getirmek çok kolay olsa da Cloud Firestore'ı oluşturan sistemlerdeki kısıtlamaları anlamak, trafiğin artması durumunda sunucusuz uygulamanızın iyi ölçeklenmesini ve performans göstermesini sağlar.

Uygulamanızı ölçeklendirme konusunda tavsiye almak için aşağıdaki bölümlere bakın.

Kullanıcılarınıza yakın bir veritabanı konumu seçin

Aşağıdaki şemada, anlık bir uygulamanın mimarisi gösterilmektedir:

Örnek gerçek zamanlı uygulama mimarisi

Bir 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 aynı Cloud Firestore ön uç sunucusuna yönlendirilir. Örneğin, veritabanınız us-east1 bölgesindeyse bağlantı da us-east1 bölgesindeki 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 yaşadığı gecikmeyi etkiler. Örneğin, uygulaması Kuzey Amerika'daki Google Cloud bölgesinde bulunan bir veritabanıyla iletişim kuran Hindistan'daki bir kullanıcı, veritabanı Hindistan veya Asya'nın başka bir bölümü gibi daha yakın bir yerde bulunuyorsa deneyimi daha yavaş ve uygulamayı daha az hızlı bulabilir.

Güvenilirliği göz önünde bulundurarak tasarım yapın

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'ya bağlanamıyorsa uygulama, yerel olarak önbelleğe alınan verilerle çalışarak kullanılabilir durumda kalır. Bu sayede, kullanıcılar kesintili internet bağlantısı 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

Firebase SDK'ları, işlemleri yeniden deneme ve bozuk bağlantıları yeniden kurma işlemlerini gerçekleştirir. Bu, sunucuların yeniden başlatılması veya istemci ile veritabanı arasındaki ağ sorunlarından kaynaklanan geçici hataları gidermeye 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 çeşitli ödünleşimler söz konusudur. Aradaki temel fark, verilerin nasıl kopyalandığıdır. Bu, uygulamanızın kullanılabilirlik garantilerini etkiler. Ç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, veritabanını güncellemeler için düzenli olarak yoklayarak aynı sonucu elde edebilir ancak bu yöntem genellikle daha yavaş, daha maliyetli 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 nasıl çalıştığı ayrıntılı olarak açıklanmakta ve performansı korurken gerçek zamanlı sorguları ölçeklendirmeye yönelik bazı en iyi uygulamalar açıklanmaktadır.

Mobil SDK'lardan biriyle oluşturulmuş bir mesajlaşma uygulaması aracılığıyla Cloud Firestore'ya bağlanan iki kullanıcı olduğunu varsayalım.

A müşterisi, chatroom adlı koleksiyona doküman eklemek ve 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ü dinleyicisi kullanarak aynı koleksiyondaki güncellemeleri dinler. B müşterisi, yeni bir mesaj oluşturulduğunda anında bildirim alır. Aşağıdaki şemada, anlık görüntü dinleyicisinin arkasındaki mimari gösterilmektedir:

Anlık görüntü işleyici bağlantısının mimarisi

İstemci B, veritabanına bir anlık görüntü dinleyicisi bağladığında aşağıdaki etkinlik sırası gerçekleşir:

  1. B istemcisi, Cloud Firestore ile bağlantı açar ve Firebase SDK'sı üzerinden onSnapshot(collection("chatroom"))'ye çağrı yaparak bir dinleyici kaydeder. Bu dinleyici saatlerce etkin kalabilir.
  2. Cloud Firestore ön ucu, veri kümesini başlatmak için temel depolama sistemini sorgular. Eşleşen belgelerin tüm sonuç kümesini yükler. Buna yoklama sorgusu diyoruz. Ardından sistem, 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.
  3. B istemcisinin sorgusu dinleme moduna geçer. Dinleyici, bir abonelik işleyicisine kaydolur ve verilerdeki güncellemeleri bekler.
  4. A istemcisi artık bir dokümanı değiştirmek için yazma işlemi gönderiyor.
  5. Veritabanı, doküman değişikliğini depolama sistemine işler.
  6. Sistem, işlemsel olarak aynı güncellemeyi dahili bir değişiklik günlüğüne işler. Değişiklik günlüğü, değişiklikleri gerçekleşme sırasına göre kesin bir şekilde sıralar.
  7. Değişiklik günlüğü de güncellenen verileri bir dizi abonelik işleyicisine dağıtır.
  8. Güncellenen belgenin, şu anda kayıtlı olan anlık görüntü işleyicilerle eşleşip eşleşmediğini görmek için ters sorgu eşleştirici çalıştırılır. Bu örnekte, doküman B müşterisinin anlık görüntü dinleyicisiyle eşleşiyor. Adından da anlaşılacağı gibi, ters sorgu eşleştiriciyi normal bir veritabanı sorgusu olarak düşünebilirsiniz ancak bu sorgu tersine yapılır. 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 almasını sağlamak için veritabanının Firebase güvenlik kurallarını değerlendirir.
  9. Sistem, doküman güncellemesini B istemcisinin cihazındaki SDK'ya iletir ve onSnapshot geri çağırma işlemi tetiklenir. Yerel kalıcılık etkinse SDK, güncellemeyi yerel önbelleğe de uygular.

Cloud Firestore'nı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. Yelpaze, tek bir veri değişikliğinin milyonlarca gerçek zamanlı sorguya ve bağlı kullanıcıya hizmet vermek için verimli bir şekilde yayılmasını sağlar. Cloud Firestore, tüm bu bileşenlerin birçok kopyasını birden fazla bölgede (çok bölgeli dağıtım durumunda birden fazla bölge) çalıştırarak yüksek kullanılabilirlik ve ölçeklenebilirlik elde eder.

Mobil ve web SDK'larından verilen tüm okuma işlemlerinin yukarıdaki modeli izlediğini belirtmekte fayda var. Tutarlılık garantilerini korumak için önce anket sorgusu, 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 dokümanlı alma işlemlerini ve tek görevli 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çeklendirmek için en iyi uygulamaları kullanı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 sayıda yazma isteğine nasıl yanıt verdiğini anlamanıza yardımcı olur.

Gerçek zamanlı sorguları yönlendiren Cloud Firestoredeğ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ğinin üzerine çıktığında değişiklik günlüğü birden fazla sunucuya bölünür ve sorgu işleme, tek bir abone işleyici yerine birden fazla abone işleyiciden veri tüketmeye başlar. İstemci ve SDK açısından bu işlemler tamamen şeffaftır ve bölme işlemi gerçekleştiğinde uygulamanın herhangi bir işlem yapması gerekmez. Aşağıdaki şemada, anlık sorguların nasıl ölçeklendirildiği gösterilmektedir:

Değişiklik günlüğü dağıtımının mimarisi

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ı önerilerine uyun. Key Visualizer, yazma etkin noktalarını analiz etmek için kullanışlı bir araçtır.

Birçok uygulama, öngörülebilir organik büyüme gösterir. Bu büyüme, Cloud Firestore önlem almadan karşılanabilir. 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ğine dikkat edin.

Yazma ve okuma işlemlerinin nasıl etkileşimde bulunduğunu anlama

Anlık sorgu sistemini, yazma işlemlerini okuyuculara bağlayan bir kanal olarak düşünebilirsiniz. Bir doküman oluşturulduğunda, güncellendiğinde veya silindiğinde değişiklik, depolama sisteminden şu anda kayıtlı olan dinleyicilere yayılır. Cloud Firestore'nın değişiklik günlüğü yapısı güçlü tutarlılığı garanti eder. Bu sayede uygulamanız, veritabanının veri değişikliklerini işlediği zamana kıyasla sırası bozulmuş güncellemelerle ilgili bildirimler almaz. Bu, veri tutarlılığıyla ilgili uç durumları kaldırarak uygulama geliştirmeyi basitleştirir.

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 sınırlama uygulandığında, okuma işlemi değişiklik günlüğünden tutarlı veriler beklenirken duraklayabilir. 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, hotspot'lardan uzak durmaktır.

Dokümanları ve yazma işlemlerini küçük tutun

Anlık görüntü dinleyicileriyle uygulama oluştururken genellikle kullanıcıların veri değişikliklerini hızlı bir şekilde öğrenmesini istersiniz. Bunu başarmak için öğeleri küçük tutmaya çalışın. Sistem, onlarca alan içeren küçük belgeleri sistem üzerinden çok hızlı bir şekilde iletebilir. Yüzlerce alan ve büyük veriler içeren daha büyük dokümanların işlenmesi daha uzun sürer.

Aynı şekilde, gecikmeyi düşük tutmak için kısa ve hızlı commit ve yazma işlemlerini tercih edin. Büyük gruplar, yazan tarafında daha yüksek işleme hızı sağlayabilir ancak anlık görüntü dinleyicileri için bildirim süresini artırabilir. Bu durum, performansı artırmak için gruplandırma kullanabileceğiniz diğer veritabanı sistemlerinin kullanımına kıyasla genellikle sezgisel değildir.

Verimli işleyiciler kullanın

Veritabanınızın yazma hızları arttıkça, Cloud Firestore veri işlemeyi birçok sunucuya böler. Cloud Firestore'nın parçalama algoritması, aynı koleksiyondaki veya koleksiyon grubundaki verileri aynı değişiklik günlüğü sunucusunda birlikte konumlandırmaya çalışır. Sistem, bir sorgunun işlenmesine dahil olan 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 belirli kalıplar, anlık görüntü dinleyicileri için yine de ideal olmayan davranışlara yol açabilir. Örneğin, uygulamanız verilerinin çoğunu büyük bir koleksiyonda saklıyorsa dinleyicinin ihtiyacı olan tüm verileri alabilmek için birçok sunucuya bağlanması gerekebilir. Bu durum, sorgu filtresi uygulasanız bile geçerliliğini korur. Birçok sunucuya bağlanmak, yanıtların yavaşlama 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 küçük yazma hızlarına sahip daha küçük koleksiyonlara ayırmak en iyi yöntem olabilir.

Bu, ilişkisel bir veritabanında tam tablo taramaları gerektiren performans sorgularını düşünmeye benzer. İlişkisel bir veritabanında, tam tablo taraması gerektiren bir sorgu, yüksek değişimli bir koleksiyonu izleyen bir anlık görüntü dinleyicisine eşdeğerdir. Veritabanının daha spesifik bir dizin kullanarak sunabileceği bir sorguya kıyasla yavaş çalışabilir. Daha spesifik bir indekse sahip sorgu, tek bir belgeyi veya daha az sıklıkta değişen bir koleksiyonu izleyen bir anlık görüntü dinleyicisine benzer. Kullanım alanınızın davranışını ve ihtiyaçlarını en iyi şekilde anlamak için uygulamanıza yük testi uygulamanız gerekir.

Yoklama sorgularını hızlı tutma

Hızlı yanıt veren gerçek zamanlı sorguların bir diğer önemli kısmı, verileri başlatmak 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 sonuç kümesinin tamamını yükleyip kullanıcının cihazına göndermesi gerekir. Yavaş sorgular, uygulamanızın daha az yanıt vermesine neden olur. Ö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.
  • Hotspot'lar, 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.

Yoklama sorgularınız yeterince hızlıysa yoklama durumu, uygulamanızın kullanıcıları için şeffaf hale gelir.

Uzun süreli işleyicileri tercih edin

Dinleyicileri mümkün olduğunca uzun süre açık tutmak ve etkin 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 dokümanlar için faturalandırılırsınız. Uzun süreli bir anlık görüntü dinleyicisi, sorguya hizmet vermek için ihtiyaç duyduğu verileri yalnızca yaşam döngüsü boyunca okur. Bu işlem, ilk yoklama işlemini ve ardından veriler gerçekten değiştiğinde gönderilen bildirimleri içerir. Diğer yandan, tek seferlik sorgular, uygulama sorguyu en son yürüttüğünden beri değişmemiş olabilecek verileri yeniden okur.

Uygulamanızın yüksek oranda veri tüketmesi gereken durumlarda anlık görüntü dinleyicileri uygun olmayabilir. Örneğin, kullanım alanınız uzun bir süre boyunca saniyede çok sayıda belgeyi bir bağlantı üzerinden gönderiyorsa daha düşük sıklıkta çalışan tek seferlik sorguları tercih etmek daha iyi olabilir.

Sonraki Adımlar