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.
Daha düşük maliyetler, uygulamanız gecikmeye duyarlıysa daha düşük yazma gecikmesi veya diğer GCP kaynaklarıyla birlikte konumlandırma için bir bölgesel konum seçin.
Doküman kimlikleri
.ve..doküman kimliklerinden kaçının.- Doküman kimliklerinde
/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 neden olabilir.
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 ayraç*yıldız işareti`ters eğik çizgi
Dizinler
Yazma gecikmesini azaltma
Yazma gecikmesine en çok katkıda bulunan faktör dizin dağıtımı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, azalan ve dizi dizine ekleme seçeneklerini devre dışı bırakabilirsiniz. Kullanılmayan dizine eklenen değerleri kaldırmak depolama maliyetlerini de düşürür.
İşlemdeki doküman 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 uygulamada, dizinlerinizi yönetmek için otomatik dizine ekleme özelliğinin yanı sıra hata mesajı bağlantılarından yararlanabilirsiniz. Ancak aşağıdaki durumlarda tek alan muafiyetleri ekleyebilirsiniz:
| Durum | Açıklama |
|---|---|
| Büyük dize alanları | Sorgu 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 daha yüksek trafik oranlarında performansı etkileyebilir. En iyi uygulama olarak, TTL alanlarınıza tek alan muafiyeti ekleyin. |
| Büyük dizi veya harita 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, 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.
Mümkün olduğunda eşzamanlı aramalar yerine eşzamansız aramalar kullanın. Eşzamansız çağrılar, gecikmenin etkisini en aza indirir. Örneğin, yanıt oluşturmadan önce bir doküman aramasının ve sorgunun sonuçlarına ihtiyaç duyan bir uygulamayı düşünün. 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çleri kullanın. Ofset kullanmak, atlanan dokümanların uygulamanıza döndürülmesini engeller ancak bu dokümanlar yine de dahili olarak alınır. 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 hatalarla başa çıkmak için başarısız işlemleri otomatik olarak yeniden dener. 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çeğe göre tasarım
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 tek dokümanları ne kadar hızlı güncelleyeceğ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 belgeyi güncelleyebileceği tam maksimum hız, iş yüküne bağlıdır. Yazma hızı, istekler arasındaki çekişme ve etkilenen dizin sayısı bu faktörler arasındadır.
Belge yazma işlemi, belgeyi ve ilişkili tüm dizinleri günceller. Cloud Firestore, yazma işlemini bir kopya çoğunluğu üzerinde senkronize olarak uygular. 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 hızları
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 sorun, "hotspot" olarak bilinir. Uygulamanız aşağıdakilerden herhangi birini yapıyorsa hotspot sorunuyla karşılaşabilir:
Çok yüksek bir hızda yeni dokümanlar oluşturur ve kendi tekdüze artan kimliklerini ayırır.
Cloud Firestore, dağılım algoritması kullanarak doküman kimlikleri atar. Otomatik belge kimlikleri 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.
Zaman damgası gibi monoton olarak artan bir alana sahip 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 bir hızda yazma
Silinen verileri atlamayın
Yakın zamanda silinen verileri atlayan sorgulardan kaçının. İlk sorgu sonuçları kısa süre önce silindiyse sorgunun çok sayıda dizine ekleme girişini atlaması gerekebilir.
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, yakın zamanda silinen belgelerdeki created alanı için dizin girişlerini tarar. Bu, 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 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 zaman tanımak amacıyla dokümanları alfabetik olarak kapatmalısınız. Yeni bir koleksiyonda saniye başına en fazla 500 işlemle başlamanızı ve ardından trafiği 5 dakikada bir %50 artırmanızı öneririz. Benzer şekilde yazma trafiğinizi de 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 olarak artırmak özellikle önemlidir. Bu taşıma işlemini gerçekleştirmenin basit bir yolu, eski koleksiyondan okumak ve belge yoksa yeni koleksiyondan okumaktır. 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 kimliğini değiştirirseniz benzer bir sorunla karşılaşabilirsiniz.
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 bir örnek 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 okumalar
Trafiği yeni bir koleksiyona taşırken paralel okumaları uygulamak için önce eski koleksiyondan okuma yapın. Belge eksikse 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ı kimliği karmasının sonucunun işleviniz veya kullanıcı davranışı tarafından ç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. 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 yeni koleksiyondan veri okuyabilirsiniz.
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. Kullanıcı kimliğinin karma oluşturma işlemine göre taşınacak bir kullanıcı grubu seçin. Bu kullanıcı grubuna ait dokümanları taşımak için toplu iş kullanın ve taşıma işleminin ortasında olan kullanıcılar için paralel okumalar kullanın.
Taşıma aşamasında hem eski hem de yeni öğeleri ikili yazmadığınız sürece kolayca geri dönemeyeceğinizi unutmayın. 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.
- Verilerle ilgili uygunlukla ilgili en iyi uygulama olarak, hassas bilgileri doküman adlarında ve doküman alan adlarında saklamamanızı öneririz.
Yetkisiz erişimi engelleme
Cloud Firestore Security Rules ile veritabanınızda yetkisiz işlemleri önleyin. Örneğin, kuralları kullanmak kötü amaçlı bir kullanıcının veritabanınızın tamamını tekrar tekrar indirdiği bir senaryoyu önleyebilir.
Cloud Firestore Security Rules'u kullanma hakkında daha fazla bilgi edinin.