Cloud Firestore kullanan bir uygulama oluştururken burada listelenen en iyi uygulamaları hızlı bir referans olarak kullanın.
Veritabanı konumu
Veritabanı örneğinizi oluştururken kullanıcılarınıza ve işlem kaynaklarınıza en yakın veritabanı konumunu seçin. Uzak 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 işlem kaynaklarını en az iki bölgeye yerleştirin.
Daha düşük maliyetler, uygulamanız gecikmeye duyarlıysa daha düşük yazma gecikmesi veya diğer GCP kaynaklarıyla aynı yerde bulunma için bölgesel bir konum seçin.
Doküman kimlikleri
.ve..doküman kimliklerini kullanmayın.- Doküman kimliklerinde
/eğik çizgi kullanmaktan kaçının. Aşağıdakiler gibi sürekli artan doküman kimlikleri kullanmayın:
Customer1,Customer2,Customer3, ...Product 1,Product 2,Product 3, ...
Bu tür sıralı kimlikler, gecikmeyi etkileyen etkin noktalara neden olabilir.
Alan Adları
Ek kaçış karakteri gerektirdiğinden alan adlarında aşağıdaki karakterleri kullanmaktan kaçının:
.nokta[sol köşeli ayraç]sağ köşeli ayraç*yıldız işareti`vurgu işareti
Dizinler
Yazma gecikmesini azaltma
Yazma gecikmesine en çok katkıda bulunan faktör, dizin yayılımıdır. Dizin yayılımını azaltmak için en iyi uygulamalar şunlardır:
Koleksiyon düzeyinde dizin muafiyetleri ayarlayın. Azalan ve dizi dizine eklemeyi devre dışı bırakmak kolay bir varsayılan seçenektir. Kullanılmayan dizine eklenmiş değerlerin kaldırılması, depolama maliyetlerini de azaltır.
Bir işlemdeki belge sayısını azaltın. Çok sayıda belge yazmak için atomik toplu yazıcı yerine toplu yazıcı kullanabilirsiniz.
Dizin muafiyetleri
Çoğu uygulamada, dizinlerinizi yönetmek için otomatik dizine ekleme özelliğinin yanı sıra hata mesajı bağlantılarını kullanabilirsiniz. Ancak aşağıdaki durumlarda tek alan muafiyetleri eklemek isteyebilirsiniz:
| Durum | Açıklama |
|---|---|
| Büyük dize alanları | Sorgulama için kullanmadığınız uzun dize değerlerini sık sık barındıran bir dize alanınız varsa alanı dizine eklemeden muaf tutarak depolama maliyetlerini azaltabilirsiniz. |
| Sıralı değerler içeren dokümanların bulunduğu bir koleksiyona yüksek yazma hızları | Bir koleksiyondaki belgeler arasında sıralı olarak artan veya azalan bir alanı (ör. zaman damgası) dizine eklerseniz koleksiyona maksimum yazma hızı saniyede 500 yazma işlemi olur. Sıralı değerler içeren alana göre sorgu yapmıyorsanız bu sınırı atlamak için alanı dizine eklemeden muaf tutabilirsiniz. Örneğin, yazma hızının yüksek olduğu bir IoT kullanım alanında, zaman damgası alanı içeren dokümanların bulunduğu bir koleksiyon saniyede 500 yazma sınırına yaklaşabilir. |
| 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 daha yüksek trafik oranlarında performansı etkileyebilir. En iyi uygulama olarak, TTL alanlarınız için otomatik dizine ekleme muafiyetleri ekleyin. |
| Büyük dizi veya harita alanları | Büyük dizi veya harita alanları,doküman 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 bu alanı dizine ekleme işleminden muaf 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 yapılan güncellemeler başlıklı makaleyi inceleyin.
Mümkün olduğunda eşzamanlı çağrılar yerine eşzamansız çağrılar kullanın. Eşzamansız çağrılar, gecikme etkisini en aza indirir. Örneğin, bir yanıt oluşturmadan önce belge arama sonucuna ve sorgu sonuçlarına ihtiyaç duyan bir uygulama düşünün. Arama ve sorgu arasında veri bağımlılığı yoksa sorguyu başlatmadan önce aramanın tamamlanmasını eşzamanlı olarak beklemeye gerek yoktur.
Ofset kullanmayın. Bunun yerine imleçleri kullanın. Ofset kullanmak yalnızca atlanan dokümanların uygulamanıza döndürülmesini engeller ancak bu dokümanlar dahili olarak alınmaya devam eder. Atlanan belgeler sorgunun gecikmesini etkiler ve uygulamanız, bu belgeleri 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 hataları gidermek için başarısız işlemleri otomatik olarak yeniden dener. Uygulamanız, Cloud Firestore hizmetine bir SDK yerine 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 Ölçekli gerçek zamanlı sorguları anlama başlıklı makaleyi inceleyin.
Ölçeklenebilir tasarım
Aşağıdaki en iyi uygulamalar, çekişme sorunlarına yol açan durumlardan nasıl kaçınacağınızı açıklar.
Tek bir dokümanda yapılan güncellemeler
Uygulamanızı tasarlarken, uygulamanızın tek dokümanları ne kadar hızlı güncellediğini göz önünde bulundurun. İş 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, büyük ölçüde iş yüküne bağlıdır. Yazma hızı, istekler arasındaki çekişme ve etkilenen dizinlerin sayısı bu faktörler arasındadır.
Belge yazma işlemi, belgeyi ve ilişkili dizinleri günceller ve Cloud Firestore yazma işlemini replikaların çoğunluğuna eşzamanlı olarak uygular. Yazma hızları yeterince yüksek olduğunda veritabanında çekişme, daha yüksek gecikme veya başka hatalar görülmeye başlar.
Dar bir doküman aralığında yüksek okuma, yazma ve silme oranları
Sözlükbilimsel olarak yakın dokümanlarda yüksek okuma veya yazma oranlarından kaçının. Aksi takdirde uygulamanızda çekişme hataları yaşanır. Bu sorun, yoğunluk olarak bilinir ve uygulamanız aşağıdakilerden herhangi birini yaparsa yoğunluk yaşayabilir:
Çok yüksek bir hızda yeni dokümanlar oluşturur ve kendi monoton şekilde artan kimliklerini tahsis eder.
Cloud Firestore, doküman kimliklerini bir dağılım algoritması kullanarak tahsis eder. Otomatik doküman kimliklerini kullanarak yeni dokümanlar oluşturursanız yazma işlemlerinde hotspotting ile karşılaşmazsınız.
Az sayıda doküman içeren bir koleksiyonda yüksek hızda yeni dokümanlar oluşturma.
Zaman damgası gibi monoton şekilde artan bir alana sahip yeni belgeleri çok yüksek bir hızda oluşturur.
Koleksiyondaki belgeleri yüksek hızda siler.
Trafiği kademeli olarak artırmadan veritabanına çok yüksek bir hızda yazma işlemi gerçekleştirme
Silinen verileri atlamaktan kaçınma
Yakın zamanda silinen verileri atlayan sorgulardan kaçının. Erken sorgu sonuçları yakın zamanda silindiyse sorgunun çok sayıda dizin girişini atlaması gerekebilir.
Silinen çok sayıda veriyi atlaması gerekebilecek iş yüklerine örnek olarak, sıradaki en eski iş öğelerini bulmaya çalışan bir iş yükü verilebilir. 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, yakın zamanda silinen belgelerdeki created alanı için dizin girişlerini tarar. Bu durum sorguları yavaşlatır.
Performansı artırmak için start_at yöntemini kullanarak en iyi başlangıç noktasını bulun. Ö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-pattern olan monoton olarak artan bir alan kullanılmaktadır.
Trafiği artırma
Cloud Firestore hizmetine, belgeleri artan trafiğe hazırlaması için yeterli zaman tanımak amacıyla yeni koleksiyonlara veya sözlük sırasına göre yakın belgelere giden trafiği kademeli olarak artırmanız gerekir. Yeni bir koleksiyon için saniyede en fazla 500 işlemle başlamanızı ve ardından trafiği her 5 dakikada bir %50 artırmanızı öneririz. Yazma trafiğinizi de benzer şekilde artırabilirsiniz ancak Cloud Firestore standart sınırlarını göz önünde bulundurun. İş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 artış özellikle önemlidir. Bu taşıma işlemini gerçekleştirmenin basit bir yolu, eski koleksiyondan okuma yapmaktır. Doküman yoksa yeni koleksiyondan okuma yapın. Ancak bu durum, yeni koleksiyondaki sözlükbilimsel olarak yakın dokümanlara yönelik trafikte ani bir artışa neden olabilir. Cloud Firestore özellikle az sayıda belge içeriyorsa yeni koleksiyonu artan trafik için verimli bir şekilde hazırlayamayabilir.
Aynı koleksiyondaki birçok dokümanın doküman kimliklerini 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 okuma olarak bilinen bir strateji örneği verilmiştir. Bu stratejinin verileriniz için etkili olup olmadığını belirlemeniz gerekir. Önemli bir husus, taşıma sırasında paralel işlemlerin maliyet üzerindeki etkisidir.
Paralel okuma işlemleri
Trafiği yeni bir koleksiyona taşırken paralel okuma işlemlerini uygulamak için önce eski koleksiyondan okuma yapın. Belge eksikse yeni koleksiyondan okuyun. Mevcut olmayan belgelerin yüksek oranda okunması, yoğunluk noktası oluşmasına neden olabilir. Bu nedenle, yeni koleksiyondaki yükü kademeli olarak artırdığınızdan emin olun. Eski dokümanı yeni koleksiyona kopyalayıp eski dokümanı silmek daha iyi bir stratejidir. Cloud Firestore uygulamasının yeni koleksiyona gelen trafiği işleyebilmesi için paralel okuma işlemlerini kademeli olarak artırın.
Yeni bir koleksiyona okuma veya yazma işlemlerini kademeli olarak artırmak için olası bir strateji, yeni dokümanlar yazmaya çalışan kullanıcıların rastgele bir yüzdesini seçmek için kullanıcı kimliğinin deterministik bir karma değerini kullanmaktır. Kullanıcı kimliği karma işleminin sonucunun, işleviniz veya kullanıcı davranışı nedeniyle çarpıtılmadığından emin olun.
Bu sırada, eski dokümanlardaki tüm verilerinizi yeni koleksiyona kopyalayan bir toplu iş çalıştırın. Yoğunluk noktalarını önlemek için toplu işinizde sıralı doküman kimliklerine yazma işlemi yapılmamalıdır. Toplu iş tamamlandığında yalnızca yeni koleksiyondan okuma yapabilirsiniz.
Bu stratejinin daha gelişmiş bir versiyonu, kullanıcıları küçük gruplar halinde taşımaktır. Kullanıcı belgesine, kullanıcının taşıma durumunu izleyen bir alan ekleyin. Kullanıcı kimliğinin karmasına göre taşınacak bir kullanıcı grubu seçin. Bu kullanıcı grubunun dokümanlarını taşımak için toplu iş kullanın ve taşıma işleminin ortasındaki kullanıcılar için paralel okuma kullanın.
Taşıma aşamasında hem eski hem de yeni varlıkların ikili yazma işlemlerini yapmazsanız kolayca geri dönemezsiniz. Bu, Cloud Firestore maliyetlerini artırır.
Gizlilik
- Hassas bilgileri Cloud proje kimliğinde saklamayın. Cloud proje kimliği, projenizin ömründen daha uzun süre saklanabilir.
- Veri uygunluğuyla ilgili en iyi uygulama olarak, hassas bilgileri doküman adlarında ve doküman alanı adlarında saklamamanızı öneririz.
Yetkisiz erişimi önleyin
Cloud Firestore Security Rules ile veritabanınızda yetkisiz işlemleri önleyin. Örneğin, kuralları kullanarak kötü amaçlı bir kullanıcının veritabanınızın tamamını tekrar tekrar indirmesini engelleyebilirsiniz.
Cloud Firestore Security Rules kullanımı hakkında daha fazla bilgi edinin.