Azure SQL Hyperscale Gerçekten Distributed SQL mi?

Bulutta ölçeklenen ilişkisel veritabanı arayanlar için “distributed SQL” neredeyse bir kategori adı oldu. Azure SQL Database Hyperscale bu tanımın içine giriyor mu? Anna Hoffman’ın Azure SQL Dev Corner’daki yazısı soruyu etiket tartışmasından çıkarıp mimari düzeyde yanıtlıyor. Hyperscale dağıtık bir mimariye sahip, üzerinde ise tek yazıcılı (single-writer) bir SQL motoru çalışıyor. Veritabanı seçerken hangi gereksinimi nasıl tartacağınızı belirleyen de bu ayrım.

“Dağıtık” denince genelde ne kastediliyor?

Yazıya göre mimarlar distributed SQL derken aslında bir özellik demetini birlikte istiyor:

• Gerçek işlemler (transaction), “eventually” değil.
• Bir şeyler bozulduğunda bile üzerine akıl yürütülebilen tutarlılık.
• Tam SQL desteği, alt kümesi değil.
• Kurumsal düzeyde operasyon: yüksek erişilebilirlik, yedekleme ve geri yükleme, güvenlik, uyumluluk.
• 10 TB’a gelindiğinde yeniden mimari kurmayı gerektirmeyen ölçek.
• Bazı iş yükleri için birden fazla yazma düğümü.

Tanımların ayrıştığı yer sonuncusu, yani birden fazla yazıcı. Hyperscale’in nerede durduğunu anlamak için de önce neyi dağıttığına bakmak gerekiyor.

Hyperscale neyi dağıtıyor?

Hyperscale, tek bir SQL Server makinesinin üstlendiği dört işi ayrı katmanlara bölüyor. Compute replica’ları sorgu işlemcisini çalıştırıyor, log servisi kalıcılığı (durability) üstlenip log akışını dağıtıyor, page server’ların her biri verinin bir dilimine sahip oluyor, Azure Storage da uzun vadeli kopyayı tutup yedekleri snapshot olarak alıyor. Bu ayrıştırmanın kökeni, aynı yazarın daha önce ele aldığı Socrates araştırma makalesine dayanıyor.

Eskiden veri büyüklüğüyle birlikte ölçeklenen maliyetler böylece o bağdan kurtuluyor:

• Depolama otomatik olarak büyüyor; üst sınır 128 TB.
• Yedekler compute’a dokunmayan, neredeyse anlık snapshot’lar; geri yükleme süresi büyük ölçüde veritabanı boyutundan bağımsız.
• Yeni bir replica eklemek veri kopyalamayı gerektirmiyor ve replica hiçbir zaman bayat (stale) sayfa okumuyor. Dört adede kadar yüksek erişilebilirlik replica’sı, bunun yanında her biri kendi compute boyutuna sahip 30’a kadar named replica kullanılabiliyor; raporlama, analitik veya AI iş yüklerini izole etmek için uygun.
• Log 150 MB/s’e kadar çalışıyor, compute ise Premium-series donanımda 192 vCore’a kadar çıkıyor.

Yazma tarafı bilinçli olarak tek noktada

Hyperscale’de yazmaları kabul eden tek bir primary var ve yazı bunu bir tasarım kararı olarak anlatıyor, eksiklik olarak değil.

Tek yazıcı demek, yazma yolunda dağıtık commit protokolü yok, uygulamanızı etrafında kurgulamanız gereken bir çakışma çözümü (conflict resolution) yok, iki bölgenin aynı satırı güncellemeye çalışmasından doğan sürprizler yok demek. Karşılığında SQL Server motorunun işlem semantiğini ve uygulamanızın halihazırda kullandığı T-SQL yüzeyini alıyorsunuz: temporal tablolar, JSON, graph, vektörler, columnstore, saklı yordamlar ve diğerleri. Mevcut uygulamalarınız ve araçlarınız yeniden yazılmadan çalışmaya devam ediyor.

Yazarın formülasyonu şöyle: Hyperscale, üstünde tek yazıcılı bir SQL motoru bulunan dağıtık bir mimaridir. Etiketten çok bu ayrım işe yarıyor. Distributed SQL tanımınız mutlaka birden fazla yazıcı içeriyorsa Hyperscale size farklı bir takas sunuyor. Önceliğiniz işlemler, tutarlılık, SQL uyumluluğu, kurumsal operasyonlar, depolama ve okuma ölçeğiyse Hyperscale’i bu gereksinimlere göre değerlendirip yazma kapasitesini ayrı bir başlık olarak ele almak mantıklı.

Performans tarafında ne var?

Aurora da compute’u dağıtık bir depolama katmanından ayırıyor, yani AWS benzer bir mimari yolu izlemiş; doğal karşılaştırma noktası bu yüzden Aurora oluyor. Principled Technologies tam bu karşılaştırmayı yapmış, testin Microsoft tarafından ısmarlandığı da yazıda açıkça belirtiliyor.

Testte Hyperscale Premium-series ile Amazon Aurora PostgreSQL I/O-Optimized, 2,3 TB’lık bir veritabanı üzerinde HammerDB TPROC-C iş yüküyle karşılaştırılmış. 16 vCore seviyesinde Hyperscale, Aurora’ya kıyasla %52’ye kadar daha yüksek performans ve %51’e kadar daha iyi dolar başına performans vermiş, test edilen her eşzamanlılık seviyesinde önde çıkmış. Yazının kendi uyarısı da yerinde, sizin iş yükünüz bir benchmark değil; kendi testinizi yapın. Yöntem bilgisi kamuya açık.

Tek fiyat ve küçükten başlama imkanı

Hyperscale tek ve her şey dahil bir fiyatla sunuluyor, satın alınacak ayrı bir yazılım ya da ayrı bir I/O ücreti yok. Başlangıç noktası 10 GB, yani bu katman yalnızca “çok büyük veritabanları” için değil. Bob Ward’ın ifadesiyle “start here, stay here”, burada başlayıp burada kalabiliyorsunuz. Serverless tarafında otomatik duraklatma ve devam ettirme özelliği de önizlemede; kimsenin kullanmadığı bir dev/test veritabanının compute’u sıfıra kadar inebiliyor.

Özet

Hyperscale’i “distributed SQL mi, değil mi” ikilemine sıkıştırmak soruyu yanlış yerden kuruyor. Depolama, log, sayfa sunumu ve yedekleme gerçekten dağıtık, yazma yolu ise bilinçli biçimde tek noktada tutuluyor. Karar verirken en pratik yol, ihtiyaç listesini ikiye ayırmak: okuma ölçeği, depolama büyümesi, geri yükleme süresi ve SQL uyumluluğu bir tarafta, çok yazıcılı topoloji gereksinimi diğer tarafta.

Kaynaklar ve İleri Okuma

• Is Azure SQL Database Hyperscale “distributed SQL”? — Anna Hoffman, Azure SQL Dev Corner
• The paper that split the database in four: Socrates ve Hyperscale mimarisi
• Principled Technologies benchmark raporu
• Azure SQL Database Foundations video serisi
• Azure SQL Dev Corner blogu
• Azure SQL Hyperscale’in Socrates Mimarisi Nasıl Çalışır