Cloud Firestore için en iyi uygulamalar

Cloud Firestore kullanan bir uygulama oluştururken hızlı referans olarak burada listelenen en iyi uygulamaları kullanın.

Veritabanı konumu

Veritabanı örneğinizi oluşturduğunuzda kullanıcılarınıza ve bilgi işlem kaynaklarınıza en yakın veritabanı konumunu seçin. Geniş kapsamlı ağ atlamaları hataya daha yatkındır ve sorgu gecikmesini artırır.

Uygulamanızın kullanılabilirliğini ve dayanıklılığını en üst düzeye çıkarmak için çok bölgeli bir konum seçin ve kritik bilgi işlem kaynaklarını en az iki bölgeye yerleştirin.

Uygulamanız gecikmeye duyarlıysa daha düşük yazma gecikmesi veya diğer GCP kaynaklarıyla ortak konum için daha düşük maliyetler için bölgesel bir konum seçin.

Belge Kimlikleri

  • Belge kimliklerinden kaçının . Ve .. .
  • Belge kimliklerinde / ileri eğik çizgileri kullanmaktan kaçının.
  • Aşağıdakiler gibi monoton olarak artan belge kimliklerini kullanmayın:

    • Customer1 , Customer2 , Customer3 , ...
    • Product 1 , Product 2 , Product 3 , ...

    Bu tür sıralı kimlikler, gecikmeyi etkileyen sıcak noktalara yol açabilir.

Alan Adları

  • Ekstra kaçış gerektirdiklerinden alan adlarında aşağıdaki karakterlerden kaçının:

    • . dönem
    • [ sol parantez
    • ] sağ parantez
    • * yıldız işareti
    • ` geri tıklama

Dizinler

Yazma gecikmesini azaltın

Yazma gecikmesine en çok katkıda bulunan faktör dizin yayılımıdır. Dizin yayılımını azaltmaya yönelik en iyi uygulamalar şunlardır:

  • Koleksiyon düzeyinde dizin muafiyetlerini ayarlayın. Kolay bir varsayılan, Azalan ve Dizi indekslemeyi devre dışı bırakmaktır. Kullanılmayan indekslenmiş değerlerin kaldırılması depolama maliyetlerini de düşürecektir.

  • Bir işlemdeki belge sayısını azaltın. Çok sayıda belge yazmak için atomik toplu yazıcı yerine toplu yazıcı kullanmayı düşünün.

Dizin muafiyetleri

Çoğu uygulamada, dizinlerinizi yönetmek için otomatik dizine eklemenin yanı sıra hata mesajı bağlantılarına da güvenebilirsiniz. Ancak aşağıdaki durumlarda tek alanlı muafiyetler eklemek isteyebilirsiniz:

Dava Tanım
Büyük dize alanları

Sorgulama için kullanmadığınız, genellikle uzun dize değerlerini tutan bir dize alanınız varsa, alanı dizin oluşturma işleminden muaf tutarak depolama maliyetlerini azaltabilirsiniz.

Sıralı değerlere sahip belgeler içeren bir koleksiyona yüksek yazma oranları

Zaman damgası gibi bir koleksiyondaki belgeler arasında sırayla artan veya azalan bir alanı dizine eklerseniz koleksiyona maksimum yazma hızı saniyede 500 yazma olur. Sıralı değerlere sahip alanı temel alarak sorgulama yapmazsanız bu sınırı atlamak için alanı indekslemeden muaf tutabilirsiniz.

Örneğin, yazma hızının yüksek olduğu bir IoT kullanım durumunda, zaman damgası alanına sahip belgeleri içeren bir koleksiyon, saniyede 500 yazma sınırına yaklaşabilir.

TTL alanları

TTL (yaşam süresi) politikaları kullanıyorsanız TTL alanının bir zaman damgası olması gerektiğini unutmayın. TTL alanlarında dizine ekleme varsayılan olarak etkindir ve daha yüksek trafik hızlarında performansı etkileyebilir. En iyi uygulama olarak TTL alanlarınız için tek alanlı muafiyetler ekleyin.

Büyük dizi veya harita alanları

Büyük dizi veya harita alanları, belge başına 40.000 dizin girişi sınırına yaklaşabilir. Büyük bir dizi veya harita alanına göre sorgulama yapmıyorsanız, onu indekslemeden muaf tutmalısınız.

Okuma ve yazma işlemleri

  • Bir uygulamanın tek bir belgeyi güncelleyebileceği tam maksimum hız, büyük ölçüde iş yüküne bağlıdır. Daha fazla bilgi için bkz. Tek bir belgede yapılan güncellemeler .

  • Mümkün olduğunda senkronize aramalar yerine senkronize olmayan aramaları kullanın. Eşzamansız çağrılar gecikme etkisini en aza indirir. Örneğin, bir yanıt oluşturmadan önce bir belge aramasının sonucuna ve bir sorgunun sonuçlarına ihtiyaç duyan bir uygulamayı düşünün. Arama ve sorgunun veri bağımlılığı yoksa, sorguyu başlatmadan önce aramanın tamamlanmasını eşzamanlı olarak beklemeye gerek yoktur.

  • Ofsetleri kullanmayın. Bunun yerine imleçleri kullanın. Ofset kullanmak yalnızca atlanan belgelerin uygulamanıza geri gönderilmesini önler ancak bu belgeler yine de dahili olarak alınır. Atlanan belgeler sorgunun gecikme süresini etkiler ve uygulamanız, bunları almak için gereken okuma işlemleri için faturalandırılır.

İşlem yeniden denemeleri

Cloud Firestore SDK'ları ve istemci kitaplıkları, geçici hatalarla başa çıkmak için başarısız işlemleri otomatik olarak yeniden dener. Uygulamanız Cloud Firestore'a SDK yerine doğrudan REST veya RPC API'leri aracılığıyla erişiyorsa uygulamanızın güvenilirliği artırmak için işlem yeniden denemeleri uygulaması gerekir.

Gerçek zamanlı güncellemeler

Gerçek zamanlı güncellemelerle ilgili en iyi uygulamalar için bkz. Gerçek zamanlı sorguları geniş ölçekte anlama .

Ölçek için tasarlama

Aşağıdaki en iyi uygulamalar, çekişme sorunları yaratan durumlardan nasıl kaçınılacağını açıklamaktadır.

Tek bir belgedeki güncellemeler

Uygulamanızı tasarlarken uygulamanızın tek belgeleri ne kadar hızlı güncellediğini düşünün. İş yükünüzün performansını karakterize etmenin en iyi yolu yük testi yapmaktır. Bir uygulamanın tek bir belgeyi güncelleyebileceği tam maksimum hız, büyük ölçüde iş yüküne bağlıdır. Faktörler arasında yazma hızı, istekler arasındaki çekişme ve etkilenen dizin sayısı yer alır.

Bir belge yazma işlemi, belgeyi ve ilişkili tüm dizinleri günceller ve Cloud Firestore, yazma işlemini bir kopya yeter sayısı genelinde eşzamanlı olarak uygular. Yeterince yüksek yazma hızlarında veritabanı çekişme, daha yüksek gecikme veya diğer hatalarla karşılaşmaya başlayacaktır.

Dar bir belge aralığında yüksek okuma, yazma ve silme oranları

Belgeleri sözlükbilimsel olarak kapatmak için yüksek okuma veya yazma hızlarından kaçının, aksi takdirde uygulamanızda çekişme hataları yaşanacaktır. Bu sorun, etkin noktalanma olarak bilinir ve uygulamanız aşağıdakilerden herhangi birini yaparsa etkin noktalanma yaşayabilir:

  • Çok yüksek oranda yeni belgeler oluşturur ve kendi monoton artan kimliklerini tahsis eder.

    Cloud Firestore, belge kimliklerini bir dağılım algoritması kullanarak tahsis eder. Otomatik belge kimliklerini kullanarak yeni belgeler oluşturursanız, yazma sırasında sıcak nokta sorunuyla karşılaşmamalısınız.

  • Az belgeli bir koleksiyonda yüksek oranda yeni belge oluşturur.

  • Zaman damgası gibi monoton olarak artan bir alana sahip yeni belgeleri çok yüksek bir oranda oluşturur.

  • Bir koleksiyondaki belgeleri yüksek oranda siler.

  • Trafiği kademeli olarak artırmadan veritabanına çok yüksek bir hızda yazar.

Silinen verileri atlamaktan kaçının

Yakın zamanda silinen verileri atlayan sorgulardan kaçının. İlk sorgu sonuçları yakın zamanda silinmişse, bir sorgunun çok sayıda dizin girişini atlaması gerekebilir.

Çok sayıda silinmiş veriyi atlamak zorunda kalabilecek bir iş yükü örneği, kuyruğa alınmış en eski iş öğelerini bulmaya çalışan bir iş yüküdür. Sorgu şöyle görünebilir:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

Bu sorgu her çalıştırıldığında, yakın zamanda silinmiş belgelerde created alan için dizin girişlerini tarar. Bu, sorguları yavaşlatır.

Performansı artırmak amacıyla başlamak için en iyi yeri bulmak amacıyla start_at yöntemini kullanın. Örneğin:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

NOT: Yukarıdaki örnekte, yüksek yazma hızları için bir anti-model olan monoton olarak artan bir alan kullanılmaktadır.

Trafiği hızlandırmak

Cloud Firestore'a artan trafiğe yönelik belgeleri hazırlaması için yeterli zaman tanımak amacıyla, yeni koleksiyonlara giden trafiği kademeli olarak artırmalı veya belgeleri sözlükbilimsel olarak kapatmalısınız. Yeni bir koleksiyona saniyede maksimum 500 işlemle başlamanızı ve ardından trafiği her 5 dakikada bir %50 artırmanızı öneririz. Benzer şekilde yazma trafiğinizi de artırabilirsiniz ancak Cloud Firestore Standart Sınırlarını unutmayın. İşlemlerin anahtar aralığı boyunca nispeten eşit şekilde dağıtıldığından emin olun. Buna "500/50/5" kuralı denir.

Trafiği yeni bir koleksiyona taşıma

Uygulama trafiğini bir koleksiyondan diğerine taşıyorsanız, kademeli olarak artış özellikle önemlidir. Bu geçişi gerçekleştirmenin basit bir yolu, eski koleksiyondan okumak ve belge mevcut değilse yeni koleksiyondan okumaktır. Ancak bu, yeni koleksiyondaki belgelerin sözlükbilimsel olarak kapatılmasına yönelik trafikte ani bir artışa neden olabilir. Cloud Firestore, özellikle az sayıda belge içerdiğinde yeni koleksiyonu artan trafiğe verimli bir şekilde hazırlayamayabilir.

Aynı koleksiyondaki birçok belgenin belge kimliğini değiştirirseniz benzer bir sorun ortaya çıkabilir.

Trafiği yeni bir koleksiyona taşımak için en iyi strateji, veri modelinize bağlıdır. Aşağıda paralel okumalar olarak bilinen örnek bir strateji verilmiştir. Bu stratejinin verileriniz için etkili olup olmadığını belirlemeniz gerekecektir ve önemli bir husus, geçiş sırasında paralel operasyonların maliyet etkisi olacaktır.

Paralel okumalar

Trafiği yeni bir koleksiyona taşırken paralel okumalar uygulamak için önce eski koleksiyondan okuyun. Belge eksikse yeni koleksiyondan okuyun. Var olmayan belgelerin yüksek oranda okunması, sıcak nokta tespitine yol açabilir; bu nedenle, yeni koleksiyonun yükünü kademeli olarak artırdığınızdan emin olun. Daha iyi bir strateji, eski belgeyi yeni koleksiyona kopyalamak ve ardından eski belgeyi silmektir. Cloud Firestore'un yeni koleksiyona gelen trafiği yönetebilmesini sağlamak için paralel okumaları kademeli olarak artırın.

Yeni bir koleksiyona yönelik okuma veya yazma işlemlerini kademeli olarak artırmaya yönelik olası bir strateji, yeni belgeler yazmaya çalışan kullanıcıların rastgele bir yüzdesini seçmek için kullanıcı kimliğinin deterministik bir karmasını kullanmaktır. Kullanıcı kimliği karmasının sonucunun, işleviniz veya kullanıcı davranışı nedeniyle çarpık olmadığından emin olun.

Bu arada, tüm verilerinizi eski belgelerden yeni koleksiyona kopyalayan bir toplu iş çalıştırın. Toplu işiniz, sıcak noktaları önlemek için sıralı belge kimliklerine yazmaktan kaçınmalıdır. Toplu iş bittiğinde yalnızca yeni koleksiyondan okuyabilirsiniz.

Bu stratejinin geliştirilmiş hali, küçük kullanıcı gruplarını aynı anda taşımaktır. Kullanıcı belgesine, söz konusu kullanıcının geçiş durumunu izleyen bir alan ekleyin. Kullanıcı kimliğinin karmasına göre taşınacak bir grup kullanıcı seçin. Söz konusu kullanıcı grubu için belgeleri taşımak üzere bir toplu iş kullanın ve geçişin ortasındaki kullanıcılar için paralel okumaları kullanın.

Geçiş aşamasında hem eski hem de yeni varlıklara çift yazma işlemi yapmadığınız sürece kolayca geri dönemeyeceğinizi unutmayın. Bu, Cloud Firestore maliyetlerini artıracaktır.

Mahremiyet

  • Hassas bilgileri Bulut Proje Kimliğinde depolamaktan kaçının. Bulut Proje Kimliği projenizin ömrü boyunca saklanabilir.
  • Veri uyumluluğuyla ilgili en iyi uygulama olarak, hassas bilgilerin belge adlarında ve belge alan adlarında saklanmamasını öneririz.

Yetkisiz erişimi önleyin

Cloud Firestore Güvenlik Kuralları ile veritabanınızda yetkisiz işlemleri önleyin. Örneğin, kuralların kullanılması, kötü niyetli bir kullanıcının veritabanınızın tamamını tekrar tekrar indirdiği bir senaryoyu önleyebilir.

Cloud Firestore Güvenlik Kurallarını kullanma hakkında daha fazla bilgi edinin.