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

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ümanda ileri düzey Cloud Firestore konuları ele alınmaktadır. Cloud Firestore'ü kullanmaya yeni başladıysanız hızlı başlangıç kılavuzuna göz atın.

Cloud Firestore, Firebase ve Google Cloud'den mobil cihaz, web ve sunucu geliştirme için esnek ve ölçeklenebilir bir veritabanıdır. Cloud Firestore 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ız gerekir. 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ın mimarisini oluşturmadan önce en iyi uygulamalar için aşağıdaki bölümlere bakın.

Üst düzey bileşenleri anlama

Aşağıdaki şemada, bir 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ı gönderebilir. Ancak 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 ve önbellek gibi ek özellikler de sağlayabilirler.

Google Front End (GFE)

Bu, tüm Google Cloud hizmetlerinde ortak olan bir altyapı hizmetidir. GFE, gelen istekleri kabul eder ve ilgili Google hizmetine (bu bağlamda Cloud Firestore hizmeti) iletir. Ayrıca, hizmet reddi saldırılarına karşı koruma da dahil olmak üzere diğer önemli işlevleri de sunar.

Cloud Firestore hizmet

Cloud Firestore hizmeti, API isteğinde kimlik doğrulama, yetkilendirme, kota kontrolleri ve güvenlik kuralları dahil olmak üzere kontroller gerçekleştirir ve işlemleri 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 verileri hem de meta verileri 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'teki en iyi uygulamaları daha iyi anlamanıza yardımcı olabilir.

Anahtar aralıkları ve bölme işlemleri

Cloud Firestore, NoSQL, belge tabanlı 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. Dokümanlar mantıksal olarak depolanır ve bu tek anahtara göre alfabetik olarak sıralanır. Anahtar aralığı terimini, alfabetik olarak birbirine bitişik bir 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. 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 işlemek için verileri birden fazla makinede veya depolama sunucusunda depolanabilen ve sunulabilen ayrı parçalara böler. Bu bölümler, veritabanı tablolarında bölme adı verilen anahtar aralığı bloklarında oluşturulur.

Eşzamanlı Çoğaltma

Veritabanının her zaman otomatik ve senkronize olarak kopyalandığını unutmayın. Verilerin bölünmüş parçalarının, bir bölgeye erişilemediğinde bile kullanılabilir durumda kalması için farklı bölgelerde kopyaları vardır. Bölünmüşlüğün farklı kopyalarına tutarlı şekilde çoğaltma işlemi, 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ı tarzı iki tabloda şu şekilde düzenler:

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

Aşağıdaki şemada, Cloud Firestore veritabanı tablolarının bölmelerle nasıl görünebileceği gösterilmektedir. Bölümler üç farklı bölgede çoğaltılır ve her bölüme atanan bir Paxos lideri vardır.

Veri düzeni

Tek bölgeli ve çok bölgeli

Veritabanı oluştururken bölge veya çok bölgeli 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ölmelerinin seçilen bölgedeki farklı bölgelerde kopyaları vardır.

Çoklu bölgeli konum, veritabanının kopyalarının depolandığı tanımlanmış 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 kopyaları bulunur. Üçüncü bölgede, tam veri kümesini korumayan ancak kopyalama işlemine katılan bir şahit kopya bulunur. Veriler birden çok bölge arasında çoğaltıldığında, bir bölgenin tamamı kaybolsa bile veriler yazılabilir ve okunabilir.

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

Tek bölgeli ve çok bölgeli

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 dokümanın hem de ilişkili dizin girişlerinin depolama katmanında atomik olarak güncellenmesini gerektirir. Cloud Firestore, bir veya daha fazla dokümana birden fazla okuma ve/veya yazma içeren atomik işlemleri de destekler.

Cloud Firestore, tüm yazma işlemleri 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 serileştirilebilirlik sağlar. Bu, tüm işlemlerin bir seri siparişteymiş gibi göründüğü anlamına gelir.

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

Cloud Firestore, bir işlemin ilk adımı olarak mevcut belgeyi okur ve Documents tablosundaki verilerde yapılacak mutasyonları belirler.

Bu süreç, Dizinler tablosunda aşağıdaki gibi gerekli güncellemelerin yapılmasını da içerir:

  • Belgelere eklenen alanlar için Dizinler tablosuna karşılık gelen eklemeler yapılmalıdır.
  • Dokümanlardan kaldırılan alanların, Dizinler tablosunda da silinmesi gerekir.
  • Belgelerde değiştirilen alanlar için Dizinler tablosunda hem silme (eski değerler için) hem de ekleme (yeni değerler için) işlemi gerekir.

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 alan ve birleşik. Cloud Firestore'te oluşturulan dizinleri ayrıntılı olarak incelemek için Cloud Firestore'teki 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ındaki yazma işlemlerini anlama

Daha önce de belirtildiği gibi, Cloud Firestore'te 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 bölgedeki üç farklı depolama sunucusunda barındırılan sekiz bölme (1-8 olarak işaretlenmiştir) içerir ve her bölme 3(veya daha fazla) farklı bölgede çoğaltılır. Her bölme, farklı bölmelerde farklı bir bölgede bulunabilecek bir Paxos lideri içerir.

<span class=Cloud Firestore veritabanı bölme">

Aşağıdaki gibi Restaurants koleksiyonuna sahip bir Cloud Firestore veritabanı düşünün:

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ümana geçme

Aşağıdaki genel adımlarda, yazma işleminin bir parçası olarak neler olduğu açıklanmaktadır:

  1. Okuma/yazma işlemi oluşturun.
  2. Depolama katmanındaki Dokümanlar tablosundan Restaurants koleksiyonundaki restaurant1 dokümanı okuyun.
  3. Dizinler tablosundan dokümana ait dizinleri okuyun.
  4. Verilerde yapılacak mutasyonları hesaplayın. Bu durumda beş mutasyon vardır:
    • M1: Documents 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 priceCategory değerinin eski satırlarını silin.
    • M4 ve M5: Azalan ve artan dizinler için priceCategory değerinin yeni değerine ait satırları Dizinler tablosuna ekleyin.
  5. Bu mutasyonları gönderin.

Cloud Firestore hizmetindeki depolama alanı istemcisi, değiştirilecek satırların anahtarlarına sahip olan bölmelerin olup olmadığını kontrol eder. 3. Bölüm'ün M1'i, 6. Bölüm'ün ise M2-M5'i yayınladığı bir durumu ele alalım. Tüm bu bölmelerin katılımcı olarak yer aldığı dağıtılmış bir işlem vardır. Katılımcı bölmelerine, okuma/yazma işleminin bir parçası olarak daha önce verilerin okunduğu diğer tüm bölmeler de dahil edilebilir.

Aşağıdaki adımlarda, kaydetme işleminin bir parçası olarak nelerin gerçekleştiği açıklanmaktadır:

  1. Depolama alanı istemcisi bir taahhüt gönderir. Taahhüt, M1-M5 mutasyonlarını içerir.
  2. 3. ve 6. bölümler bu işlemin katılımcılarıdır. Katılımcılardan biri koordinatör olarak seçilir (ör. 3. Bölüm). Koordinatörün görevi, işlemin tüm katılımcılarda atomik olarak kaydetmesini veya iptal edilmesini sağlamaktır.
    • Bu bölmelerin lider kopyaları, katılımcılar ve koordinatörler tarafından yapılan çalışmalardan sorumludur.
  3. Her katılımcı ve koordinatör, ilgili kopyalarıyla bir Paxos algoritması çalıştırır.
    • Lider, kopyalarla bir Paxos algoritması çalıştırır. Çoğaltmaların çoğu lidere ok to commit yanıtı ile yanıt verirse yeterli katılım sağlanır.
    • Ardından her katılımcı, hazır olduğunda (iki aşamalı taahhüt işleminin ilk aşaması) koordinatörü bilgilendirir. Herhangi bir katılımcı işlemi taahhüt edemiyorsa işlemin tamamı aborts.
  4. Koordinatör, kendisi de dahil olmak üzere tüm katılımcıların hazır olduğunu anladığında accept işlem sonucunu tüm katılımcılara bildirir (iki aşamalı taahhüt işleminin 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, Cloud Firestore'teki depolama alanı istemciye işlemin sabitlendiğini yanıtlar. Koordinatör ve tüm katılımcılar, buna paralel olarak mutasyonları verilere uygular.

Kaydetme yaşam döngüsü

Cloud Firestore veritabanı küçük olduğunda, M1-M5 mutasyonlarındaki tüm anahtarlar tek bir bölme tarafından sahiplenilebilir. 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 yazma işlemleri

Çok bölgeli dağıtımlarda, kopyaların bölgelere dağıtılması kullanılabilirliği artırır ancak performans maliyeti getirir. Farklı bölgelerdeki kopyalar arasında iletişim kurmak daha uzun sürer. Bu nedenle, Cloud Firestore işlemleri için referans gecikme, tek bölgeli dağıtımlara kıyasla biraz daha fazladır.

Yedek kopyaları, grupların liderliğinin her zaman birincil bölgede kalacağı şekilde yapılandırırız. Birincil bölge, Cloud Firestore sunucusuna trafiğin geldiği bölgedir. Bu liderlik kararı, Cloud Firestore'teki depolama alanı istemcisi ile kopya lideri (veya çoklu bölme işlemleri için koordinatör) arasındaki iletişimde gidiş-dönüş gecikmesini azaltır.

Cloud Firestore'teki her yazma işlemi, Cloud Firestore'teki gerçek zamanlı motorla da etkileşim 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'te bir okumanın ömrünü anlama

Bu bölümde, Cloud Firestore'teki bağımsız, gerçek zamanlı olmayan okumalar ayrıntılı olarak ele alınmaktadır. Cloud Firestore sunucusu, bu sorguların çoğunu dahili olarak iki ana aşamada işler:

  1. Dizinler tablosu üzerinde tek bir aralık taraması
  2. Dokümanlar tablosunda, önceki taramanın sonucuna göre aramalara işaret et
Cloud Firestore'te daha az veya daha fazla işlem gerektiren belirli sorgular (ör. IN sorguları) olabilir.

Depolama katmanından okunan veriler, tutarlı okumalar sağlamak için dahili olarak bir veritabanı işlemi kullanılarak okunur. Ancak yazma işlemleri için kullanılan işlemlerin aksine bu işlemler kilit almaz. Bunun yerine, bir zaman damgası seçip 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'teki depolama istemcisi, depolama katmanına okuma zaman damgasının nasıl seçileceğini belirten bir zaman damgası sınırı belirtir. Cloud Firestore içinde depolama alanı istemcisi tarafından seçilen zaman damgası sınırı türü, Read isteği için okuma seçeneklerine göre belirlenir.

Depolama katmanındaki okuma işlemlerini 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 son derece tutarlıdır. Bu güçlü tutarlılık, Cloud Firestore okuma işleminin, okuma işleminin 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ölme okuma

Cloud Firestore ürünündeki depolama alanı istemcisi, okunacak satırların anahtarlarına sahip olan bölümleri arar. Önceki bölümde 3. bölümden 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 kopyaya bağlı olarak aşağıdaki durumlar ortaya çıkabilir:

  • Okuma isteği, lider bir kopyaya (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 kopyaya (ör. B bölgesi) gider
    • 3. bölme, dahili durumundan okumayı sunmak için yeterli bilgiye sahip olduğunu bilir ve bölme bunu yapar.
    • 3. bölme, en son verileri görüp görmediğinden emin değildir. Lidere, okumayı yayınlamak için uygulaması gereken son işlemin zaman damgasını sorması için 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ölme üzerinden yapılması gerektiğinde tüm bölmelerde aynı mekanizma geçerli olur. Tüm bölmelerden veriler döndürüldükten sonra Cloud Firestore'teki depolama alanı istemcisi sonuçları birleştirir. Cloud Firestore, müşterisine bu verilerle yanıt verir.

Eski okumalar

Cloud Firestore'te varsayılan mod güçlü okumalardır. Ancak bu yöntem, liderle iletişim kurulması gerekebileceğinden gecikmeye yol açabilir. Cloud Firestore uygulamanızın genellikle verilerin en son 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, veriler read_time'te olduğu için okumalar yapılır ve en yakın kopyanın, belirtilen read_time'te veri olduğunu zaten doğrulamış olma olasılığı yüksektir. Belirgin şekilde daha iyi performans için 15 saniye makul bir eskilik değeridir. Eski okumalar için bile döndürülen satırlar birbiriyle tutarlıdır.

Yoğun bölgelerden kaçınma

Cloud Firestore içindeki bölümler, gerektiğinde veya anahtar alanı genişlediğinde trafiği daha fazla depolama sunucusuna yayınlama işini dağıtmak için otomatik olarak daha küçük parçalara bölünür. Fazla trafiği işlemek için oluşturulan bölmeler, trafik ortadan kalksa bile yaklaşık 24 saat boyunca saklanır. Bu nedenle, tekrarlanan trafik artışları varsa bölünmeler korunur ve gerektiğinde daha fazla bölünme eklenir. Bu mekanizmalar, artan trafik yükü veya veritabanı boyutu altında Cloud Firestore veritabanlarının otomatik olarak ölçeklendirilmesine yardımcı olur. Ancak aşağıda açıklandığı gibi dikkate almanız gereken bazı sınırlamalar vardır.

Depolama alanını ve yükü bölme işlemi zaman alır. Trafik çok hızlı arttığında, hizmet ayarlanırken genellikle sıcak noktalar olarak adlandırılan yüksek gecikmeye veya son tarihin aşılmasına neden olabilir. En iyi uygulama, işlemleri anahtar aralığına dağıtırken saniyede 500 işlem içeren bir veritabanında koleksiyon trafiğini artırmaktır. Bu kademeli artıştan sonra trafiği 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 uygun şekilde ölçeklendirecek şekilde konumlandırır.

Yük arttıkça otomatik olarak bölme oluşturulsa da Cloud Firestore, yalnızca özel bir kopyalanmış depolama sunucusu grubu kullanarak tek bir doküman yayınlayana kadar bir anahtar aralığını bölebilir. Sonuç olarak, tek bir belgede yüksek ve sürekli eşzamanlı işlem hacimleri, söz konusu belgede sıcak nokta oluşmasına neden olabilir. 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ı meydana gelir.

Cloud Firestore içinde belge kimliği olarak sırayla artan/azalan bir anahtar kullanıldığında ve saniye başına işlem sayısı oldukça yüksek olduğunda da yoğun nokta oluşur. Trafiğin artması yalnızca yeni oluşturulan bölüme taşındığı için daha fazla bölüm oluşturmanın burada bir faydası yoktur. Cloud Firestore varsayılan olarak dokümandaki tüm alanları otomatik olarak dizine eklediğinden, zaman damgası gibi sırayla artan/azalan bir değer içeren bir doküman alanı için dizin alanında da bu tür hareketli sıcak noktalar oluşturulabilir.

yararlanabilirsiniz.

Yukarıda belirtilen uygulamaları uygulayarak Cloud Firestore'ün, herhangi bir yapılandırma ayarlamanız gerekmeden keyfi olarak büyük iş yükleri sunacak şekilde ölçeklendirilebileceğini unutmayın.

Sorun giderme

Cloud Firestore, kullanım kalıplarını analiz etmek ve hotspot sorunlarını gidermek için tasarlanmış bir teşhis aracı olarak Anahtar Görselleştirici'yi sağlar.

Sonraki Adımlar