Cloud Firestore kullanan bir uygulama oluştururken hızlıca başvurmak için burada listelenen en iyi uygulamalardan yararlanı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ı daha fazla hataya neden olur 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 tekdüze artan doküman kimlikleri kullanmayın:
Customer1,Customer2,Customer3, ...Product 1,Product 2,Product 3, ...
Bu tür sıralı kimlikler, gecikmeyi etkileyen yoğun trafik noktalarına neden olabilir.
Alan adları
Alan adlarında aşağıdaki karakterleri kullanmaktan kaçının. Bu karakterler için ek kod dışına alma işlemi gerekir:
.dönemi[sol köşeli ayraç]sağ köşeli ayraç*yıldız işareti`vurgu işareti
Dizinler
Yazma gecikmesini azaltma
Yazma gecikmesine en büyük katkıyı dizin dağıtımı yapar. Dizin yayılımını azaltmak için en iyi uygulamalar:
Koleksiyon düzeyinde dizin muafiyetleri ayarlayın. Varsayılan olarak Azalan ve Dizi dizine ekleme'yi devre dışı bırakmak kolaydır. Kullanılmayan dizine eklenmiş değerlerin kaldırılması depolama maliyetlerini de düşürür.
Bir işlemdeki doküman sayısını azaltın. Çok sayıda doküman yazmak için atomik toplu yazar yerine toplu yazar kullanmayı düşünebilirsiniz.
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 içeren bir dize alanınız varsa alanı dizine ekleme işleminden muaf tutarak depolama maliyetlerini azaltabilirsiniz. |
| Sıralı değerler içeren belgeler barındıran 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ğerlere sahip alana göre sorgu yapmıyorsanız bu sınırı atlamak 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ın bulunduğu bir koleksiyon) saniyede 500 yazma sınırına yaklaşılabilir. |
| 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 indeksleme varsayılan olarak etkindir ve daha yüksek trafik oranlarında performansı etkileyebilir. En iyi uygulama olarak, TTL alanlarınız için tek alan muafiyetleri ekleyin. |
| Büyük dizi veya harita alanları | Büyük dizi veya harita alanları,belge başına 40.000 dizin girişi sınırına yaklaşabilir. Büyük bir dizi veya harita alanına göre sorgu yapmıyorsanız bunu dizine ekleme işleminden muaf tutmanız gerekir. |
Okuma ve yazma işlemleri
Bir uygulamanın tek bir belgeyi güncelleyebileceği tam maksimum hız, iş yüküne büyük ölçüde bağlıdır. Daha fazla bilgi için Tek bir belgede yapılan güncellemeler 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, gecikme etkisini en aza indirir. Örneğin, bir yanıt oluşturmadan önce doküman aramasının sonucuna ve sorgu sonuçlarına ihtiyaç duyan bir uygulamayı ele alalım. 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. Yalnızca bir ofset kullanmak, atlanan dokümanların uygulamanıza döndürülmesini önler 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 olan işlemleri otomatik olarak yeniden dener. Uygulamanız, SDK yerine doğrudan REST veya RPC API'leri üzerinden Cloud Firestore 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 Büyük ölçekte gerçek zamanlı sorguları anlama başlıklı makaleyi inceleyin.
Ölçeğe göre tasarım
Aşağıdaki en iyi uygulamalar, çekişme sorunlarına yol açan durumlardan nasıl kaçınabileceğinizi açıklar.
Tek bir dokümanda yapılan güncellemeler
Uygulamanızı tasarlarken tek bir dokümanı 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 belgeyi güncelleyebileceği tam maksimum hız, iş yüküne büyük ölçüde 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 tüm dizinleri günceller ve Cloud Firestore yazma işlemini eşzamanlı olarak bir çoğunluk kopyasına uygular. Yazma hızı yeterince yüksek olduğunda 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ı
Sözlükbilimsel olarak birbirine yakın dokümanlara yüksek okuma veya yazma hızlarıyla erişmekten kaçının. Aksi takdirde uygulamanızda çakışma hataları oluşur. Bu sorun, sıcak nokta olarak bilinir ve uygulamanız aşağıdakilerden herhangi birini yaparsa sıcak nokta sorunu yaşayabilir:
Çok yüksek bir hızda yeni dokümanlar oluşturur ve tekdüze şekilde artan kendi kimliklerini ayırır.
Cloud Firestore, doküman kimliklerini dağıtma algoritması kullanarak ayırır. Otomatik belge kimliklerini kullanarak yeni belgeler oluşturursanız yazma işlemlerinde sıcak nokta oluşumuyla karşılaşmazsınız.
Az sayıda doküman içeren bir koleksiyonda yüksek hızda yeni dokümanlar oluşturulması
Zaman damgası gibi tekdüze artan bir alanla çok yüksek hızda yeni dokümanlar oluşturur.
Bir koleksiyondaki dokümanları yüksek hızda siler.
Trafiği kademeli olarak artırmadan çok yüksek bir hızda veritabanına yazma işlemi gerçekleştiriliyor.
Silinen verilerin atlanmasını önleme
Yakın zamanda silinen 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ş veriyi atlamak zorunda kalabilecek bir iş yükü örneği, sıraya alınmış en eski iş öğelerini bulmaya çalışan bir iş yüküdür. 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, kısa süre önce silinen belgelerdeki created alanı için dizin girişleri taranır. Bu durum sorguları yavaşlatır.
Performansı artırmak için start_at yöntemini kullanarak başlamak için en iyi yeri 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 tekdüze şekilde artan bir alan kullanılmaktadır.
Trafiği artırma
Cloud Firestore'ya dokümanları artan trafiğe hazırlaması için yeterli zaman tanımak amacıyla yeni koleksiyonlara veya sözlükbilimsel olarak yakın dokümanlara yönelik 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ığına 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 yapmak ve doküman yoksa yeni koleksiyondan okuma yapmaktır. Ancak bu durum, yeni koleksiyondaki sözlükbilimsel olarak yakın dokümanlara yönelik trafikte ani bir artışa neden olabilir. Cloud Firestore Yeni koleksiyonu, özellikle az sayıda doküman içerdiğinde artan trafiğe karşı verimli bir şekilde hazırlayamayabilir.
Aynı koleksiyondaki birçok dokümanın doküman kimliklerini değiştirirseniz benzer bir sorun oluşabilir.
Trafiği yeni bir koleksiyona taşıma konusunda 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. Ayrıca, taşıma sırasında paralel işlemlerin maliyet üzerindeki etkisini de göz önünde bulundurmanız önemlidir.
Paralel okuma
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 okunma oranı, hotspotting'e yol açabilir. Bu nedenle, yeni koleksiyona 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ın yeni koleksiyona gelen trafiği işleyebildiğinden emin olmak 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ümanlar yazmaya çalışan kullanıcıların rastgele bir yüzdesini seçmek üzere kullanıcı kimliğinin deterministik bir karma değerini 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, etkin noktaları önlemek için sıralı doküman kimliklerine yazmaktan kaçınmalıdır. Toplu iş tamamlandığında yalnızca yeni koleksiyondan okuyabilirsiniz.
Bu stratejinin daha iyi bir versiyonu, kullanıcıları küçük gruplar halinde taşımaktır. Kullanıcı belgesine, ilgili 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 bir 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 öğeler için çift yazma işlemi yapmadığınız sürece kolayca geri dönemeyeceğinizi unutmayın. Bu durum, Cloud Firestore maliyetlerinin artmasına neden olur.
Gizlilik
- Hassas bilgileri Cloud projesi kimliğinde depolamayın. Cloud projesi kimliği, projenizin yaşam süresinden daha uzun süre saklanabilir.
- Veri uyumluluğu açısından en iyi uygulama olarak, hassas bilgileri doküman adlarında ve doküman alan adlarında depolamamanızı öneririz.
Yetkisiz erişimi engelleme
Cloud Firestore Security Rules ile veritabanınızda yetkisiz işlemleri önleyin. Örneğin, kurallar kullanarak kötü niyetli bir kullanıcının tüm veritabanınızı tekrar tekrar indirmesini önleyebilirsiniz.
Cloud Firestore Security Rules kullanma hakkında daha fazla bilgi edinin.