Geniş ölçekte okuma ve yazma işlemlerini anlayın

Uygulamalarınızı yüksek performans ve güvenilirlik sağlayacak şekilde tasarlamak için bilinçli kararlar almak istiyorsanız bu dokümanı okuyun. Bu belgede ileri düzey Cloud Firestore konuları yer almaktadır. Cloud Firestore'i 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 esnek, ölçeklenebilir bir veritabanıdır. Cloud Firestore ile çalışmaya başlamak ve zengin, güçlü uygulamalar yazmak çok kolaydır.

Veritabanınızın boyutu ve trafiğiniz arttıkça uygulamalarınızın iyi performans göstermeye devam etmesi için Cloud Firestore arka ucundaki okuma ve yazma mekanizmalarını anlamanız faydalı 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 bakın.

Üst düzey bileşenleri anlama

Aşağıdaki şemada, Cloud Firestore API isteğinde yer alan üst düzey bileşenler gösterilmektedir.

Üst düzey bileşenler

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'sine doğrudan HTTP ve RPC çağrıları yapabilir. İstemci kitaplıkları ise 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, önbellekler gibi ek özellikler de sağlayabilirler.

Google Front End (GFE)

Bu, tüm Google bulut hizmetlerinde ortak olan 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 diğer önemli işlevleri de sağlar.

Cloud Firestore hizmet

Cloud Firestore hizmeti; kimlik doğrulama, yetkilendirme, kota kontrolleri ve güvenlik kuralları dahil olmak üzere API isteğiyle ilgili kontrolleri gerçekleştirir ve işlemleri yönetir. Bu Cloud Firestore hizmeti, veri okuma ve yazma işlemleri için depolama katmanıyla etkileşim kuran 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ı ö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çeklendirildiği açıklanmaktadır. Verilerin nasıl düzenlendiğini öğrenmek, ölçeklenebilir bir veri modeli tasarlamanıza ve Cloud Firestore ile ilgili en iyi uygulamaları daha iyi anlamanıza yardımcı olabilir.

Anahtar Aralıkları ve Bölünmeler

Cloud Firestore, NoSQL tabanlı, belge odaklı 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 çevrilir. Dokümanlar mantıksal olarak depolanır ve bu tek anahtara göre sözlük düzeninde sıralanır. Sözlükbilimsel 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üktür. Veriler üzerindeki iş yükünün tek 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 fazla makinede veya depolama sunucusunda depolanıp sunulabilecek ayrı parçalara böler. Bu bölümler, veritabanı tablolarında "bölme" adı verilen anahtar aralıkları blokları halinde oluşturulur.

Eşzamanlı replikasyon

Veritabanının her zaman otomatik ve eşzamanlı olarak kopyalandığını unutmayın. Veri bölümlerinin farklı bölgelerde replikaları bulunur. Böylece bir bölgeye erişilemediğinde bile veriler kullanılabilir durumda kalır. Bölümün farklı kopyalarına tutarlı replikasyon, mutabakat için Paxos algoritması tarafından yönetilir. Her bir parçanın bir replikası, Paxos lideri olarak seçilir. Bu replika, ilgili parçaya yazma işlemlerini gerçekleştirmekten sorumludur. Eşzamanlı replikasyon, Cloud Firestore verilerinin en yeni sürümünü her zaman okuyabilmenizi 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şlemleri için düşük gecikme süreleri sağlayan, ölçeklenebilir ve yüksek kullanılabilirliğe sahip bir sistemdir.

Veri düzeni

Cloud Firestore, şemasız bir doküman veritabanıdır. Ancak dahili olarak, verileri depolama katmanında öncelikle aşağıdaki gibi iki ilişkisel veritabanı tarzı tabloda düzenler:

  • Documents tablosu: Dokümanlar bu tabloda depolanır.
  • Dizinler tablosu: Sonuçların verimli bir şekilde alınmasını ve dizin değerine göre sıralanmasını sağlayan dizin girişleri bu tabloda depolanır.

Aşağıdaki diyagramda, Cloud Firestore veritabanı tablolarının bölmelerle nasıl görünebileceği gösterilmektedir. Bölümler üç farklı bölgede kopyalanır ve her bölümün atanmış bir Paxos lideri vardır.

Veri düzeni

Tek bölge ve çoklu bölge karşılaştırması

Veritabanı oluştururken bir bölge veya çoklu bölge seçmeniz gerekir.

Tek bir bölgesel konum, us-west1 gibi belirli bir coğrafi konumdur. Daha önce açıklandığı gibi, Cloud Firestore veritabanının veri bölümlerinin seçilen bölgedeki farklı bölgelerde replikaları vardır.

Çok bölgeli konum, veritabanı replikalarının depolandığı tanımlı bir bölge grubundan oluşur. Cloud Firestore'ın çok bölgeli dağıtımında, bölgelerden ikisinde veritabanındaki tüm verilerin tam replikaları bulunur. Üçüncü bir bölgede, tam bir veri kümesi bulundurmayan ancak replikasyona katılan bir tanık replika bulunur. Veriler birden fazla bölge arasında kopyalanarak tüm bir bölge kaybedilse bile yazılabilir ve okunabilir hale gelir.

Bir bölgenin konumları hakkında daha fazla bilgi için Cloud Firestore konumları başlıklı makaleyi inceleyin.

Tek bölge ve çoklu bölge karşılaştırması

Cloud Firestore uygulamasında yazma işleminin yaşam döngüsünü anlama

Cloud Firestore istemcisi tek bir doküman oluşturarak, güncelleyerek veya silerek veri yazabilir. Tek bir dokümana yazma işlemi, depolama katmanında hem dokümanın hem de ilişkili dizin girişlerinin atomik olarak güncellenmesini gerektirir. Cloud Firestore, bir veya daha fazla dokümana birden fazla okuma ve/veya yazma işleminden oluşan atomik işlemleri de destekler.

Cloud Firestore, tüm yazma işlemleri için ilişkisel veritabanlarının ACID özelliklerini (bölünmezlik, tutarlılık, yalıtım ve dayanıklılık) sağlar. Cloud Firestore, tüm işlemlerin seri bir düzende yürütülüyormuş gibi görünmesini sağlayan serileştirilebilirlik özelliği de sunar.

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 onayladığında bu işlem, depolama katmanında dahili olarak veritabanı okuma-yazma işlemi olarak yürütülür. İşlem, Cloud Firestore'nin daha önce bahsedilen ACID özelliklerini sağlamasına olanak tanır.

İşlemin ilk adımı olarak Cloud Firestore, mevcut dokümanı okur ve Belgeler tablosundaki verilerde yapılacak değişiklikleri belirler.

Bu, 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 eklemeleri olmalıdır.
  • Dokümanlardan kaldırılan alanların, Dizinler tablosunda silinmesi gerekir.
  • Dokümanlarda değiştirilen alanlar için Dizinler tablosunda hem silme (eski değerler için) hem de ekleme (yeni değerler için) işlemleri gerekir.

Daha önce bahsedilen mutasyonları hesaplamak için Cloud Firestore, veritabanının dizin oluşturma yapılandırmasını okur. Dizine ekleme yapılandırması, bir veritabanının dizinleri hakkındaki bilgileri depolar. Cloud Firestore, iki tür dizin kullanır: tek alanlı ve bileşik. Cloud Firestore içinde oluşturulan dizinler hakkında ayrıntılı bilgi için Cloud Firestore içindeki dizin türleri başlıklı makaleyi inceleyin.

Değişiklikler hesaplandıktan sonra Cloud Firestore bunları bir işlemde toplar ve ardından işlemi uygular.

Depolama katmanındaki yazma işlemini anlama

Daha önce de 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 diyagramda, Cloud Firestore veritabanının tek bir bölgedeki üç farklı depolama sunucusunda barındırılan sekiz bölümü (1-8 olarak işaretlenmiş) vardır ve her bölüm 3(veya daha fazla) farklı bölgede kopyalanır. Her bölümün bir Paxos lideri vardır. Bu lider, farklı bölümler için farklı bölgelerde olabilir.

<span class=Cloud Firestore veritabanı bölünmesi">

Aşağıdaki gibi Restaurants koleksiyonuna sahip bir Cloud Firestore veritabanını ele alalım:

Restoran koleksiyonu

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.

Koleksiyondaki bir dokümanda değişiklik yapma

Aşağıdaki genel adımlarda, yazma işlemi kapsamında neler olduğu açıklanmaktadı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ümanın dizinlerini okuyun.
  4. Verilerde yapılacak mutasyonları hesaplama Bu durumda beş mutasyon vardır:
    • M1: Belgeler tablosunda 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 tablosunda priceCategory'nin eski değerini içeren satırları silin.
    • M4 ve M5: Azalan ve artan dizinler için Dizinler tablosuna priceCategory'in yeni değerinin satırlarını ekleyin.
  5. Bu mutasyonları uygulayın.

Cloud Firestore hizmetindeki depolama alanı istemcisi, değiştirilecek satırların anahtarlarına sahip olan bölümleri arar. 3. dilimin M1'e, 6. dilimin ise M2-M5'e hizmet verdiği bir durumu ele alalım. Bu parçaların tümünü katılımcı olarak içeren dağıtılmış bir işlem vardır. Katılımcı bölümleri, okuma-yazma işlemi kapsamında verilerin daha önce okunduğu diğer bölümleri de içerebilir.

Aşağıdaki adımlarda, kaydetme işlemi kapsamında neler olduğu açıklanmaktadır:

  1. Depolama alanı istemcisi bir commit işlemi gerçekleştirir. İşleme, M1-M5 mutasyonlarını içerir.
  2. Bu işlemde 3 ve 6 numaralı bölümler katılımcıdır. Katılımcılardan biri koordinatör olarak seçilir (ör. Split 3). Koordinatörün görevi, işlemin tüm katılımcılar arasında atomik olarak uygulanmasını veya iptal edilmesini sağlamaktır.
    • Bu bölümlerin lider replikaları, katılımcılar ve koordinatörler tarafından yapılan işlerden sorumludur.
  3. Her katılımcı ve koordinatör, kendi replikalarıyla bir Paxos algoritması çalıştırır.
    • Lider, replikalarla bir Paxos algoritması çalıştırır. Replikalardan çoğu, lidere ok to commit yanıtı verirse çoğunluk sağlanır.
    • Ardından her katılımcı, hazır olduğunda koordinatörü bilgilendirir (iki aşamalı kaydetmenin ilk aşaması). Katılımcılardan herhangi biri 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 öğrendikten sonra accept işlem sonucunu tüm katılımcılara iletir (iki aşamalı kaydetmenin ikinci aşaması). Bu aşamada her katılımcı, kaydetme kararını kararlı depolama alanına kaydeder ve işlem kaydedilir.
  5. Koordinatör, depolama istemcisine Cloud Firestore içinde işlemin tamamlandığını bildirir. Buna paralel olarak koordinatör ve tüm katılımcılar, verilerde değişiklikleri uygular.

Yaşam döngüsünü kaydetme

Cloud Firestore veritabanı küçük olduğunda, M1-M5 mutasyonlarındaki tüm anahtarlar tek bir bölüme ait olabilir. Bu durumda, işlemde yalnızca bir katılımcı olur ve daha önce bahsedilen iki aşamalı kaydetme işlemi gerekmez. Bu sayede yazma işlemleri daha hızlı gerçekleşir.

Çok bölgeli yazma işlemleri

Çok bölgeli dağıtımda, replikaların bölgelere yayılması kullanılabilirliği artırır ancak performans maliyetine neden olur. Farklı bölgelerdeki replikalar arasındaki iletişim daha uzun gidiş dönüş süreleri gerektirir. Bu nedenle, Cloud Firestore işlemlerinin temel gecikmesi, tek bölgeli dağıtımlara kıyasla biraz daha fazladır.

Replika yapılandırması, bölümlerin liderliği her zaman birincil bölgede kalacak şekilde yapılır. Birincil bölge, trafiğin Cloud Firestore sunucusuna geldiği bölgedir. Yönetimin bu kararı, Cloud Firestore bölgesindeki depolama alanı istemcisi ile replika lideri (veya çoklu bölme işlemleri için koordinatör) arasındaki iletişimde gidiş dönüş gecikmesini azaltır.

Cloud Firestore uygulamasındaki her yazma işlemi, Cloud Firestore uygulamasındaki gerçek zamanlı motorla da etkileşim içerir. Gerçek zamanlı sorgular hakkında daha fazla bilgi için Gerçek zamanlı sorguları geniş ölçekte anlama başlıklı makaleyi inceleyin.

Cloud Firestore uygulamasında okuma sürecini anlama

Bu bölümde, Cloud Firestore uygulamasındaki bağımsız, gerçek zamanlı olmayan okuma işlemleri ele alınmaktadır. Dahili olarak, Cloud Firestore sunucusu bu sorguların çoğunu iki ana aşamada işler:

  1. Dizinler tablosunda tek bir aralık taraması
  2. Önceki taramanın sonucuna göre Belgeler tablosunda nokta aramaları
Cloud Firestore içinde daha az veya daha fazla işlem gerektiren belirli sorgular (ör. IN sorguları) olabilir.

Depolama katmanından veri okuma işlemleri, tutarlı okuma sağlamak için dahili olarak bir veritabanı işlemi kullanılarak yapılır. Ancak yazma işlemleri için kullanılan işlemlerin aksine, bu işlemler kilitlenmez. Bunun yerine, bir zaman damgası seçip tüm okuma işlemlerini bu zaman damgasında yürütürler. Kilit almadıkları için eşzamanlı okuma-yazma işlemlerini engellemezler. Bu işlemi gerçekleştirmek için Cloud Firestore içindeki depolama alanı istemcisi, depolama alanı katmanına okuma zaman damgasını nasıl seçeceğini bildiren bir zaman damgası sınırı belirtir. Cloud Firestore içinde depolama alanı 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'teki depolama katmanında nasıl işlendiği açıklanmaktadır.

Güçlü okumalar

Varsayılan olarak Cloud Firestore okuma işlemleri güçlü tutarlılığa sahiptir. Bu güçlü tutarlılık, Cloud Firestore okuma işleminin, okuma işleminin başlangıcına kadar kaydedilen tüm yazma işlemlerini yansıtan verilerin en yeni sürümünü döndürdüğü anlamına gelir.

Tek Bölünmüş okuma

Cloud Firestore içindeki depolama alanı istemcisi, okunacak satırların anahtarlarına sahip bölümleri arar. Önceki bölümde yer alan 3. parçadan 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 ortaya çıkabilir:

  • Okuma isteği bir lider replikaya (A Bölgesi) gider.
    • Lider her zaman güncel olduğundan okuma işlemi doğrudan devam edebilir.
  • Okuma isteği, lider olmayan bir replikaya (ör. Bölge B) gider.
    • 3. bölüm, dahili durumundan okuma işlemini gerçekleştirmek için yeterli bilgiye sahip olduğunu anlayabilir ve okuma işlemini gerçekleştirir.
    • 3. bölüm, en son verileri görüp görmediğinden emin değil. Lidere bir mesaj göndererek okuma işlemini gerçekleştirmek için uygulaması gereken son işlemin zaman damgasını ister. Bu işlem uygulandıktan sonra okuma işlemi devam edebilir.

Cloud Firestore, ardından yanıtı istemcisine döndürür.

Çoklu bölünmüş okuma

Okuma işlemlerinin birden fazla bölmeden yapılması gerektiğinde aynı mekanizma tüm bölmelerde gerçekleşir. Tüm bölümlerden veriler döndürüldükten sonra Cloud Firestore içindeki depolama alanı istemcisi sonuçları birleştirir. Cloud Firestore, bu verilerle istemcisine yanıt verir.

Eski okumalar

Güçlü okumalar, Cloud Firestore için varsayılan moddur. Ancak liderle iletişim kurulması gerekebileceğinden gecikme süresi daha uzun olabilir. Genellikle Cloud Firestore uygulamanızın verilerin en yeni sürümünü okuması gerekmez ve işlev, birkaç saniye eski olabilecek verilerle iyi çalışır.

Böyle bir durumda istemci, read_time okuma seçeneklerini kullanarak eski okumaları almayı tercih edebilir. Bu durumda okuma işlemleri, verilerin read_time tarihindeki durumuna göre yapılır ve en yakın replikanın, belirtilen read_time tarihindeki verileri doğrulamış olma olasılığı yüksektir. Performansı belirgin şekilde artırmak için 15 saniye makul bir eskime değeridir. Eski okumalarda bile elde edilen satırlar birbiriyle tutarlıdır.

Sıcak noktalardan kaçınma

Cloud Firestore içindeki bölümler, gerektiğinde veya anahtar alanı genişlediğinde trafiği daha fazla depolama sunucusuna dağıtmak için otomatik olarak daha küçük parçalara ayrılır. Fazla trafiği işlemek için oluşturulan bölümler, trafik azalsa bile yaklaşık 24 saat boyunca korunur. Bu nedenle, yinelenen trafik artışları varsa bölümler korunur ve gerektiğinde daha fazla bölüm eklenir. 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.

Depolama alanını ve yükü bölmek zaman alır. Trafiği çok hızlı artırmak, hizmet ayarlanırken yüksek gecikmeye veya son tarihin aşılması hatalarına (genellikle etkin noktalar olarak adlandırılır) neden olabilir. En iyi uygulama, saniyede 500 işlemle bir veritabanındaki koleksiyonda trafiği artırırken işlemleri anahtar aralığına dağıtmaktır. Bu kademeli artıştan sonra 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 ölçeklendirir.

Bölümler, artan yükle birlikte otomatik olarak oluşturulur. Ancak Cloud Firestore, bir anahtar aralığını yalnızca özel bir replika depolama sunucusu grubu kullanarak tek bir dokümana hizmet verene kadar bölebilir. Sonuç olarak, tek bir doküman üzerinde yüksek ve sürekli eşzamanlı işlem hacmi, o dokümanda bir hotspot'a yol açabilir. Tek bir dokümanda sürekli olarak yüksek gecikme süreleriyle karşılaşıyorsanız verileri birden fazla dokümana bölmek veya kopyalamak için veri modelinizi değiştirmeyi düşünebilirsiniz.

Çakışma hataları, birden fazla işlem aynı dokümanı aynı anda okumaya ve/veya yazmaya çalıştığında ortaya çıkar.

Yoğun kullanımın bir diğer özel durumu, Cloud Firestore içinde belge kimliği olarak sıralı şekilde artan/azalan bir anahtar kullanıldığında ve saniye başına işlem sayısı oldukça yüksek olduğunda ortaya çıkar. Trafik artışı yeni oluşturulan bölüme taşınacağından daha fazla bölüm oluşturmak bu durumda işe yaramaz. Cloud Firestore, varsayılan olarak dokümandaki tüm alanları otomatik olarak dizine eklediğinden, zaman damgası gibi sıralı olarak 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ı izleyerek Cloud Firestore'in herhangi bir yapılandırma ayarı yapmanıza gerek kalmadan dilediğiniz kadar büyük iş yüklerine hizmet verecek şekilde ölçeklenebileceğini unutmayın.

Sorun giderme

Cloud Firestore, kullanım kalıplarını analiz etmek ve hotspotting sorunlarını gidermek için tasarlanmış bir teşhis aracı olan Key Visualizer'ı sunar.

Sonraki Adımlar