Uygulamalarınızı yüksek performans ve güvenilirlik için tasarlama konusunda bilinçli kararlar almak istiyorsanız bu dokümanı 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 ve 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.
Cloud Firestore SDK 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, önbellekler vb. 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 sağlar.
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. Verilerdeki iş yükünün tek bir makinenin kaldıramayacağı kadar ağır olduğu durumlar 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 farklı bölgelerde kopyaları bulunur. Bu sayede, bir bölgeye erişilemediğinde bile veriler kullanılabilir durumda kalı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ölme için Paxos lideri olarak görev yapacak bir kopya seçilir. Bu kopya, ilgili bölmeye yapılan yazma işlemlerinden sorumludur. Senkronize çoğaltma, Cloud Firestore'teki verilerin her zaman en son sürümünü okumanızı sağlar.
Bunun genel sonucu, hem okuma hem de yazma işlemleri için ağır iş yüklerinden bağımsız olarak çok büyük ölçekte düşük gecikmeler sağlayan ölçeklenebilir ve yüksek kullanılabilirlikli bir sistemdir.
Veri düzeni
Cloud Firestore, şema kullanmayan bir belge veritabanıdır. Ancak verileri depolama katmanında öncelikle aşağıdaki gibi iki ilişkisel veritabanı tarzı tabloda 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.
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.
Cloud Firestore'te bir yazma işleminin ömrünü anlama
Cloud Firestore istemcileri 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 seri bir sırada yürütülmüş 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.
Ayrıca, Dizinler tablosunda aşağıdaki gibi gerekli güncellemeleri yapmanız gerekir:
- 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şlem içinde toplar ve ardından işlemi tesciller.
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.
Cloud Firestore veritabanı bölme">
Aşağıdaki gibi 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 ister.
Aşağıdaki genel adımlarda, yazma işleminin bir parçası olarak neler olduğu açıklanmaktadır:
- Okuma/yazma işlemi oluşturun.
- Depolama katmanındaki Dokümanlar tablosundan
Restaurantskoleksiyonundakirestaurant1dokümanı okuyun. - Dizinler tablosundan dokümanın dizinlerini okuyun.
- Verilerde yapılacak mutasyonları hesaplayın. Bu durumda beş mutasyon vardır:
- M1: Documents tablosundaki
restaurant1satırını,priceCategoryalanının değerindeki değişikliği yansıtacak şekilde güncelleyin. - M2 ve M3: Azalan ve artan dizinler için Dizinler tablosundaki
priceCategoryeski değerinin satırlarını silin. - M4 ve M5: Azalan ve artan dizinler için
priceCategorydeğerinin yeni satırlarını Dizinler tablosuna ekleyin.
- M1: Documents tablosundaki
- 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:
- Depolama alanı istemcisi bir taahhüt gönderir. Taahhüt, M1-M5 mutasyonlarını içerir.
- 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.
- 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 commityanı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 tüm işlem
aborts.
- Lider, kopyalarla bir Paxos algoritması çalıştırır. Çoğaltmaların çoğu lidere
- Koordinatör, kendisi de dahil olmak üzere tüm katılımcıların hazır olduğunu anladığında
acceptiş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. - 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.
Cloud Firestore veritabanı küçük olduğunda, M1-M5 mutasyonlarındaki tüm anahtarlar tek bir bölme tarafından sahiplenilebilir. Bu durumda, işlemde yalnızca bir katılımcı vardır ve daha önce bahsedilen iki aşamalı taahhüt gerekli değildir. Bu nedenle, yazma işlemleri daha hızlı olur.
Ç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şlemlerinin temel gecikmesi, 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 gelen 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 Gerçek zamanlı sorguları ölçekte 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:
- Dizinler tablosu üzerinde tek bir aralık taraması
- Önceki taramanın sonucuna göre Dokümanlar tablosunda nokta aramaları
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 okumaları güçlü ve 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 içindeki depolama alanı istemcisi, okunacak satırların anahtarlarına sahip olan bölmelerin adını 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 kopyaya 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ğundan okuma işlemi doğrudan devam edebilir.
- 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. Bu işlem uygulandıktan sonra okuma işlemine devam edilebilir.
Cloud Firestore, yanıtı istemciye döndürür.
Çoklu bölme 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, bu verileri kullanarak müşterisine 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.
Bu gibi durumlarda istemci, read_time okuma seçeneklerini kullanarak eski okumalar almayı tercih edebilir. Bu durumda, veriler read_time'te olduğu için okuma işlemleri 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çının
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. Ayrıca, 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 veritabanında saniyede 500 işlemle bir koleksiyondaki trafiği 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 gecikmeler yaşıyorsanız verileri birden fazla dokümana bölmek veya kopyalamak için veri modelinizi değiştirmeyi düşünebilirsiniz.
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. Trafik artışı yalnızca yeni oluşturulan bölmelere taşınacağından daha fazla bölme 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ı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
- Diğer en iyi uygulamalar hakkında bilgi edinin.
- Geniş ölçekte gerçek zamanlı sorgular hakkında bilgi edinin.