Cloud Firestore kullanan bir uygulama oluştururken burada listelenen en iyi uygulamaları hızlı referans olarak kullanın.
Veritabanı konumu
Veritabanı örneğinizi oluştururken kullanıcılarınıza ve bilgi işlem kaynaklarınıza en yakın veritabanı konumunu seçin. Uzak ağ atlamaları hatalara 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.
Yazma oranının daha düşük olması için maliyetlerin daha düşük olması amacıyla bölgesel konum seçin uygulamanız gecikmeye duyarlıysa veya diğer GCP kaynaklarıyla ortak konum için çözüm sunar.
Doküman kimlikleri
.ve..doküman kimliklerinden kaçının.- Belge kimliklerinde
/düz eğik çizgi kullanmaktan kaçının. Aşağıdakiler gibi monoton olarak artan doküman kimlikleri kullanmayın:
Customer1,Customer2,Customer3, ...Product 1,Product 2,Product 3, ...
Bu tür sıralı kimlikler, gecikmeyi etkileyen hotspot'lara yol açabilir.
Alan Adları
Ek kod dışına alma işlemi gerektirdikleri için alan adlarında aşağıdaki karakterleri kullanmaktan kaçının:
.dönemi[sol köşeli ayraç]sağ köşeli parantez*yıldız işareti`ters eğik çizgi
Dizinler
Yazma gecikmesini azaltma
Yazma gecikmesinde ana etken, dizin dağılmasıdır. Dizin dağıtımını azaltmak için en iyi uygulamalar şunlardır:
Koleksiyon düzeyinde dizin muafiyetlerini ayarlayın. Varsayılan olarak kolay bir yöntem, Azalan ve Dizi dizine ekleme. Dizine eklenen kullanılmayan değerlerin kaldırılması depolama alanı maliyetlerini de azaltır.
Bir işlemdeki belge sayısını azaltın. Çok sayıda belge yazmak için atomik toplu yazar yerine toplu yazar kullanmayı düşünün.
Dizin muafiyetleri
Çoğu uygulama için otomatik dizine eklemenin yanı sıra bağlantılarını kullanın. Ancak isterseniz tek alan muafiyetleri aşağıdaki durumlarda:
| Durum | Açıklama |
|---|---|
| Geniş dize alanları | Sorgulamak için kullanmadığınız uzun dize değerlerini sık sık barındıran bir dize alanınız varsa alanı dizine ekleme işleminden muaf tutarak depolama maliyetlerini düşürebilirsiniz. |
| Sıralı değerler içeren belgeler içeren bir koleksiyona yüksek yazma hızları | Bir koleksiyondaki belgeler arasında sırayla artan veya azalan bir alanı (ör. zaman damgası) dizine eklerseniz koleksiyona maksimum yazma hızı saniyede 500 yazma işlemidir. Sıralı değerlere sahip alana göre sorgu yapmıyorsanız bu sınırı aşmak için alanı dizine ekleme işleminden muaf tutabilirsiniz. Yüksek yazma hızına sahip bir IoT kullanım alanında (ör. zaman damgası alanı içeren dokümanlar içeren bir koleksiyon) saniye başına 500 yazma işlemi sınırına yaklaşılabilir. |
| TTL alanları |
TTL (geçerlilik süresi) politikalarını 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 performansı daha yüksek trafik oranlarında etkiler. En iyi uygulama olarak, TTL alanlarınıza tek alan muafiyetleri ekleyin. |
| Büyük dizi veya eşleme alanları | Büyük dizi veya eşleme alanları, doküman başına 40.000 dizin girişi sınırına yaklaşabilir. Büyük bir diziye veya harita alanına göre sorgu yapmıyorsanız bu alanı dizine ekleme kapsamı dışında tutmanız gerekir. |
Okuma ve yazma işlemleri
Bir uygulamanın tek bir dokümanı 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 Tek bir dokümanda güncelleme yapma başlıklı makaleyi inceleyin.
Uygun durumlarda, eşzamanlı çağrılar yerine eşzamansız çağrıları kullanın. Eşzamansız çağrılar gecikmenin etkisini en aza indirir. Örneğin, Yeşil Ofis projenizde önce bir doküman aramasının ve sorgunun sonuçlarını gerektiren bir yanıt oluşturabilirsiniz. Arama ve sorgu arasında veri bağımlılığı yoksa sorguyu başlatmadan önce aramanın tamamlanmasını eşzamanlı olarak beklemeniz gerekmez.
Ofset kullanmayın. Bunun yerine imleçler için de geçerlidir. Ofset kullanmak, yalnızca atlanan dokümanların uygulamanıza döndürülmesini önler ancak bu dokümanlar yine de dahili olarak alınır. Atlanan dokümanlar, dokümanın ve uygulamanız, her bir kullanıcı için gereken okuma geri yükleyebilirsiniz.
İşlem yeniden denemeleri
Cloud Firestore SDK'ları ve istemci kitaplıklar otomatik olarak yeniden deneme başarısız oldu geçici hataları çözmek için kullanır. Uygulamanız Cloud Firestore'e bir SDK üzerinden değil, doğrudan REST veya RPC API'leri üzerinden erişiyorsa güvenilirliği artırmak için işlem yeniden denemelerini uygulamalıdır.
Gerçek zamanlı güncellemeler
Gerçek zamanlı güncellemelerle ilgili en iyi uygulamalar için Gerçek zamanlı sorguları ölçekte anlama başlıklı makaleyi inceleyin.
Ölçeklendirilebilecek tasarımlar yapma
Aşağıdaki en iyi uygulamalarda, anlaşmazlık sorunlarına yol açan durumların nasıl önleneceği açıklanmaktadır.
Tek bir dokümanda yapılan güncellemeler
Uygulamanızı tasarlarken uygulamanızın tek bir dokümanı 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 dokümanı güncelleyebileceği tam maksimum hız önemli ölçüde iş yüküne bağlıdır. Etkenler arasında yazma hızı, istekler arasındaki çekişme ve etkilenen dizin sayısı bulunur.
Belge yazma işlemi, belgeyi ve ilişkili tüm dizinleri günceller. ve Cloud Firestore, yazma işlemini çoğunlukta olması gerekir. Yeterince yüksek yazma hızlarında veritabanı çakışma, daha yüksek gecikme veya başka hatalarla karşılaşmaya başlar.
Dar bir belge aralığında yüksek okuma, yazma ve silme oranları
Belgeleri alfabetik olarak kapatmak için yüksek okuma veya yazma hızlarından kaçının. Aksi takdirde uygulamanızda çakışma hataları yaşanır. Bu sorunun adı bir sorun ortaya çıkabilir ve uygulama, hotspot oluşumunu şu:
Çok yüksek bir oranda yeni dokümanlar oluşturur ve monoton olarak artan kimlikleri ayırır.
Cloud Firestore, belge kimliklerini dağılım algoritması kullanarak ayırır. Otomatik belge kimliklerini kullanarak yeni dokümanlar oluşturursanız yazma işleminde yoğun noktayla karşılaşmazsınız.
Az sayıda doküman içeren bir koleksiyonda yüksek oranda yeni doküman oluşturur.
Tekerlekli olarak artan bir alana sahip yeni dokümanlar oluşturur. Örneğin, zaman damgasını artırabilirsiniz.
Koleksiyondaki dokümanları yüksek hızda siler.
Trafiği kademeli olarak artırmadan veritabanına çok yüksek bir hızda yazma
Silinmiş verileri atlamaktan kaçının
Yakın zamanda silinmiş verileri atlayan sorgulardan kaçının. Bir sorgunun atlanması gerekebilir ilk sorgu sonuçları yakın zamanda yeni kullanıcılar silindi.
Silinen çok sayıda veriyi atlaması gerekebilecek bir iş yükü örneği, sıraya alınmış en eski iş öğelerini bulmaya çalışan bir iş yükü olabilir. Sorgu şu şekilde 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
created alanı (en son silinen dokümanlarda da yer alır.) Bu, sorguları yavaşlatır.
Performansı artırmak için en iyi başlangıç noktasını bulmak üzere 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 anti-pattern olan tekdüze artan bir alan kullanılmaktadır.
Trafiği artırma
Yeni koleksiyonlara gelen trafiği kademeli olarak artırmalı veya Cloud Firestore'ye dokümanları artan trafiğe hazırlaması için yeterli süre tanımak amacıyla dokümanları alfabetik olarak kapatmalısınız. En fazla 500 sayfayla başlamanızı öneririz. yeni bir koleksiyona kopyalama ve ardından trafikte %50 artış her 5 dakikada bir Benzer şekilde yazma trafiğinizi de artırabilir, ancak Cloud Firestore Standart Sınırlar. Emin olun İşlemlerin anahtar aralığı boyunca nispeten eşit bir şekilde dağıtılmasını sağlamaktır. Bu adı "500/50/5" kuralı.
Trafiği yeni bir koleksiyona taşıma
Uygulama trafiğini bir koleksiyondan diğerine taşıyorsanız kademeli artış özellikle önemlidir. Bu taşıma işlemini gerçekleştirmenin basit bir yolu belge mevcut değilse yeni koleksiyon örneğinden koleksiyonudur. Ancak bu durum, yeni koleksiyondaki alfabetik olarak yakın dokümanlara yönelik trafiğin aniden artmasına neden olabilir. Cloud Firestore, özellikle az sayıda doküman içerdiğinde yeni koleksiyonu artan trafiğe hazırlayamayabilir.
Aynı koleksiyondaki birçok dokümanın doküman kimliklerini değiştirirseniz benzer bir sorunla karşılaşabilirsiniz.
Trafiği yeni bir koleksiyona taşımak için en iyi strateji verilerinize bağlıdır modeli. Aşağıda paralel okumalar olarak bilinen bir örnek strateji verilmiştir. Yapmanız gerekenler bu stratejinin verileriniz için etkili olup olmadığını belirleme ve paralel operasyonların maliyet üzerindeki etkisi ile ilgili önemli bir husus, taşımayı öğreteceğim.
Paralel okumalar
Trafiği yeni bir koleksiyona taşırken paralel okumaları uygulamak için önce eski koleksiyondan okuma yapın. Belge yoksa yeni koleksiyondan okuyun. Var olmayan belgelerin yüksek oranda okunması, yoğun noktaların oluşmasına neden olabilir. Bu nedenle, yeni koleksiyona olan yükü kademeli olarak artırdığınızdan emin olun. Daha iyi bir strateji, eski dokümanı yeni koleksiyona kopyalayıp eski dokümanı silmektir. Cloud Firestore'ün yeni koleksiyona gelen trafiği işleyebilmesi için paralel okumaları kademeli olarak artırın.
Yeni bir koleksiyona okuma veya yazma işlemlerini kademeli olarak artırmak için olası bir strateji, yeni doküman yazmaya çalışan kullanıcıların rastgele bir yüzdesini seçmek üzere kullanıcı kimliğinin deterministik karmasını kullanmaktır. Kullanıcının Kimlik karması, işleviniz veya kullanıcı davranışı nedeniyle bozulmaz.
Bu arada, tüm verilerinizi eski dokümanlardan görebilirsiniz. Toplu işiniz, yoğun noktaları önlemek için sıralı doküman kimliklerine yazma işlemlerinden kaçınmalıdır. Toplu iş tamamlandığında, yalnızca okuma iznine sahip yeni koleksiyondan.
Bu stratejinin bir ayrıntısı, bir seferde küçük gruplar halinde kullanıcı taşımaktır. Kullanıcı belgesine, ilgili kullanıcının taşıma durumunu izleyen bir alan ekleyin. Taşınacak kullanıcı grubunu, kullanıcı kimliğinin karma değerine göre seçin. Tekliflerinizi otomatikleştirmek ve optimize etmek için kullanıcı grubu için dokümanları taşımak ve paralel okumalar yapabilirsiniz. ortasındasınız.
Her iki eski dosyanın ikisine de yazmadığınız sürece eski sürüme kolayca dönemeyeceğinizi unutmayın. kontrol edilir. Bu, Cloud Firestore maliyetlerini artıracaktır.
Gizlilik
- Hassas bilgileri Cloud projesi kimliğinde saklamayın. Cloud proje kimliği, projenizin yaşam süresinin ötesinde saklanabilir.
- Veri uygunluğuna dair en iyi uygulama olarak, hassas verileri depolamaya belge adlarındaki ve doküman alan adlarındaki bilgileri içerebilir.
Yetkisiz erişimi engelleme
Veritabanınızdaki yetkisiz işlemleri önlemek için Cloud Firestore Security Rules Örneğin, kuralları kullanarak farklı sürekli olarak veritabanınızın tamamını indirir.
Cloud Firestore Security Rules özelliğini kullanma hakkında daha fazla bilgi edinin.