Geniş ölçekte okuma ve yazma kavrayışı

Uygulamalarınızı yüksek performans ve güvenilirlik sağlayacak şekilde tasarlama konusunda bilinçli kararlar almak için bu belgeyi okuyun. Bu belge, gelişmiş Cloud Firestore konuları içerir. Cloud Firestore'u kullanmaya yeni başlıyorsanız 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 geliştirilmiş esnek ve ölçeklenebilir bir veritabanıdır. Cloud Firestore'u kullanmaya başlamak ve zengin, güçlü uygulamalar yazmak çok kolaydır.

Veritabanı boyutu ve trafik artarken uygulamalarınızın iyi performans göstermeye devam etmesini sağlamak için Cloud Firestore arka ucundaki okuma ve yazma mekaniklerini anlamanız önemlidir. 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. Uygulamalar Cloud Firestore API'ye doğrudan HTTP ve RPC çağrıları yapabilirken 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 Firestore hizmeti) yönlendirir. Ayrıca, Hizmet Reddi saldırılarına karşı koruma gibi başka önemli işlevler de sunar.

Cloud Firestore hizmeti

Cloud Firestore hizmeti, API isteğini kontrol eder. Bu kontroller arasında kimlik doğrulama, yetkilendirme, kota kontrolleri ve güvenlik kuralları yer alır ve işlemler de yönetilir. Bu Cloud Firestore hizmeti, veri okuma ve yazma işlemleri 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 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ğini öğrenerek ölçeklenebilir bir veri modeli tasarlayabilir ve Cloud Firestore'daki en iyi uygulamaları daha iyi anlayabilirsiniz.

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ığamayacak kadar büyüktür. 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üklerinin üstesinden gelmek için verileri ayrı parçalara ayırır. Bunlar birden fazla makinede ya da depolama sunucusunda depolanabilir ve sunulur. 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'daki verilerin en güncel sürümlerini her zaman okuyabilmenizi sağlar.

Sonuç olarak büyük ölçekte hem okuma hem 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ı tablolarının bölmeler halinde 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. Cloud Firestore veritabanının veri bölümleri, daha önce açıklandığı gibi, seçilen bölge içindeki farklı alt bölgelerde bulunan replikalara sahiptir.

Çok bölgeli konum, veritabanı replikalarının depolandığı tanımlanmış bölgeler grubundan oluşur. Cloud Firestore'un çok bölgeli dağıtımında bu bölgelerden ikisi, veritabanındaki tüm verilerin tam replikalarına sahiptir. Üçü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.

Bölgelerin konumları hakkında daha fazla bilgi için Cloud Firestore konumları sayfasına bakın.

Cloud Firestore'da yazma sürecinin ömrünü anlama

Cloud Firestore istemcisi tek bir belge 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, bir ya da daha fazla belgeye birden fazla okuma ve/veya yazma işleminden oluşan atomik işlemleri de destekler.

Cloud Firestore, her yazma türü 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 sayede tüm işlemler, seri siparişe göre yürütülmüş gibi görünür.

Yazma işlemindeki üst düzey adımlar

Cloud Firestore istemcisi daha önce bahsedilen yöntemlerden birini kullanarak bir yazma veya 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'un daha önce bahsedilen ACID özelliklerini sağlamasına olanak tanır.

Bir işlemin ilk adımı olarak Cloud Firestore, mevcut belgeyi okur ve Belgeler tablosundaki verilere 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ştirilen alanların Dizinler tablosunda hem silme (eski değerler için) hem de ekleme (yeni değerler için) olması gerekir.

Daha önce bahsedilen mutasyonları hesaplamak için Cloud Firestore, projenin dizine ekleme yapılandırmasını okur. Dizine ekleme yapılandırması, bir projenin dizinleriyle ilgili bilgileri depolar. Cloud Firestore, tek alanlı ve birleşik olmak üzere iki tür dizin kullanır. Cloud Firestore'da oluşturulan dizinler hakkında ayrıntılı bilgi edinmek için Cloud Firestore'daki dizin türleri bölümüne bakın.

Mutasyonlar hesaplandıktan sonra Cloud Firestore, mutasyonları bir işlemde toplar ve kaydeder.

Depolama katmanında yazma işlemini anlama

Daha önce belirtildiği gibi, Cloud Firestore'da 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.

Aşağıdaki şekilde Restaurants koleksiyonuna sahip bir Cloud Firestore veritabanı 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 eder.

Aşağıdaki üst düzey adımlarda, yazma işleminin bir parçası olarak neler olduğu açıklanmıştır:

1. Okuma-yazma işlemi oluşturun.
2. Depolama katmanındaki Documents tablosundan Restaurants koleksiyonundaki restaurant1 dokümanını okuyun.
3. Dizinler tablosundan dokümana ait dizinleri okuyun.
4. 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.
5. Bu değişiklikleri kaydedin.

Cloud Firestore hizmetindeki depolama alanı istemcisi, değiştirilecek satırların anahtarlarının sahibi olan bölmeleri 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:

1. Depolama istemcisi bir kayıt gerçekleştirir. Kaydetme, M1-M5 mutasyonlarını içerir.
2. 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 otomatik olarak gerçekleşmesini 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.
3. 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.
4. Koordinatör kendisi de dahil olmak üzere tüm katılımcıların hazır olduğunu bildikten sonra accept işlem sonucunu tüm katılımcılara bildirir (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.
5. Koordinatör, Cloud Firestore'daki 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 gelen trafiğin geldiği bölgedir. Bu liderlik kararı, Cloud Firestore'daki depolama alanı istemcisi ile replika lideri (veya çok bölümlü işlemler için koordinatör) arasındaki iletişimde gidiş dönüş gecikmesini azaltır.

Cloud Firestore'daki her yazma işlemi, Cloud Firestore'daki gerçek zamanlı altyapıyla bir miktar etkileşim 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'da okuma işlemlerinin kullanım ömrünü anlama

Bu bölümde Cloud Firestore'daki 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:

1. Dizinler tablosu üzerinden tek aralık taraması
2. Dokümanlar tablosunda, önceki taramanın sonucuna göre aramalara işaret et

Cloud Firestore'da daha az veya daha fazla işleme gerektiren belirli sorgular (örneğin, IN sorguları) olabilir.

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. Cloud Firestore'daki depolama istemcisi, bu işlemi gerçekleştirmek için zaman damgası sınırı belirtir. Bu zaman damgası, depolama katmanına okuma zaman damgasının nasıl seçileceğini bildirir. Cloud Firestore'da depolama alanı istemcisi tarafından seçilen zaman damgası 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 veri okumasının, okumanın başına kadar kaydedilen tüm yazma işlemlerini yansıtan en son veri sürümünü döndürdüğü anlamına gelir.

Tek Bölme okuma

Cloud Firestore'daki 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.

Daha sonra Cloud Firestore, 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. Tüm bölümlerden alınan veriler döndürüldüğünde Cloud Firestore'daki depolama istemcisi sonuçları birleştirir. Daha sonra Cloud Firestore, istemcisine bu verilerle yanıt verir.

Eski okumalar

Güçlü okuma işlemleri, Cloud Firestore'daki varsayılan moddur. Ancak liderle iletişim kurması gereken durumlar nedeniyle bu gecikmenin daha yüksek bir gecikme oranına sahip olması gerekir. Cloud Firestore uygulamanızın genellikle verilerin en yeni 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, okuma işlemleri 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'daki bölümler, gerektiğinde veya anahtar alanı genişlediğinde hizmet trafiği daha fazla depolama sunucusuna dağıtmak 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, anahtar aralığını yalnızca çoğaltılmış depolama sunucularından oluşan özel bir küme 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'da belge kimliği olarak sırayla artan/azaltma anahtarı kullanıldığında ve saniye başına işlem sayısının önemli ölçüde yüksek olmasıyla 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, varsayılan olarak belgedeki tüm alanları otomatik olarak dizine eklediğinden bu tür hareketli hotspot'lar, zaman damgası gibi sırayla artan/azalan bir değer içeren belge alanı için dizin alanında da oluşturulabilir.

Yukarıda açıklanan uygulamalar uygulanarak Firestore, herhangi bir yapılandırma ayarı yapmanıza gerek kalmadan isteğe bağlı olarak büyük iş yüklerine hizmet verecek şekilde ölçeklendirilebilir.

Sorun giderme

Firestore, kullanım kalıplarını analiz etmek ve hotspot sorunlarını gidermek için özel olarak tasarlanmış bir 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