Uygulamalarınızı yüksek performans ve güvenilirlik için tasarlama konusunda bilinçli kararlar vermek için bu belgeyi okuyun. Bu belge gelişmiş Cloud Firestore konularını içerir. Cloud Firestore'a yeni başlıyorsanız bunun yerine hızlı başlangıç kılavuzuna bakın.
Cloud Firestore, Firebase ve Google Cloud'dan mobil cihaz, web ve sunucu geliştirmeye yönelik esnek, ölçeklenebilir bir veritabanıdır. Cloud Firestore'u kullanmaya başlamak, zengin ve güçlü uygulamalar yazmak çok kolaydır.
Veritabanı boyutunuz ve trafiğiniz arttıkça uygulamalarınızın iyi performans göstermeye devam etmesini sağlamak için Cloud Firestore arka ucundaki okuma ve yazma mekanizmalarını anlamanıza yardımcı olur. Ayrıca okuma ve yazma işlemlerinizin depolama katmanıyla etkileşimini ve performansı etkileyebilecek temel kısıtlamaları da anlamalısınız.
Uygulamanızın mimarisini oluşturmadan önce en iyi uygulamalar için aşağıdaki bölümlere bakın.
Üst düzey bileşenleri anlayın
Aşağıdaki şemada Cloud Firestore API isteğinde yer alan ü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'sine doğrudan HTTP ve RPC çağrıları yapabilirken, istemci kitaplıkları, API kullanımını basitleştirmek ve en iyi uygulamaları uygulamak için bir soyutlama katmanı sağlar. Ayrıca çevrimdışı erişim, önbellekler vb. gibi ek özellikler de sağlayabilirler.
Google Ön Uç (GFE)
Bu, tüm Google bulut hizmetlerinde ortak olan bir altyapı hizmetidir. GFE, gelen talepleri kabul eder ve bunları ilgili Google hizmetine (bu bağlamda Firestore hizmetine) iletir. Ayrıca Hizmet Reddi saldırılarına karşı koruma da dahil olmak üzere diğer önemli işlevleri de sağlar.
Bulut Firestore hizmeti
Cloud Firestore hizmeti, API isteği üzerinde kimlik doğrulama, yetkilendirme, kota kontrolleri ve güvenlik kurallarını içeren kontroller gerçekleştirir ve ayrıca işlemleri yönetir. Bu Cloud Firestore hizmeti, okunan ve yazılan veriler için depolama katmanıyla etkileşime giren 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 ilgili veritabanı özelliklerinin depolanmasından sorumludur. Aşağıdaki bölümlerde verilerin Cloud Firestore depolama katmanında nasıl düzenlendiği ve sistemin nasıl ölçeklendiği açıklanmaktadır. Verilerin nasıl organize edildiğini öğrenmek, ölçeklenebilir bir veri modeli tasarlamanıza ve Cloud Firestore'daki en iyi uygulamaları daha iyi anlamanıza yardımcı olabilir.
Anahtar Aralıklar ve Bölmeler
Cloud Firestore, NoSQL, belge odaklı bir veritabanıdır. Verileri, koleksiyon hiyerarşileri halinde düzenlenen belgelerde depolarsınız. Koleksiyon hiyerarşisi ve belge kimliği, her belge için tek bir anahtara çevrilir. Belgeler bu tek anahtarla mantıksal olarak depolanır ve sözlüksel olarak sıralanır. Anahtar aralığı terimini sözlükbilimsel olarak bitişik anahtar aralığını belirtmek için kullanırız.
Tipik bir Cloud Firestore veritabanı, tek bir fiziksel makineye sığmayacak kadar büyüktür. Verilerdeki iş yükünün tek bir makinenin kaldıramayacağı kadar ağır olduğu senaryolar da vardır. Büyük iş yüklerini yönetmek için Cloud Firestore, verileri birden fazla makinede veya depolama sunucusunda depolanabilecek ve bu sunuculardan sunulabilecek ayrı parçalara ayırır. Bu bölümler, veritabanı tablolarında bölme adı verilen anahtar aralık blokları halinde yapılır.
Eşzamanlı Çoğaltma
Veritabanının her zaman otomatik ve eşzamanlı olarak çoğaltıldığını unutmamak önemlidir. Veri bölmelerinin, bir bölge erişilemez hale geldiğinde bile kullanılabilir durumda kalmalarını sağlamak için farklı bölgelerde kopyaları bulunur. Bölünmenin farklı kopyalarına tutarlı çoğaltma, fikir birliği için Paxos algoritması tarafından yönetilir. Her bölümün bir kopyası, söz konusu bölüme yazma işlemlerini yürütmekten sorumlu olan Paxos lideri olarak görev yapmak üzere seçilir. Eşzamanlı çoğaltma size her zaman Cloud Firestore'daki verilerin en son sürümünü okuyabilme yeteneği sağlar.
Bunun genel sonucu, ağır iş yüklerinden bağımsız olarak ve çok büyük ölçekte hem okuma hem de yazma için düşük gecikmeler sağlayan, ölçeklenebilir ve yüksek düzeyde kullanılabilir bir sistemdir.
Veri düzeni
Cloud Firestore şemasız bir belge veritabanıdır. Ancak dahili olarak, verileri öncelikle depolama katmanındaki iki ilişkisel veritabanı stili tabloya aşağıdaki gibi yerleştirir:
- Belgeler tablosu: Belgeler bu tabloda saklanır.
- İndeksler tablosu: Sonuçların verimli bir şekilde alınmasını sağlayan ve indeks değerine göre sıralanan indeks girişleri bu tabloda saklanır.
Aşağıdaki diyagram, Cloud Firestore veritabanına ilişkin tabloların bölmelerle nasıl görünebileceğini göstermektedir. Bölmeler üç farklı bölgede çoğaltılır ve her bölmenin atanmış bir Paxos lideri vardır.
Tek Bölge ve Çoklu Bölge
Veritabanı oluşturduğunuzda bir bölge veya çoklu bölge seçmelisiniz.
Tek bir bölgesel konum, us-west1 gibi belirli bir coğrafi konumdur. Bir Cloud Firestore veritabanının veri bölümleri, daha önce açıklandığı gibi, seçilen bölge içindeki farklı bölgelerde replikalara sahiptir.
Çok bölgeli konum, veritabanının kopyalarının depolandığı tanımlı bir bölge kümesinden oluşur. Cloud Firestore'un çok bölgeli dağıtımında, bölgelerden ikisinde veritabanındaki tüm verilerin tam kopyaları bulunur. Üçüncü bir bölge, tam veri kümesini korumayan ancak çoğaltmaya katılan bir tanık kopyasına sahiptir. Verilerin birden fazla bölge arasında kopyalanmasıyla, tüm bölge kaybedilse bile veriler yazılabilir ve okunabilir.
Bir bölgenin konumları hakkında daha fazla bilgi için bkz. Cloud Firestore konumları .
Cloud Firestore'da bir yazma işleminin ömrünü anlayın
Cloud Firestore istemcisi, tek bir belge oluşturarak, güncelleyerek veya silerek veri yazabilir. Tek bir belgeye yazma işlemi, hem belgenin hem de onunla ilişkili dizin girişlerinin depolama katmanında atomik olarak güncellenmesini gerektirir. Cloud Firestore ayrıca bir veya daha fazla belgeye birden fazla okuma ve/veya yazma işlemi içeren atomik işlemleri de destekler.
Cloud Firestore, her türlü yazma işlemi için ilişkisel veritabanlarının ACID özelliklerini (atomiklik, tutarlılık, yalıtım ve dayanıklılık) sağlar. Cloud Firestore ayrıca seri hale getirilebilirlik de sağlar; bu, tüm işlemlerin seri sırayla yürütülüyormuş gibi görünmesi 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şlemi gerçekleştirdiğinde, dahili olarak bu, depolama katmanında bir veritabanı okuma-yazma işlemi olarak yürütülür. İşlem, Cloud Firestore'un daha önce bahsedilen ACID özelliklerini sağlamasını sağlar.
Cloud Firestore, bir işlemin ilk adımı olarak mevcut belgeyi okur ve Belgeler tablosundaki verilerde yapılacak değişiklikleri belirler.
Bu aynı zamanda Dizinler tablosunda aşağıdaki gibi gerekli güncellemelerin yapılmasını da içerir:
- Belgelere eklenen alanlar, Dizinler tablosunda karşılık gelen eklere ihtiyaç duyar.
- Belgelerden kaldırılan alanların Dizinler tablosunda ilgili silme işlemlerinin yapılması gerekir.
- Belgelerde değiştirilen alanların Dizinler tablosunda hem silinmesi (eski değerler için) hem de eklenmesi (yeni değerler için) gerekir.
Daha önce bahsedilen mutasyonları hesaplamak için Cloud Firestore, projenin indeksleme yapılandırmasını okur. Dizin oluşturma yapılandırması, bir projenin dizinleri hakkındaki bilgileri saklar. Cloud Firestore iki tür dizin kullanır: tek alanlı ve bileşik. Cloud Firestore'da oluşturulan dizinlerin ayrıntılı bir şekilde anlaşılması için bkz . Cloud Firestore'daki dizin türleri .
Mutasyonlar hesaplandıktan sonra Cloud Firestore bunları bir işlem içinde toplar ve ardından gerçekleştirir.
Depolama katmanındaki bir yazma işlemini anlama
Daha önce tartışıldığı gibi Cloud Firestore'daki bir yazma, depolama katmanında bir okuma-yazma işlemini içerir. Veri düzenine bağlı olarak, yazma işlemi, veri düzeninde görüldüğü gibi bir veya daha fazla bölmeyi içerebilir.
Aşağıdaki şemada, Cloud Firestore veritabanı tek bir bölgedeki üç farklı depolama sunucusunda barındırılan sekiz bölmeye (1-8 olarak işaretlenmiştir) sahiptir ve her bölme 3 (veya daha fazla) farklı bölgede çoğaltılır. Her bölümün bir Paxos lideri vardır ve bu lider, farklı bölümler için farklı bir bölgede olabilir.
Aşağıdaki gibi Restaurants koleksiyonuna sahip bir Cloud Firestore veritabanını düşünün:
Cloud Firestore istemcisi, priceCategory alanının değerini güncelleyerek Restaurant koleksiyonundaki bir belgede aşağıdaki değişikliği talep eder.
Aşağıdaki üst düzey adımlar, yazma işleminin bir parçası olarak neler olduğunu açıklar:
- Okuma-yazma işlemi oluşturun.
- Depolama katmanındaki Belgeler tablosundan
Restaurantskoleksiyonundakirestaurant1belgesini okuyun. - Belgenin dizinlerini Dizinler tablosundan okuyun.
- Verilere yapılacak mutasyonları hesaplayınız. Bu durumda beş mutasyon vardır:
- M1:
priceCategoryalanının değerindeki değişikliği yansıtacak şekilde Belgeler tablosundakirestaurant1satırını güncelleyin. - M2 ve M3: Azalan ve artan indeksler için İndeksler tablosundaki
priceCategoryeski değerine ait satırları silin. - M4 ve M5: Azalan ve artan dizinler için Dizinler tablosuna,
priceCategoryyeni değeri için satırları ekleyin.
- M1:
- Bu mutasyonları gerçekleştirin.
Cloud Firestore hizmetindeki depolama istemcisi, değiştirilecek satırların anahtarlarına sahip olan bölmeleri arar. Bölünmüş 3'ün M1'e hizmet ettiği ve Bölünmüş 6'nın M2-M5'e hizmet ettiği bir durumu ele alalım. Tüm bu bölünmeleri katılımcı olarak içeren dağıtılmış bir işlem var. Katılımcı bölmeleri, okuma-yazma işleminin bir parçası olarak verilerin daha önce okunduğu herhangi bir başka bölmeyi de içerebilir.
Aşağıdaki adımlar, taahhüdün bir parçası olarak neler olduğunu açıklar:
- Depolama istemcisi bir taahhütte bulunur. Taahhüt M1-M5 mutasyonlarını içerir.
- 3. ve 6. bölmeler bu işlemin katılımcılarıdır. Katılımcılardan biri koordinatör olarak seçilir, örneğin Split 3. Koordinatörün görevi, işlemin tüm katılımcılar arasında atomik olarak yapılmasını veya iptal edilmesini sağlamaktır.
- Bu bölünmelerin lider kopyaları, katılımcıların ve koordinatörlerin yaptığı işlerden sorumludur.
- Her katılımcı ve koordinatör, kendi kopyalarıyla bir Paxos algoritması çalıştırır.
- Lider, kopyalarla bir Paxos algoritması çalıştırıyor. Çoğaltmaların çoğunun lidere yanıt
ok to commitdurumunda yeter sayı elde edilir. - Daha sonra her katılımcı hazırlandıklarında koordinatöre bilgi verir (iki aşamalı taahhüdün ilk aşaması). Herhangi bir katılımcı işlemi gerçekleştiremezse tüm işlem
aborts.
- Lider, kopyalarla bir Paxos algoritması çalıştırıyor. Çoğaltmaların çoğunun lidere yanıt
- Koordinatör, kendisi de dahil olmak üzere tüm katılımcıların hazır olduğunu öğrendikten sonra,
acceptişlemi sonucunu tüm katılımcılara iletir (iki aşamalı taahhüdün ikinci aşaması). Bu aşamada her katılımcı taahhüt kararını stabil depolamaya kaydeder ve işlem taahhüt edilir. - Koordinatör, Cloud Firestore'daki depolama istemcisine işlemin gerçekleştirildiğine ilişkin yanıt verir. Buna paralel olarak koordinatör ve tüm katılımcılar mutasyonları verilere uygular.
Cloud Firestore veritabanı küçük olduğunda, tek bir bölünme M1-M5 mutasyonlarındaki tüm anahtarlara sahip olabilir. Böyle bir durumda işlemde yalnızca bir katılımcı vardır ve daha önce bahsedilen iki aşamalı taahhüt gerekli değildir, dolayısıyla yazma işlemleri daha hızlı gerçekleşir.
Çoklu bölgede yazar
Çok bölgeli bir dağıtımda, kopyaların bölgelere yayılması kullanılabilirliği artırır ancak performans maliyetini de beraberinde getirir. Farklı bölgelerdeki kopyalar arasındaki iletişim, daha uzun gidiş-dönüş süreleri gerektirir. Bu nedenle Cloud Firestore işlemlerinin temel gecikme süresi, tek bölge dağıtımlarıyla karşılaştırıldığında biraz daha fazladır.
Replikaları, bölünmeler için liderliğin her zaman birincil bölgede kalacağı şekilde yapılandırıyoruz. Birincil bölge, trafiğin Cloud Firestore sunucusuna geldiği bölgedir. Bu liderlik kararı, Cloud Firestore'daki depolama istemcisi ile replika lideri (veya çoklu bölünmüş işlemler için koordinatör) arasındaki iletişimdeki gidiş-dönüş gecikmesini azaltır.
Cloud Firestore'daki her yazma aynı zamanda Cloud Firestore'daki gerçek zamanlı motorla bir miktar etkileşimi de içerir. Gerçek zamanlı sorgular hakkında daha fazla bilgi için bkz. Gerçek zamanlı sorguları geniş ölçekte anlama .
Cloud Firestore'da bir okumanın ömrünü anlayın
Bu bölümde Cloud Firestore'daki bağımsız, gerçek zamanlı olmayan okumalar ele alınmaktadır. Cloud Firestore sunucusu dahili olarak bu sorguların çoğunu iki ana aşamada işler:
- Dizinler tablosu üzerinde tek aralıklı tarama
- Önceki taramanın sonucuna göre Belgeler tablosundaki nokta aramaları
Depolama katmanından okunan veriler, tutarlı okumalar sağlamak için dahili olarak bir veritabanı işlemi kullanılarak yapılır. Ancak yazma 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ı o 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'daki depolama istemcisi, depolama katmanına okuma zaman damgasının nasıl seçileceğini söyleyen bir zaman damgası sınırı belirtir. Cloud Firestore'da depolama istemcisi tarafından seçilen zaman damgası sınırının tü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'daki depolama katmanında nasıl işlendiği açıklanmaktadır.
Güçlü okumalar
Varsayılan olarak Cloud Firestore okumaları son derece tutarlıdır . Bu güçlü tutarlılık, Cloud Firestore okumasının, okumanın başlangıcına kadar gerçekleştirilen tüm yazma işlemlerini yansıtan verilerin en son sürümünü döndürdüğü anlamına gelir.
Tek Bölünmüş okuma
Cloud Firestore'daki depolama istemcisi, okunacak satırların anahtarlarına sahip olan bölmeleri arar. Önceki bölümdeki Split 3'ten bir okuma yapması gerektiğini varsayalım. İstemci, gidiş-dönüş gecikmesini azaltmak için okuma isteğini en yakın kopyaya gönderir.
Bu noktada seçilen replikaya bağlı olarak aşağıdaki durumlar meydana gelebilir:
- Okuma isteği bir lider kopyaya (Bölge A) gider.
- Lider her zaman güncel olduğundan okuma doğrudan devam edebilir.
- Okuma isteği lider olmayan bir kopyaya (Bölge B gibi) gider
- Bölme 3, dahili durumu aracılığıyla okumaya hizmet etmek için yeterli bilgiye sahip olduğunu bilebilir ve bölme bunu yapar.
- Split 3 en son verileri görüp görmediğinden emin değil. Okumayı sunmak için uygulaması gereken son işlemin zaman damgasını istemek üzere lidere bir mesaj gönderir. Bu işlem uygulandıktan sonra okuma devam edebilir.
Cloud Firestore daha sonra yanıtı istemcisine döndürür.
Çok bölmeli okuma
Okumaların birden fazla bölmeden yapılması gerektiği durumda, aynı mekanizma tüm bölmelerde gerçekleşir. Veriler tüm bölünmelerden döndürüldükten sonra Cloud Firestore'daki depolama istemcisi sonuçları birleştirir. Cloud Firestore daha sonra müşterisine bu verilerle yanıt verir.
Eski okumalar
Güçlü okumalar, Cloud Firestore'daki varsayılan moddur. Ancak liderle gerekli olabilecek iletişim nedeniyle potansiyel olarak daha yüksek gecikme maliyetine sahiptir. Çoğunlukla Cloud Firestore uygulamanızın verilerin en son sürümünü okumasına gerek yoktur ve işlevsellik, birkaç saniyelik eski olabilecek verilerle iyi çalışır.
Böyle bir durumda istemci, read_time read seçeneklerini kullanarak eski okumaları almayı tercih edebilir. Bu durumda, okumalar, veriler read_time olduğu gibi yapılır ve en yakın kopyanın, belirtilen read_time veriye sahip olduğunu zaten doğrulamış olması muhtemeldir. Belirgin derecede daha iyi performans için 15 saniye makul bir bayatlık değeridir. Eski okumalarda bile elde edilen satırlar birbiriyle tutarlıdır.
Sıcak noktalardan kaçının
Cloud Firestore'daki bölmeler, gerektiğinde veya anahtar alanı genişlediğinde trafiği daha fazla depolama sunucusuna sunma işini dağıtmak için otomatik olarak daha küçük parçalara bölünür. Fazla trafiği yönetmek için oluşturulan bölmeler, trafik kesilse bile yaklaşık 24 saat süreyle tutulur. Dolayısıyla, eğer trafikte tekrarlayan artışlar varsa, bölünmeler korunur ve gerektiğinde daha fazla bölünme uygulanı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 dikkat edilmesi gereken bazı sınırlamalar vardır.
Depolamayı ve yükü bölmek zaman alır ve trafiği çok hızlı artırmak, hizmet ayarlanırken yüksek gecikme süresine veya genellikle sıcak noktalar olarak adlandırılan son tarihin aşılması hatalarına neden olabilir. En iyi uygulama, işlemleri anahtar aralığına dağıtırken saniyede 500 işlem içeren 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. Bu işleme 500/50/5 kuralı denir ve veritabanını iş yükünüzü karşılayacak şekilde en iyi şekilde ölçeklendirecek şekilde konumlandırır.
Bölmeler artan yük ile otomatik olarak oluşturulsa da Cloud Firestore, bir anahtar aralığını yalnızca özel bir çoğaltılmış depolama sunucuları seti kullanarak tek bir belge sunana kadar bölebilir. Sonuç olarak, tek bir belge üzerinde yüksek ve sürekli hacimde eşzamanlı işlemler, o belgede bir sıcak noktaya yol açabilir. Tek bir belgede sürekli yüksek gecikmelerle karşılaşırsanız, verileri birden çok belgeye bölmek veya çoğaltmak için veri modelinizi değiştirmeyi düşünmelisiniz.
Birden fazla işlem aynı belgeyi aynı anda okumaya ve/veya yazmaya çalıştığında çekişme hataları meydana gelir.
Hotspotting'in başka bir özel durumu, Cloud Firestore'da belge kimliği olarak sıralı olarak artan/azalan bir anahtar kullanıldığında ve saniyede oldukça yüksek sayıda işlem gerçekleştiğinde meydana gelir. Daha fazla bölüm oluşturmanın burada bir faydası yok çünkü trafik artışı yeni oluşturulan bölüme doğru ilerliyor. Cloud Firestore, varsayılan olarak belgedeki tüm alanları otomatik olarak dizine eklediğinden, bu tür hareketli sıcak noktalar, zaman damgası gibi sıralı olarak artan/azalan bir değer içeren bir belge alanı için dizin alanında da oluşturulabilir.
Yukarıda özetlenen uygulamaları takip ederek Firestore'un, herhangi bir yapılandırmayı ayarlamanıza gerek kalmadan isteğe bağlı olarak büyük iş yüklerine hizmet edecek şekilde ölçeklenebileceğini unutmayın.
Sorun giderme
Firestore, Key Visualizer'ı kullanım modellerini analiz etmek ve etkin nokta belirleme sorunlarını gidermek için özel olarak tasarlanmış bir tanılama aracı olarak sağlar.
Sıradaki ne
- Daha fazla en iyi uygulama hakkında bilgi edinin
- Geniş ölçekte gerçek zamanlı sorgular hakkında bilgi edinin