Cloud Firestore kullanan bir uygulama oluştururken buradaki en iyi uygulamaları hızlı bir referans olarak kullanabilirsiniz.
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. Sürekli artan doküman kimlikleri kullanmayın. Örneğin:
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 dizin oluşturmayı devre dışı bırakmak kolay bir varsayılan seçenektir. Kullanılmayan dizine eklenmiş değerlerin kaldırılması, depolama maliyetlerini de azaltır.
İş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ı 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 bir belge arama sonucuna ve bir sorgunun 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 Geniş ölçekte 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 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ğun kullanım olarak bilinir ve uygulamanız aşağıdakilerden herhangi birini yaparsa yoğun kullanım 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 alan içeren yeni dokümanları çok yüksek bir hızda oluşturur.
Koleksiyondaki dokümanları yüksek hızda siler.
Trafiği kademeli olarak artırmadan veritabanına çok yüksek 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ıraya alınmış 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 süre tanımak amacıyla yeni koleksiyonlara veya sözlükbilimsel olarak yakın belgelere giden trafiği kademeli olarak artırmanız gerekir. Yeni bir koleksiyona 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 yapabilirsiniz. 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 doküman 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 de 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 örnek bir strateji verilmiştir. Bu stratejinin verileriniz için etkili olup olmadığını belirlemeniz gerekir. Taşıma sırasında paralel işlemlerin maliyet etkisi de önemli bir husustur.
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 yoksa yeni koleksiyondan okuyun. Mevcut olmayan dokümanların 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'nin yeni koleksiyona giden 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 karmasını 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, tüm verilerinizi eski dokümanlardan 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 karma değerine 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 alma işlemi yapamayacağınızı unutmayın. Bu, Cloud Firestore maliyetlerini artırır.
Gizlilik
- Cloud projesi kimliğinde hassas bilgiler saklamayın. Cloud proje kimliği, projenizin kullanım ö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 önleyebilirsiniz.
Cloud Firestore Security Rules kullanımı hakkında daha fazla bilgi edinin.