Uygulamalarınızı yüksek performans ve güvenilirlik sağlayacak şekilde tasarlama konusunda bilinçli kararlar almak için bu belgeyi okuyun. Bu doküman ileri seviye Cloud Firestore konuları içeriyor. Yeni başlıyorsanız Cloud Firestore, bu makale yerine hızlı başlangıç kılavuzuna göz atın.
Cloud Firestore, Firebase ve Google Cloud tarafından sunulan mobil cihaz, web ve sunucu geliştirme için esnek ve ölçeklenebilir bir veritabanıdır. Cloud Firestore kullanmaya başlamak ve zengin, güçlü uygulamalar yazmak çok kolaydır.
Veritabanı boyutunuz ve trafiğiniz artarken uygulamalarınızın iyi performans göstermeye devam etmesini sağlamak için Cloud Firestore arka ucunda okuma ve yazma mekanizmasının anlaşılmasına yardımcı olur. Ayrıca okuma ve yazma işlemlerinizin depolama katmanıyla etkileşimini ve performansı etkileyebilecek temel kısıtlamaları da anlamanız gerekir.
Uygulamanızı tasarlamadan önce en iyi uygulamalar için aşağıdaki bölümlere göz atın.
Üst düzey bileşenleri anlama
Aşağıdaki şemada, Cloud Firestore API isteğindeki üst düzey bileşenler gösterilmektedir.
Cloud Firestore SDK'sı ve istemci kitaplıkları
Cloud Firestore, farklı platformlar için SDK'ları ve istemci kitaplıklarını destekler. Bir uygulama Cloud Firestore API'ye doğrudan HTTP ve RPC çağrıları yapabilse de istemci kitaplıkları, API kullanımını basitleştirmek ve en iyi uygulamaları hayata geçirmek için bir soyutlama katmanı sağlar. Ayrıca çevrimdışı erişim ve önbellek gibi ek özellikler de sağlayabilirler.
Google Kullanıcı Arabirimi (GFE)
Bu, tüm Google bulut hizmetlerinde ortak olarak kullanılan bir altyapı hizmetidir. GFE gelen istekleri kabul eder ve ilgili Google hizmetine (bu bağlamda Cloud Firestore hizmeti) yönlendirir. Ayrıca, Hizmet Reddi saldırılarına karşı koruma gibi başka önemli işlevler de sunar.
Cloud Firestore hizmet
Cloud Firestore hizmeti, API isteğini kimlik doğrulama, yetkilendirme, kota kontrolleri ve güvenlik kuralları gibi kontroller ile yönetir ve işlemleri de yönetir. Bu Cloud Firestore hizmeti, veri okuma ve yazma işlemleri için depolama katmanıyla etkileşimde bulunan bir depolama istemcisi içerir.
Cloud Firestore depolama katmanı
Cloud Firestore depolama katmanı, hem verilerin hem de meta verilerin ve Cloud Firestore tarafından sağlanan ilişkili veritabanı özelliklerini depolamaktan sorumludur. Aşağıdaki bölümlerde verilerin Cloud Firestore depolama katmanında nasıl düzenlendiği ve sistemin nasıl ölçeklendirildiği açıklanmaktadır. Verilerin nasıl düzenlendiği hakkında bilgi edinmek, ölçeklenebilir bir veri modeli tasarlamanıza ve Cloud Firestore konusundaki en iyi uygulamaları daha iyi anlamanıza yardımcı olabilir.
Tuş Aralıkları ve Bölmeler
Cloud Firestore, NoSQL, belge tabanlı bir veritabanıdır. Verileri, koleksiyon hiyerarşileri halinde düzenlenen dokümanlarda depolarsınız. Koleksiyon hiyerarşisi ve doküman kimliği, her doküman için tek bir anahtara dönüştürülür. Dokümanlar bu tek anahtara göre mantıksal olarak depolanır ve sözlüksel olarak sıralanır. Sözlüksel olarak bitişik bir anahtar aralığını ifade etmek için "anahtar aralığı" terimini kullanırız.
Tipik bir Cloud Firestore veritabanı, tek bir fiziksel makineye sığmayacak kadar büyük. Veriler üzerindeki iş yükünün bir makinenin kaldıramayacağı kadar ağır olduğu senaryolar da vardır. Cloud Firestore, büyük iş yüklerini yönetmek için verileri birden çok makinede veya depolama sunucusunda depolanabilecek ve onlardan sunulabilecek ayrı parçalara ayırır. Bu bölümler, veritabanı tablolarında, bölme adı verilen anahtar aralığı bloklarında yapılır.
Eşzamanlı Çoğaltma
Veritabanının her zaman otomatik ve eşzamanlı olarak çoğaltıldığını unutmayın. Veri bölmelerinde, alt bölge erişilemez olduğunda bile kullanılabilir durumda kalmaları için farklı alt bölgelerde replikalar bulunur. Bölmenin farklı kopyalarına tutarlı çoğaltma, fikir birliği için Paxos algoritması tarafından yönetilir. Her bir bölümün bir kopyası, Paxos lideri olarak seçilir ve bu kopya, bu bölmeye yazma işlemlerinin yapılmasından sorumlu olur. Eşzamanlı çoğaltma, Cloud Firestore verilerinin en son sürümünü her zaman okuyabilmenizi sağlar.
Sonuç olarak büyük ölçekte hem okuma hem de yazma işlemleri için düşük gecikme süreleri sağlayan ölçeklenebilir ve yüksek düzeyde kullanılabilir bir sistem elde edilir.
Veri düzeni
Cloud Firestore, şemasız belge veritabanıdır. Bununla birlikte, verileri dahili olarak depolama katmanındaki ilişkisel veritabanı stilindeki iki tabloda şu şekilde düzenler:
- Dokümanlar tablosu: Dokümanlar bu tabloda depolanır.
- Dizinler tablosu: Sonuçları verimli şekilde almayı ve dizin değerine göre sıralamayı mümkün kılan dizin girişleri bu tabloda depolanır.
Aşağıdaki şemada, Cloud Firestore veritabanına ait tabloların bölmelerde nasıl görünebileceği gösterilmektedir. Bölmeler üç farklı alt bölgeye çoğaltılır ve her bölümde kendisine atanmış bir Paxos lideri bulunur.
Tek Bölge ve Çoklu Bölge
Veritabanı oluşturduğunuzda bir bölge veya çoklu bölge seçmeniz gerekir.
Tek bir bölgesel konum, us-west1 gibi belirli bir coğrafi konumdur. Bir Cloud Firestore veritabanının veri bölümlerinde, daha önce açıklandığı gibi, seçilen bölgedeki farklı alt bölgelerde replikalar bulunur.
Çok bölgeli konum, veritabanı replikalarının depolandığı tanımlanmış bölgeler grubundan oluşur. Cloud Firestore paketinin çok bölgeli dağıtımında, bu bölgelerden ikisi veritabanındaki tüm verilerin tam replikalarına sahip. Üçüncü bir bölgede, tam veri kümesini sağlamayan ancak kopyalamaya katılan bir teşhis replikası bulunur. Verilerin birden çok bölge arasında kopyalanması sayesinde bir bölgenin tamamı kaybetse bile veriler yazılabilir ve okunabilir.
Bir bölgenin konumları hakkında daha fazla bilgi edinmek için Cloud Firestore konumları bölümüne bakın.
Cloud Firestore ürününde yazım süreci hakkında bilgi edinin
Bir Cloud Firestore istemcisi tek bir doküman oluşturarak, güncelleyerek veya silerek veri yazabilir. Tek bir dokümana yazma işlemi, hem belgenin hem de dokümanla ilişkili dizin girişlerinin depolama katmanında atomik olarak güncellenmesini gerektirir. Cloud Firestore, birden fazla okuma ve/veya bir ya da daha fazla belgeye yazma işleminden oluşan atomik işlemleri de destekler.
Cloud Firestore, tüm yazma türleri için ilişkisel veritabanlarının ACID özelliklerini (atomiklik, tutarlılık, izolasyon ve dayanıklılık) sağlar. Cloud Firestore ayrıca serileştirilebilirlik sağlar. Bu, tüm işlemlerin bir seri siparişteymiş gibi göründüğü anlamına gelir.
Yazma işlemindeki üst düzey adımlar
Cloud Firestore istemcisi daha önce bahsedilen yöntemlerden herhangi birini kullanarak bir yazma işlemi gerçekleştirdiğinde veya bir işlem gerçekleştirdiğinde, dahili olarak bu işlem depolama katmanında bir veritabanı okuma-yazma işlemi olarak yürütülür. Bu işlem, Cloud Firestore ürününün daha önce bahsedilen ACID özelliklerini sağlamasına olanak tanır.
Cloud Firestore, bir işlemin ilk adımı olarak mevcut dokümanı okur ve Belgeler tablosundaki verilerde yapılacak değişiklikleri belirler.
Bu süreç, Dizinler tablosunda aşağıdaki gibi gerekli güncellemelerin yapılmasını da içerir:
- Belgelere eklenen alanların Dizinler tablosunda karşılık gelen eklemeler olması gerekir.
- Dokümanlardan kaldırılan alanlar için Dizinler tablosunda ilgili silme işlemlerinin yapılması gerekir.
- Dokümanlarda değişiklik yapılan alanlar için hem silme (eski değerler için) hem de ekleme (yeni değerler için) gerekir açılır.
Cloud Firestore, daha önce bahsedilen mutasyonları hesaplamak için projenin dizine ekleme yapılandırmasını okur. Dizine ekleme yapılandırması, bir projenin dizinleriyle ilgili bilgileri depolar. Cloud Firestore iki tür dizin kullanır: tek alanlı ve birleşik dizin. Cloud Firestore ürününde oluşturulan dizinler hakkında ayrıntılı bilgi edinmek için Cloud Firestore ürünündeki dizin türleri başlıklı makaleyi inceleyin.
Mutasyonlar hesaplandıktan sonra Cloud Firestore bunları bir işlemde toplar ve ardından kaydeder.
Depolama katmanında yazma işlemini anlama
Daha önce açıklandığı gibi, Cloud Firestore ürününde yazma işlemi, depolama katmanında bir okuma-yazma işlemi içerir. Verilerin düzenine bağlı olarak, yazma işlemi veri düzeninde görüldüğü gibi bir veya daha fazla bölme içerebilir.
Aşağıdaki şemada Cloud Firestore veritabanı, tek bir alt bölgede üç farklı depolama sunucusunda barındırılan ve 1-8 olarak işaretlenmiş sekiz bölüme sahiptir ve her bölme 3 (veya daha fazla) farklı alt bölgeye çoğaltılmıştır. Her bölmenin bir Paxos lideri vardır. Paxos, farklı bölümler için farklı alt bölgelerde yer alabilir.
Cloud Firestore veritabanı bölme">
Restaurants
koleksiyonuna sahip bir Cloud Firestore veritabanını aşağıdaki gibi düşünün:
Cloud Firestore istemcisi, priceCategory
alanının değerini güncelleyerek Restaurant
koleksiyonundaki bir dokümanda aşağıdaki değişikliği talep ediyor.
Aşağıdaki üst düzey adımlarda, yazma işleminin bir parçası olarak neler olduğu açıklanmıştır:
- Okuma-yazma işlemi oluşturun.
- Depolama katmanındaki Documents tablosundan
Restaurants
koleksiyonundakirestaurant1
dokümanını okuyun. - Dizinler tablosundan dokümana ait dizinleri okuyun.
- Veriler üzerinde yapılacak mutasyonları hesaplayın. Bu durumda beş mutasyon vardır:
- M1: Dokümanlar tablosundaki
restaurant1
satırını,priceCategory
alanının değerindeki değişikliği yansıtacak şekilde güncelleyin. - M2 ve M3: Azalan ve artan dizinler için Dizinler tablosundaki eski
priceCategory
değerine ait satırları silin. - M4 ve M5: Azalan ve artan dizinler için Dizinler tablosuna yeni
priceCategory
değerine ait satırları ekleyin.
- M1: Dokümanlar tablosundaki
- Bu değişiklikleri kaydedin.
Cloud Firestore hizmetindeki depolama alanı istemcisi, değiştirilecek satırların anahtarlarının sahibi olan bölümleri arar. Bölme 3'ün Y1'e, Bölme 6'nın ise Y2-M5'e hizmet verdiği bir durumu ele alalım. Tüm bu bölümleri katılımcı olarak içeren dağıtılmış bir işlem bulunur. Katılımcı bölmeleri, okuma-yazma işleminin bir parçası olarak verilerin daha önce okunduğu diğer tüm bölümleri de içerebilir.
Aşağıdaki adımlarda, kaydetme kapsamında ne olacağı açıklanmaktadır:
- Depolama istemcisi bir kayıt gerçekleştirir. Kaydetme, M1-M5 mutasyonlarını içerir.
- Bölme 3 ve 6, bu işlemin katılımcılarıdır. Katılımcılardan biri koordinatör olarak (ör. Bölüm 3) seçilir. Koordinatörün görevi, işlemin tüm katılımcılar arasında atomik bir biçimde iptal edilmesini veya iptal edilmesini sağlamaktır.
- Bu bölümlerin başındaki kişiler, katılımcılar ve koordinatörler tarafından yapılan işlerden sorumludur.
- Her katılımcı ve koordinatör, ilgili replikalarıyla birlikte bir Paxos algoritması yürütür.
- Lider, replikalarla bir Paxos algoritması çalıştırır. Replikaların çoğu lidere
ok to commit
yanıtıyla yanıt verirse kuoruma ulaşılır. - Daha sonra her katılımcı hazırlanırken koordinatörü bilgilendirir (iki aşamalı kaydetmenin ilk aşaması). Herhangi bir katılımcı işlemi gerçekleştiremezse işlemin tamamı
aborts
.
- Lider, replikalarla bir Paxos algoritması çalıştırır. Replikaların çoğu lidere
- Koordinatör kendisi dahil tüm katılımcıların hazırlandığını bildikten sonra
accept
işlem sonucunu tüm katılımcılara iletir (iki aşamalı taahhüdün ikinci aşaması). Bu aşamada her katılımcı, kararlı depolama alanında taahhüt kararını kaydeder ve işlem gerçekleştirilir. - Koordinatör Cloud Firestore uygulamasındaki depolama alanı istemcisine işlemin gerçekleştirildiğini bildirir. Buna paralel olarak koordinatör ve tüm katılımcılar mutasyonları verilere uygular.
Cloud Firestore veritabanı küçükse M1-M5 mutasyonlarındaki tüm anahtarlar tek bir bölmeye sahip olabilir. Böyle bir durumda, işlemde yalnızca bir katılımcı olur ve daha önce bahsedilen iki aşamalı taahhüt gerekli değildir. Böylece yazma işlemleri hızlanır.
Çoklu bölgede yazar
Çok bölgeli dağıtımda, replikaların bölgelere yayılması kullanılabilirliği artırır ancak performans maliyetini de beraberinde getirir. Farklı bölgelerdeki replikalar arasındaki iletişim daha uzun gidiş dönüş süreleri sürer. Bu nedenle, Cloud Firestore işlemleri için referans gecikme, tek bölgeli dağıtımlara kıyasla biraz daha fazladır.
Replikaları, bölümlerin liderliği her zaman birincil bölgede kalacak şekilde yapılandırıyoruz. Birincil bölge, Cloud Firestore sunucusuna trafiğin geldiği bölgedir. Yönetimin bu kararı, Cloud Firestore bölgesindeki depolama alanı istemcisi ile replika lideri (veya çok bölümlü işlemler için koordinatör) arasındaki iletişimde yaşanan gidiş dönüş gecikmesini azaltır.
Cloud Firestore içindeki her yazma işlemi, Cloud Firestore içindeki gerçek zamanlı motorla bazı etkileşimler de içerir. Gerçek zamanlı sorgular hakkında daha fazla bilgi için Geniş ölçekte gerçek zamanlı sorguları anlama başlıklı makaleyi inceleyin.
Cloud Firestore uygulamasında okuma materyalinin ömrü hakkında bilgi edinin
Bu bölümde Cloud Firestore dilindeki bağımsız, gerçek zamanlı olmayan okumalar incelenmektedir. Cloud Firestore sunucusu, dahili olarak bu sorguların çoğunu iki ana aşamada işler:
- Dizinler tablosu üzerinden tek aralık taraması
- Dokümanlar tablosunda, önceki taramanın sonucuna göre aramalara işaret et
Depolama katmanından okumalar, tutarlı okumalar sağlamak için bir veritabanı işlemi kullanılarak dahili olarak yapılır. Ancak, yazma işlemleri için kullanılan işlemlerden farklı olarak bu işlemler kilit almaz. Bunun yerine, bir zaman damgası seçerek ve ardından tüm okumaları bu zaman damgasında yürüterek çalışırlar. Kilit almadıkları için eşzamanlı okuma-yazma işlemlerini engellemezler. Bu işlemi yürütmek için Cloud Firestore öğesindeki depolama alanı istemcisi, zaman damgası sınırı belirtir. Bu zaman damgası, depolama katmanına okuma zaman damgasının nasıl seçileceğini bildirir. Depolama istemcisinin Cloud Firestore ürününde seçtiği zaman damgası sınırı, okuma isteğinin okuma seçeneklerine göre belirlenir.
Depolama katmanındaki okuma işlemini anlama
Bu bölümde, okuma türleri ve bunların Cloud Firestore ürünündeki depolama katmanında nasıl işlendiği açıklanmaktadır.
Güçlü okumalar
Varsayılan olarak Cloud Firestore okuma işlemleri son derece tutarlıdır. Bu güçlü tutarlılık, Cloud Firestore okumasının, okumanın başına kadar kaydedilen tüm yazmaları yansıtan verilerin en son sürümünü döndüreceği anlamına gelir.
Tek Bölme okuma
Cloud Firestore ürünündeki depolama alanı istemcisi, okunacak satırların anahtarlarına sahip olan bölümleri arar. Bu kodun, önceki bölümün 3. Bölümü'nden bir okuma yapması gerektiğini varsayalım. İstemci, gidiş dönüş gecikmesini azaltmak için okuma isteğini en yakın replikaya gönderir.
Bu noktada, seçilen replikaya bağlı olarak aşağıdaki durumlar yaşanabilir:
- Okuma isteği, lider replikaya (A Bölgesi) gider.
- Lider her zaman güncel olduğu için okuma işlemine doğrudan devam edebilirsiniz.
- Okuma isteği, lider olmayan bir replikaya (ör. B Bölgesi) gider
- Bölme 3, dahili durumundan okumayı gerçekleştirmek için yeterli bilgiye sahip olduğunu ve bölme bunu yapar.
- 3. bölüm en son verileri görüp görmediğinden emin değil. Lidere, okumayı sunmak için uygulanması gereken son işlemin zaman damgasını sormak amacıyla bir mesaj gönderir. İşlem uygulandıktan sonra okuma işlemi devam edebilir.
Cloud Firestore, daha sonra yanıtı istemcisine döndürür.
Bölünmüş okuma
Okumaların birden fazla bölümden yapılması gerektiğinde, tüm bölümlerde aynı mekanizma uygulanır. Veriler tüm bölümlerden döndürüldükten sonra, Cloud Firestore öğesindeki depolama alanı istemcisi sonuçları birleştirir. Cloud Firestore, müşterisine bu verilerle yanıt verir.
Eski okumalar
Güçlü okumalar, Cloud Firestore ürünündeki varsayılan moddur. Ancak liderle iletişim kurması gereken durumlar nedeniyle bu gecikmenin daha yüksek bir gecikme oranına sahip olması gerekir. Genellikle Cloud Firestore uygulamanızın verilerin en son sürümünü okuması gerekmez ve işlevsellik birkaç saniye eski olabilecek verilerle iyi performans gösterir.
Böyle bir durumda istemci, read_time
okuma seçeneklerini kullanarak eski okumaları almayı tercih edebilir. Bu durumda, okumalar veriler read_time
konumunda olduğundan yapılır ve en yakın replika büyük olasılıkla belirtilen read_time
konumunda veri bulunduğunu doğrulamış demektir.
Dikkat çekici şekilde daha iyi performans için 15 saniye, makul bir eskilik değeridir. Eski okumalarda bile, verilen satırlar birbirleriyle tutarlıdır.
Hotspot'lardan kaçınma
Cloud Firestore içindeki bölümler, gerektiğinde veya anahtar alanı genişlediğinde trafik sunma işinin daha fazla depolama sunucusuna dağıtılması için otomatik olarak daha küçük parçalara ayrılır. Fazla trafiği yönetmek için oluşturulan bölümler, trafik kopsa bile yaklaşık 24 saat boyunca saklanır. Dolayısıyla, yinelenen trafik artışları varsa bölmeler korunur ve gerektiğinde daha fazla bölme yapılır. Bu mekanizmalar, Cloud Firestore veritabanlarının artan trafik yükü veya veritabanı boyutu altında otomatik olarak ölçeklendirilmesine yardımcı olur. Ancak, aşağıda açıklandığı gibi, bilinmesi gereken bazı sınırlamalar vardır.
Depolama alanının ve yükün bölünmesi zaman alır. Trafiğin çok hızlı artırılması, yüksek gecikme veya teslim tarihinin aşılması hatalarına (genellikle hotspot'lar olarak bilinir) yol açabilir. En iyi uygulama, işlemleri anahtar aralığı genelinde dağıtırken saniyede 500 işlem olan bir veritabanındaki koleksiyondaki trafiği artırmaktır. Bu kademeli artışın ardından, trafiği her beş dakikada bir% 50'ye kadar artırın. 500/50/5 kuralı adı verilen bu işlem, veritabanını iş yükünüzü karşılayacak şekilde optimum ölçeklenecek şekilde konumlandırır.
Bölmeler artan yük ile otomatik olarak oluşturulsa da Cloud Firestore, bir anahtar aralığını yalnızca çoğaltılmış depolama sunucularının özel kümesini kullanarak tek bir doküman sunana kadar bölebilir. Sonuç olarak, tek bir doküman üzerinde aynı anda gerçekleşen yüksek ve sürekli hacimlerde işlem hacimleri, söz konusu dokümanda bir hotspot oluşmasına yol açabilir. Tek bir dokümanda sürekli olarak yüksek gecikmelerle karşılaşıyorsanız verileri birden fazla belgeye bölmek veya kopyalamak için veri modelinizi değiştirmeniz önerilir.
Birden fazla işlem, aynı dokümanı aynı anda okumaya ve/veya yazmaya çalıştığında çakışma hataları ortaya çıkar.
Diğer bir özel hotspot da, Cloud Firestore ürününde belge kimliği olarak sırayla artan/azaltma anahtarı kullanıldığında ve saniyede önemli ölçüde yüksek işlem sayısı olduğunda ortaya çıkar. Trafiğin artışı yeni oluşturulan bölüme taşındığı için daha fazla bölüm oluşturmak burada bir işe yaramaz. Cloud Firestore, dokümandaki tüm alanları varsayılan olarak dizine otomatik olarak eklediğinden, zaman damgası gibi sırayla artan/azalan bir değer içeren doküman alanı için dizin alanında bu tür hareketli hotspot'lar da oluşturulabilir.
Yukarıda açıklanan uygulamalar uygulanarak Cloud Firestore ürününün herhangi bir yapılandırma ayarı yapmanıza gerek kalmadan rastgele büyük iş yükleri için ölçeklenebileceğini unutmayın.
Sorun giderme
Cloud Firestore, kullanım kalıplarını analiz etmek ve hotspot ile ilgili sorunları gidermek için tasarlanmış teşhis aracı olarak Key Visualizer'ı sunar.
Sonraki Adımlar
- Diğer en iyi uygulamalar hakkında bilgi edinin.
- Geniş ölçekte gerçek zamanlı sorgular hakkında bilgi edinin