Cloud Firestore kullanan bir uygulama oluştururken burada listelenen en iyi uygulamalardan yararlanabilirsiniz.
Veritabanı konumu
Veritabanı örneğinizi oluşturduğunuzda, kullanıcılarınıza ve işlem kaynaklarınıza en yakın veritabanı konumunu seçin. Geniş kapsamlı ağ atlamaları daha hataya açıktı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.
Uygulamanız gecikmeye duyarlıysa daha düşük yazma gecikmesi için veya diğer GCP kaynaklarıyla birlikte konumlandırılmak amacıyla daha düşük maliyetler için bölgesel konum seçin.
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 tekdüze şekilde artan belge 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ı
Ekstra çıkış karakteri gerektirdiğinden alan adlarında aşağıdaki karakterlerden kaçının:
.devre[sol köşeli ayraç]sağ köşeli parantez*yıldız işareti`vurgu işareti
Dizinler
Yazma gecikmesini azaltma
Yazma gecikmesinde ana etken, dizin dağılmasıdır. Dizin dağılmasını azaltmak için en iyi uygulamalar şunlardır:
Koleksiyon düzeyinde dizin muafiyetlerini ayarlayın. Varsayılan olarak azalan ve dizi dizine ekleme özelliğini devre dışı bırakabilirsiniz. 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 yazıcı yerine toplu yazıcı kullanmayı düşünün.
Dizin muafiyetleri
Çoğu uygulama için, dizinlerinizi yönetmek amacıyla otomatik dizine eklemenin yanı sıra herhangi bir hata mesajı bağlantısını da kullanabilirsiniz. Ancak aşağıdaki durumlarda tek alan muafiyetleri eklemek isteyebilirsiniz:
| Durum | Açıklama |
|---|---|
| Geniş dize alanları | Genellikle sorgulamada kullanmadığınız uzun dize değerleri içeren bir dize alanınız varsa bu alanı dizine eklenmekten muaf tutarak depolama maliyetlerini azaltabilirsiniz. |
| Sıralı değerleri olan belgeler içeren bir koleksiyona yüksek yazma hızları | Zaman damgası gibi, koleksiyondaki belgeler arasında sırayla artan veya azalan bir alanı dizine eklerseniz koleksiyondaki maksimum yazma hızı saniyede 500 yazma işlemi olur. Sıralı değerleri olan alana göre sorgulama yapmıyorsanız bu sınırı atlamak için alanı dizine eklenmekten muaf tutabilirsiniz. Örneğin, yazma hızı yüksek olan bir IoT kullanım alanında, zaman damgası alanı olan belgeler içeren 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 tek alanlı muafiyetler ekleyin. |
| Büyük dizi veya eşleme alanları | Büyük dizi veya eşleme alanları,belge başına 40.000 dizin girişi sınırına yaklaşabilir. Geniş bir diziye veya eşleme alanına dayalı sorgulama yapmıyorsanız 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 bölümüne bakın.
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, yanıt oluşturmadan önce belge aramasının ve sorgunun sonuçlarını gerektiren bir uygulamayı düşünün. Aramada ve sorguda veri bağımlılığı yoksa sorguyu başlatmadan önce arama tamamlanana kadar eşzamanlı olarak beklemenize gerek yoktur.
Ofset kullanmayın. Bunun yerine imleçleri kullanın. Ofset kullanmak yalnızca atlanan belgelerin uygulamanıza döndürülmesini önler, ancak bu belgeler hâlâ 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 deneme sayısı
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'a SDK yerine doğrudan REST veya RPC API'leri aracılığıyla erişiyorsa güvenilirliği artırmak için işlem yeniden denemeleri uygulamalıdır.
Gerçek zamanlı güncellemeler
Gerçek zamanlı güncellemelerle ilgili en iyi uygulamalar için Gerçek zamanlı sorguları geniş ölçekte anlama bölümüne bakın.
Ölçeklendirilebilecek tasarımlar yapma
Aşağıdaki en iyi uygulamalar, anlaşmazlık 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 bir dokümanı ne kadar hızlı güncellediğini düşünün. İş yükünüzün performansını tanımlamanın en iyi yolu yük testi yapmaktır. Bir uygulamanın tek bir dokümanı güncelleyebileceği maksimum hız, iş yüküne büyük ölçüde 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. Cloud Firestore, yazma işlemini replika sayısına eşzamanlı olarak uygular. Yeterince yüksek yazma hızlarında, veritabanı çakışma, daha yüksek gecikme veya diğer hatalarla karşılaşmaya başlar.
Dar bir belge aralığında yüksek okuma, yazma ve silme oranları
Dokümanları sözlüksel olarak kapatmak için yüksek okuma veya yazma hızlarından kaçının. Aksi takdirde uygulamanızda çakışma hatalarıyla karşılaşılır. Bu sorun hotspot olarak bilinir ve aşağıdakilerden herhangi birini yaparsa uygulamanız hotspot ile karşılaşabilir:
Ç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şlemlerinde hotspot ile karşılaşmamanız gerekir.
Birkaç dokümanla bir koleksiyonda yüksek oranda yeni dokümanlar oluşturur.
Zaman damgası gibi monoton bir şekilde artan bir alana sahip çok yüksek bir hızda yeni dokümanlar oluşturur.
Koleksiyondaki dokümanları yüksek oranda siler.
Trafiği kademeli olarak artırmadan veritabanına çok yüksek bir hızda yazar.
Silinmiş verileri atlamaktan kaçının
Yakın zamanda silinmiş verileri atlayan sorgulardan kaçının. Erken sorgu sonuçları yakın zamanda silinmişse bir sorgunun çok sayıda dizin girişini atlaması gerekebilir.
Çok sayıda silinmiş verinin atlanması gereken iş yüküne örnek olarak sıraya alınmış en eski iş öğelerini bulmaya çalışan 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 da sorguları yavaşlatır.
Performansı artırmak için start_at yöntemini kullanarak başlamak için en iyi yeri bulun. Örnek:
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ına yönelik bir kalıp olmayan monoton olarak artan bir alan kullanılmaktadır.
Trafiği artırma
Cloud Firestore'a belgeleri artan trafik için hazırlamak üzere yeterli süre tanımak amacıyla, yeni koleksiyonlara gelen trafiği kademeli olarak artırmanız veya belgelere sözlüksel olarak son vermeniz gerekir. Saniyede en fazla 500 işlem yaparak yeni bir koleksiyona taşımanızı, ardından her 5 dakikada trafiği %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 bir şekilde dağıtıldığından emin olun. Buna "500/50/5" kuralı denir.
Trafiği yeni bir koleksiyona taşıma
Kademeli artış, özellikle uygulama trafiğini bir koleksiyondan diğerine taşıyorsanız önemlidir. Bu taşıma işlemini gerçekleştirmenin basit bir yolu, eski koleksiyondan okuma yapmak ve belge yoksa yeni koleksiyondan okumaktır. Ancak bu durum, yeni koleksiyondaki dokümanların sözlüksel 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 trafik için verimli bir şekilde hazırlayamayabilir.
Aynı koleksiyondaki birçok dokümanın belge kimliğini 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 okumalar olarak bilinen bir örnek strateji verilmiştir. Bu stratejinin verileriniz için etkili olup olmadığını belirlemeniz gerekir. Ayrıca, göz önünde bulundurulması gereken önemli bir nokta da taşıma sırasında paralel işlemlerin maliyet üzerindeki etkisidir.
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 dokümanların okunma oranının yüksek olması, hotspot'a yol açabilir. Bu nedenle, yeni koleksiyon yükünü kademeli olarak artırmaya dikkat edin. Daha iyi bir strateji, eski dokümanı yeni koleksiyona kopyalayıp eski dokümanı silmektir. Cloud Firestore'un yeni koleksiyon trafiğini yönetebilmesi için paralel okumaları kademeli olarak artırın.
Yeni bir koleksiyonda okuma veya yazma işlemlerini kademeli olarak artırmak için olası bir strateji, yeni belge yazmaya çalışan kullanıcıların rastgele bir yüzdesini seçmek amacıyla kullanıcı kimliğinin deterministik bir karmasını kullanmaktır. User-ID karmasının sonucunun işleviniz veya kullanıcı davranışı nedeniyle bozmadığından emin olun.
Bu sırada, eski belgelerdeki tüm verilerinizi yeni koleksiyona kopyalayan bir toplu iş çalıştırın. Toplu işinizde, hotspot'ları önlemek için sıralı belge kimliklerine yazma işlemi yapılmamalıdır. Toplu iş tamamlandığında yalnızca yeni koleksiyondan okuyabilirsiniz.
Bu stratejide yapılan bir geliştirme, tek seferde küçük kullanıcı gruplarını taşımaktır. Kullanıcı dokümanına, söz konusu 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. İlgili kullanıcı grubunun dokümanlarını taşımak için toplu iş kullanın ve taşıma sürecinin ortasında olan kullanıcılar için paralel okumalardan yararlanın.
Taşıma aşamasında hem eski hem de yeni varlıklar için çift yazma işlemi yapmadığınız sürece işlemi kolayca geri çekemeyeceğinizi unutmayın. Bu da Cloud Firestore maliyetlerini artırır.
Gizlilik
- Cloud proje kimliğinde hassas bilgileri depolamaktan kaçının. Cloud Proje Kimliği, projenizin kullanım süresi bitiminden sonra saklanabilir.
- Veri uygunluğuna dair en iyi uygulama olarak, hassas bilgileri doküman adlarında ve doküman alanı adlarında depolamamanızı öneririz.
Yetkisiz erişimi engelleyin
Cloud Firestore Güvenlik Kuralları ile veritabanınızdaki 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 indirdiği bir senaryodan kaçınabilirsiniz.
Cloud Firestore Güvenlik Kurallarını kullanma hakkında daha fazla bilgi edinin.