Cloud Firestore kullanan bir uygulama oluştururken hızlı referans olarak burada listelenen en iyi uygulamaları kullanın.
Veritabanı konumu
Veritabanı örneğinizi oluşturduğunuzda kullanıcılarınıza ve bilgi işlem kaynaklarınıza en yakın veritabanı konumunu seçin. Geniş kapsamlı 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 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 ortak konum için bölgesel bir konum seçin.
Belge Kimlikleri
- Belge kimliklerinden kaçının
.Ve... - Belge kimliklerinde
/ileri eğik çizgileri kullanmaktan kaçının. Aşağıdakiler gibi monoton olarak artan belge kimliklerini kullanmayın:
-
Customer1,Customer2,Customer3, ... -
Product 1,Product 2,Product 3, ...
Bu tür sıralı kimlikler, gecikmeyi etkileyen sıcak noktalara yol açabilir.
-
Alan Adları
Ekstra kaçış gerektirdiklerinden alan adlarında aşağıdaki karakterlerden kaçının:
-
.dönem -
[sol parantez -
]sağ parantez -
*yıldız işareti -
`geri tıklama
-
Dizinler
Çok fazla indeks kullanmaktan kaçının. Aşırı sayıda dizin, yazma gecikmesini artırabilir ve dizin girişlerinin depolama maliyetlerini artırabilir. Dizin oluşturma gerektirmeyen çok sayıda alana sahip belgeler için koleksiyon düzeyinde dizin muafiyetlerini göz önünde bulundurun.
Zaman damgaları gibi monoton olarak artan değerlere sahip dizin oluşturma alanlarının, yüksek okuma ve yazma hızlarına sahip uygulamalar için gecikmeyi etkileyen sıcak noktalara yol açabileceğini unutmayın.
Dizin muafiyetleri
Çoğu uygulamada, dizinlerinizi yönetmek için otomatik dizine eklemenin yanı sıra hata mesajı bağlantılarına da güvenebilirsiniz. Ancak aşağıdaki durumlarda tek alanlı muafiyetler eklemek isteyebilirsiniz:
| Dava | Tanım |
|---|---|
| Büyük dize alanları | Sorgulama için kullanmadığınız, genellikle uzun dize değerlerini tutan bir dize alanınız varsa, alanı dizin oluşturma işleminden muaf tutarak depolama maliyetlerini azaltabilirsiniz. |
| Sıralı değerlere sahip belgeler içeren bir koleksiyona yüksek yazma oranları | Zaman damgası gibi bir koleksiyondaki belgeler arasında sırayla artan veya azalan bir alanı dizine eklerseniz koleksiyona maksimum yazma hızı saniyede 500 yazma olur. Sıralı değerlere sahip alanı temel alarak sorgulama yapmazsanız bu sınırı atlamak için alanı indekslemeden muaf tutabilirsiniz. Örneğin, yazma hızının yüksek olduğu bir IoT kullanım durumunda, zaman damgası alanına sahip belgeleri içeren bir koleksiyon, saniyede 500 yazma sınırına yaklaşabilir. |
| TTL alanları | TTL (yaşam 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 hızlarında performansı etkileyebilir. En iyi uygulama olarak TTL alanlarınız için tek alanlı muafiyetler 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 sorgulama yapmıyorsanız, onu indekslemeden muaf tutmalısınız. |
Okuma ve yazma işlemleri
Bir uygulamanın tek bir belgeyi 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 bkz. Tek bir belgede yapılan güncellemeler .
Mümkün olduğunda senkronize aramalar yerine senkronize olmayan aramaları kullanın. Eşzamansız çağrılar gecikme etkisini en aza indirir. Örneğin, bir yanıt oluşturmadan önce bir belge aramasının sonucuna ve bir sorgunun sonuçlarına ihtiyaç duyan bir uygulamayı düşünün. Arama ve sorgunun veri bağımlılığı yoksa, sorguyu başlatmadan önce aramanın tamamlanmasını eşzamanlı olarak beklemeye gerek yoktur.
Ofsetleri kullanmayın. Bunun yerine imleçleri kullanın. Ofset kullanmak yalnızca atlanan belgelerin uygulamanıza geri gönderilmesini önler ancak bu belgeler yine de dahili olarak alınır. Atlanan belgeler sorgunun gecikme süresini etkiler ve uygulamanız, bunları 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'a SDK yerine doğrudan REST veya RPC API'leri aracılığıyla erişiyorsa uygulamanızın güvenilirliği artırmak için işlem yeniden denemeleri uygulaması gerekir.
Gerçek zamanlı güncellemeler
Gerçek zamanlı güncellemelerle ilgili en iyi uygulamalar için bkz. Gerçek zamanlı sorguları geniş ölçekte anlama .
Ölçekli tasarım
Aşağıdaki en iyi uygulamalar, çekişme sorunları yaratan durumlardan nasıl kaçınılacağını açıklamaktadır.
Tek bir belgedeki güncellemeler
Uygulamanızı tasarlarken uygulamanızın tek belgeleri ne kadar hızlı güncellediğini düşünün. İş 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, büyük ölçüde iş yüküne bağlıdır. Faktörler arasında yazma hızı, istekler arasındaki çekişme ve etkilenen dizin sayısı yer alır.
Bir belge yazma işlemi, belgeyi ve ilişkili tüm dizinleri günceller ve Cloud Firestore, yazma işlemini bir kopya yeter sayısı genelinde eşzamanlı olarak uygular. Yeterince yüksek yazma hızlarında veritabanı çekişme, daha yüksek gecikme veya diğer hatalarla karşılaşmaya başlayacaktır.
Dar bir belge aralığında yüksek okuma, yazma ve silme oranları
Belgeleri sözlükbilimsel olarak kapatmak için yüksek okuma veya yazma hızlarından kaçının, aksi takdirde uygulamanızda çekişme hataları yaşanacaktır. Bu sorun, etkin noktalanma olarak bilinir ve uygulamanız aşağıdakilerden herhangi birini yaparsa etkin noktalanma yaşayabilir:
Çok yüksek oranda yeni belgeler oluşturur ve kendi monoton artan kimliklerini tahsis eder.
Cloud Firestore, belge kimliklerini bir dağılım algoritması kullanarak tahsis eder. Otomatik belge kimliklerini kullanarak yeni belgeler oluşturursanız, yazma sırasında sıcak nokta sorunuyla karşılaşmamalısınız.
Az belgeli bir koleksiyonda yüksek oranda yeni belge oluşturur.
Zaman damgası gibi monoton olarak artan bir alana sahip yeni belgeleri çok yüksek bir oranda oluşturur.
Bir koleksiyondaki belgeleri yüksek oranda siler.
Trafiği kademeli olarak artırmadan veritabanına çok yüksek bir hızda yazar.
Silinen verileri atlamaktan kaçının
Yakın zamanda silinen verileri atlayan sorgulardan kaçının. İlk 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, kuyruğa alınmış en eski iş öğelerini bulmaya çalışan bir iş yüküdür. Sorgu şöyle 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 silinmiş belgelerde created alan için dizin girişlerini tarar. Bu, sorguları yavaşlatır.
Performansı artırmak amacıyla başlamak için en iyi yeri bulmak amacıyla start_at yöntemini kullanın. Ö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-model olan monoton olarak artan bir alan kullanılmaktadır.
Trafiği hızlandırmak
Cloud Firestore'a artan trafiğe yönelik belgeleri hazırlaması için yeterli zaman tanımak amacıyla, yeni koleksiyonlara giden trafiği kademeli olarak artırmalı veya belgeleri sözlükbilimsel olarak kapatmalısınız. Yeni bir koleksiyona saniyede maksimum 500 işlemle başlamanızı ve ardından trafiği her 5 dakikada bir %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 ş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ış özellikle önemlidir. Bu geçişi gerçekleştirmenin basit bir yolu, eski koleksiyondan okumak ve belge mevcut değilse yeni koleksiyondan okumaktır. Ancak bu, yeni koleksiyondaki belgelerin sözlükbilimsel 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 trafiğe verimli bir şekilde hazırlayamayabilir.
Aynı koleksiyondaki birçok belgenin belge kimliğini 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 okumalar olarak bilinen örnek bir strateji verilmiştir. Bu stratejinin verileriniz için etkili olup olmadığını belirlemeniz gerekecektir ve önemli bir husus, geçiş sırasında paralel operasyonların maliyet etkisi olacaktır.
Paralel okumalar
Trafiği yeni bir koleksiyona taşırken paralel okumalar uygulamak için önce eski koleksiyondan okuyun. Belge eksikse yeni koleksiyondan okuyun. Var olmayan belgelerin yüksek oranda okunması, sıcak nokta tespitine yol açabilir; bu nedenle, yeni koleksiyonun yükünü kademeli olarak artırdığınızdan emin olun. Daha iyi bir strateji, eski belgeyi yeni koleksiyona kopyalamak ve ardından eski belgeyi silmektir. Cloud Firestore'un yeni koleksiyona gelen trafiği yönetebilmesini sağlamak için paralel okumaları kademeli olarak artırın.
Yeni bir koleksiyona yönelik okuma veya yazma işlemlerini kademeli olarak artırmak için olası bir strateji, yeni belgeler 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 karmasının sonucunun, işleviniz veya kullanıcı davranışı nedeniyle çarpık olmadığından emin olun.
Bu arada, tüm verilerinizi eski belgelerden yeni koleksiyona kopyalayan bir toplu iş çalıştırın. Toplu işiniz, sıcak noktaları önlemek için sıralı belge kimliklerine yazmaktan kaçınmalıdır. Toplu iş bittiğinde yalnızca yeni koleksiyondan okuyabilirsiniz.
Bu stratejinin geliştirilmiş hali, küçük kullanıcı gruplarını aynı anda taşımaktır. Kullanıcı belgesine, söz konusu kullanıcının geçiş durumunu izleyen bir alan ekleyin. Kullanıcı kimliğinin karmasına göre taşınacak bir grup kullanıcı seçin. Söz konusu kullanıcı grubu için belgeleri taşımak üzere bir toplu iş kullanın ve geçişin ortasındaki kullanıcılar için paralel okumaları kullanın.
Geçiş aşamasında hem eski hem de yeni varlıklara çift yazma işlemi yapmadığınız sürece kolayca geri dönemeyeceğinizi unutmayın. Bu, Cloud Firestore maliyetlerini artıracaktır.
Mahremiyet
- Hassas bilgileri Bulut Proje Kimliğinde depolamaktan kaçının. Bulut Proje Kimliği projenizin ömrü boyunca saklanabilir.
- Veri uyumluluğuyla ilgili en iyi uygulama olarak, hassas bilgilerin belge adlarında ve belge alan adlarında saklanmamasını öneririz.
Yetkisiz erişimi önleyin
Cloud Firestore Güvenlik Kuralları ile veritabanınızda yetkisiz işlemleri önleyin. Örneğin, kuralların kullanılması, kötü niyetli bir kullanıcının veritabanınızın tamamını tekrar tekrar indirdiği bir senaryoyu önleyebilir.
Cloud Firestore Güvenlik Kurallarını kullanma hakkında daha fazla bilgi edinin.