Bir haber sitesi ya da uygulama tek bir ülkeden küresel bir kitleye açıldığında, veritabanının iki şeyi aynı anda başarması gerekir: her koşulda güçlü tutarlılık sunmak ve trafik büyüdükçe kesintisiz ölçeklenmek. Geleneksel ilişkisel sistemlerde bu iki hedef çoğu zaman birbiriyle çelişir. İşte tam bu noktada Google'ın yönetilen dağıtık veritabanı Google Cloud Spanner devreye girer.

İlgili içerikler: Veritabanı türleri rehberi · PostgreSQL Nedir? · OceanBase Nedir? · Bulut Veritabanı Servisleri

Google Cloud Spanner Nedir?

Cloud Spanner, Google Cloud tarafından sunulan, tam olarak yönetilen (fully managed) ve yatay ölçeklenebilen dağıtık bir ilişkisel veritabanı hizmetidir. Klasik ilişkisel veritabanlarının SQL, şema ve ACID işlem desteğini, dağıtık sistemlerin dünya çapında ölçeklenme yeteneğiyle birleştirmeyi hedefler. Bu sınıf ürünler genellikle "NewSQL" ya da "dağıtık SQL" başlığı altında anılır.

Spanner, Google'ın kendi içinde yıllarca kullandığı dağıtık veritabanı teknolojisinin bulut üzerinden sunulan biçimidir. Tek bir bölgeye (region) sığmayan, birden fazla coğrafyaya yayılan uygulamalarda bile güçlü tutarlılık (strong consistency) hedeflemesiyle öne çıkar. Yönetilen bir hizmet olduğu için yama, çoğaltma, yük dengeleme ve donanım arızalarının yönetimi gibi işletme yükünü büyük ölçüde Google üstlenir.

Kısa Bir Geçmiş: Spanner'ın Kökeni

Spanner, Google'ın kendi altyapısındaki ölçeklenme sorunlarını çözmek için geliştirdiği dahili bir sistem olarak ortaya çıktı. Google, bu sistemi anlatan akademik bir makale yayımladı ve Spanner, "küresel ölçekte dağıtık, tutarlı bir veritabanı" fikrinin sektördeki en çok atıf alan örneklerinden biri oldu.

İlerleyen yıllarda Google, bu teknolojiyi Google Cloud müşterilerinin de kullanabileceği yönetilen bir hizmet hâline getirdi. Zamanla PostgreSQL uyumlu bir arayüz gibi eklerle geliştirildi ve daha geniş bir geliştirici kitlesine hitap eder duruma geldi. Spanner ayrıca, sektörde sonradan ortaya çıkan pek çok dağıtık SQL projesine ilham veren mimari yaklaşımların da temelini oluşturdu.

Temel Kavramlar ve Mimari

Spanner'ı anlamak için birkaç temel kavramı bilmek gerekir. Bu kavramlar, sistemin neden hem ölçeklenebilir hem de tutarlı olabildiğini açıklar:

  • Instance (örnek): Hesaplama ve depolama kaynaklarını barındıran üst düzey birim. Bir örnek içinde birden çok veritabanı bulunabilir.
  • Node / İşlem Birimi (Processing Units): Örneğin işlem kapasitesini belirleyen kaynak birimleri. Kapasiteyi düğüm sayısıyla veya daha ince taneli işlem birimleriyle ayarlarsınız.
  • Split (parça): Spanner, tabloları birincil anahtar aralıklarına göre otomatik olarak parçalara böler ve bu parçaları düğümler arasında dağıtır. Yük arttıkça parçalar bölünür.
  • Replica (kopya): Veri, dayanıklılık ve yüksek erişilebilirlik için birden çok kopya hâlinde tutulur; kopyalar farklı bölgelerde konumlanabilir.
  • Konfigürasyon: Bölgesel (regional) veya çok bölgeli (multi-region) yapılandırmalar, verinin nerede tutulacağını ve nasıl çoğaltılacağını belirler.

Spanner, kopyalar arasında tutarlılığı sağlamak için Paxos tabanlı bir dağıtık uzlaşı (consensus) protokolü kullanır. Her parça (split) için bir kopya grubu Paxos ile yazımları senkron çoğaltır. Bu yaklaşım, bir kopya erişilemez olsa bile çoğunluk (quorum) sağlandığı sürece sistemin çalışmaya devam edebilmesini sağlar.

TrueTime ve Küresel Tutarlılık

Spanner'ın en ayırt edici yönlerinden biri TrueTime adı verilen zaman yaklaşımıdır. Dağıtık sistemlerde farklı sunucuların saatleri birbirinden hafifçe kayabilir; bu da işlemlerin küresel sırasını belirlemeyi zorlaştırır.

Google veri merkezlerinde GPS alıcıları ve atom saatleri kullanılır. TrueTime, zamanı kesin bir an olarak değil, bir belirsizlik aralığı olarak ifade eder: "şu an, şu iki değer arasında". Spanner bu bilgiyi kullanarak işlemlere tutarlı zaman damgaları atar ve bir işlemin taahhüdünü, belirsizlik aralığının geçmesini bekleyerek (commit-wait) küresel sıralamayı güvenceye alır.

Güçlü Tutarlılık ve ACID İşlemleri

Birçok dağıtık NoSQL sistemi, ölçeklenme uğruna sonunda tutarlılık (eventual consistency) modelini benimser. Spanner ise farklı bir yol izler: tek satırlık işlemlerde değil, birden çok satır ve tabloyu kapsayan işlemlerde bile ACID garantileri sunmayı hedefler.

  • Atomiklik: Bir işlemdeki tüm değişiklikler ya tümüyle uygulanır ya da hiçbiri uygulanmaz.
  • Tutarlılık: İşlemler veritabanını geçerli bir durumdan başka bir geçerli duruma taşır.
  • Yalıtım: Eşzamanlı işlemler, tutarlılığı bozmayacak şekilde birbirinden yalıtılır.
  • Dayanıklılık: Taahhüt edilen bir işlem, arıza durumunda dahi kaybolmaz.

CAP teoremi çerçevesinde Spanner tutarlılık ve bölünme toleransını önceler; pratikte ise Google'ın ağ altyapısı sayesinde yüksek erişilebilirlik hedeflenir. Salt okunur sorgular için ise zaman damgasına dayalı, kilit gerektirmeyen okuma seçenekleri sunulur; bu da okuma yükünün ölçeklenmesine yardımcı olur.

Veri Modeli ve SQL Lehçeleri

Spanner ilişkisel bir veri modeli kullanır: tablolar, sütunlar, birincil anahtarlar, ikincil indeksler ve yabancı anahtar benzeri ilişkiler. Sorgular SQL ile yazılır. Spanner iki SQL arayüzü sunar: Google'ın kendi lehçesi (GoogleSQL) ve PostgreSQL uyumlu bir arayüz. PostgreSQL arayüzü, mevcut PostgreSQL bilgisine ve araç ekosistemine yakın durmak isteyen ekipler için tanıdık bir yüzey sağlar.

sql
-- Basit bir tablo tanımı (GoogleSQL)
CREATE TABLE Musteriler (
  MusteriId   STRING(36) NOT NULL,
  Ad          STRING(200),
  Eposta      STRING(320),
  OlusturmaTs TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp=true),
) PRIMARY KEY (MusteriId);

-- Sorgu
SELECT Ad, Eposta
FROM Musteriler
WHERE MusteriId = @id;

Spanner, şema değişikliklerini (DDL) hizmet çalışırken ve genellikle kesintiye yol açmadan uygulayabilir. Bu, sürekli çalışması gereken üretim sistemlerinde önemli bir kolaylıktır.

İç İçe Tablolar ve Birincil Anahtar Tasarımı

Spanner, ilişkili verileri fiziksel olarak yan yana tutmak için iç içe (interleaved) tablolar özelliği sunar. Bir alt tabloyu üst tablosuyla iç içe tanımladığınızda, ilişkili satırlar aynı parçada birlikte saklanır. Bu, üst-alt kayıtları tek seferde okuyan sorguların performansını iyileştirir.

sql
-- Siparisler tablosu, Musteriler icine ic ice yerlestirilir
CREATE TABLE Siparisler (
  MusteriId  STRING(36) NOT NULL,
  SiparisId  STRING(36) NOT NULL,
  Tutar      NUMERIC,
  Durum      STRING(20),
) PRIMARY KEY (MusteriId, SiparisId),
  INTERLEAVE IN PARENT Musteriler ON DELETE CASCADE;

Birincil anahtar seçimi Spanner'da performansı doğrudan etkiler. Sürekli artan (monoton) anahtarlar; örneğin sıralı sayaçlar veya işlenmemiş zaman damgaları, tüm yazımların aynı parçaya gitmesine ve bir "sıcak nokta" (hotspot) oluşmasına yol açabilir.

Ölçeklenme: Node ve İşlem Birimleri

Spanner'ın vaadi, veritabanını elle parçalamaya (manuel sharding) gerek kalmadan yatay ölçeklenmedir. Kapasiteyi artırmak için genellikle örneğe düğüm veya işlem birimi eklemek yeterlidir; veri dağıtımını sistem kendisi yönetir. Kapasite iki birimle ifade edilir:

BirimAçıklama
İşlem Birimi (PU)Kapasitenin en küçük ölçeklendirme birimi; küçük iş yükleri için ince taneli ayar sağlar.
Node (düğüm)Bir node, 1000 işlem birimine karşılık gelir. Büyük iş yükleri düğüm sayısıyla ölçeklenir.
SplitAnahtar aralığına göre otomatik oluşan veri parçası; yük arttıkça bölünüp yeniden dağıtılır.
Auto-scalingYük değişimlerine göre kapasiteyi otomatik ayarlamaya yönelik seçenekler bulunur.

Yüksek Erişilebilirlik ve Yapılandırmalar

Erişilebilirlik açısından iki temel yapılandırma vardır. Bölgesel (regional) yapılandırmada veri tek bir bölge içindeki birden çok bölgecikte (zone) çoğaltılır. Çok bölgeli (multi-region) yapılandırmada ise veri birden fazla coğrafi bölgeye yayılır; bu, bir bölge tümüyle sorun yaşasa bile hizmetin sürmesine yardımcı olur ve okumaları kullanıcılara coğrafi olarak yakınlaştırabilir.

Google, Spanner için hizmet seviyesi taahhütlerini (SLA) resmi dokümantasyonunda yayımlar; çok bölgeli yapılandırmalar için daha yüksek erişilebilirlik hedefleri belirtilir. Yapılandırma seçimi maliyeti, gecikmeyi ve dayanıklılığı doğrudan etkilediğinden iş gereksinimlerine göre kararlaştırılmalıdır.

Yedekleme, Geri Yükleme ve Change Streams

Spanner, yönetilen yedekleme ve geri yükleme yetenekleri sunar. Ayrıca belirli bir zamana geri dönmeye yardımcı olan noktasal geri yükleme (point-in-time recovery) gibi mekanizmalar için veri sürüm geçmişini belirli bir pencere boyunca saklama seçenekleri bulunur.

Change streams (değişiklik akışları) özelliği, tablolardaki ekleme, güncelleme ve silmeleri gerçek zamanlıya yakın biçimde izleyip başka sistemlere aktarmayı sağlar. Bu, analitik ambarlara veri taşımak, arama indekslerini güncel tutmak veya olay tabanlı mimariler kurmak için kullanışlıdır.

Kullanım Alanları

Spanner, güçlü tutarlılık ile büyük ölçekli yatay ölçeklenmenin aynı anda gerektiği senaryolarda öne çıkar:

  • Finansal hizmetler: Ödeme, cüzdan ve hesap defteri (ledger) gibi kesin tutarlılık gerektiren sistemler.
  • Perakende ve envanter: Bölgeler arası stok ve sipariş yönetimi; aşırı satışın önlenmesi.
  • Oyun: Küresel oyuncu profilleri, skor tabloları ve durum verisi.
  • Küresel uygulamalar: Kullanıcıları birden çok kıtaya yayılan, tek bir tutarlı veri katmanı isteyen servisler.
  • Kurumsal sistemler: Yüksek erişilebilirlik ve büyümeye hazır ilişkisel altyapı arayan platformlar.

Spanner ile Geleneksel Veritabanlarının Karşılaştırması

Aşağıdaki tablo, Spanner'ı klasik tek düğümlü ilişkisel veritabanları ve tipik dağıtık NoSQL sistemleriyle kabaca karşılaştırır. Ayrıntılar ürüne ve yapılandırmaya göre değişir.

ÖzellikCloud SpannerKlasik RDBMSTipik NoSQL
Veri modeliİlişkisel (SQL)İlişkisel (SQL)Anahtar-değer / doküman vb.
Yatay ölçeklenmeYerleşik, otomatikSınırlı / manuelGenellikle güçlü
İşlemlerDağıtık ACIDACID (tek düğüm)Sıklıkla sınırlı
TutarlılıkGüçlü / hariciGüçlüÇoğunlukla eventual
İşletmeTam yönetilenGenelde kendi kendineDeğişken

Karşılaştırmalı bir bakış için OceanBase gibi diğer dağıtık SQL sistemlerine ve genel olarak bulut veritabanı servislerine göz atabilirsiniz.

Avantajlar ve Dikkat Edilmesi Gerekenler

Spanner güçlü bir çözümdür, ancak her iş yükü için doğru araç değildir. Karar verirken şu dengeleri göz önünde bulundurun:

  • Artı: Elle parçalama olmadan yatay ölçeklenme ve güçlü tutarlılığı bir arada sunar.
  • Artı: Tam yönetilen yapısı işletme yükünü azaltır; yama ve çoğaltma Google tarafında yönetilir.
  • Artı: SQL ve tanıdık ilişkisel model sayesinde öğrenme eğrisi görece yumuşaktır.
  • Dikkat: Maliyet, küçük veya seyrek iş yüklerinde tek düğümlü bir veritabanına göre yüksek olabilir.
  • Dikkat: Google Cloud'a bağımlılık (vendor lock-in) ve birincil anahtar tasarımının performansa etkisi göz önünde bulundurulmalıdır.

KEYDAL ve Global Veritabanı Altyapısı

Bir haber sitesi büyüdükçe veri katmanı; tutarlılık, ölçeklenme ve erişilebilirlik üçgeninde giderek kritikleşir. Doğru veritabanı seçimi kadar, onu barındıran altyapının performansı ve işletilebilirliği de sonucu belirler. KEYDAL, haber siteleri için yayın yazılımı, barındırma ve sunucu altyapısını bir arada sunarak yayıncıların içerikle ilgilenmesini, altyapı yükünü ise ekibine bırakmasını amaçlar.