Azure SQL Database Hyperscale dağıtık SQL midir?

Azure SQL Database Hyperscale'in mimarisi, tek yazıcılı bir SQL motorunu depolama ve günlük katmanlarına ayırarak dağıtık bir yapı sunuyor. Yazar, bu ayrımın "dağıtık SQL" tanımıyla nasıl örtüştüğünü ve benchmark sonuçlarını inceliyor. Veri katmanı seçimi yapan geliştiriciler için kullanışlı bir değerlendirme.

Kilit noktalar

• Hyperscale tek bir primary ile yazma kabul eder; çok yazıcılı dağıtık commit gerekiyorsa bu bir kısıttır.
• Depolama 128 TB'a kadar otomatik büyür; yedekler compute'a dokunmayan anlık snapshot'lardır.
• Up to four HA replica ve 30 adet named replica ile okuma ve raporlama iş yükleri ayrılabilir.
• Log hızı 150 MB/s'e, compute ise Premium-series donanımda 192 vCore'a kadar çıkar.
• Benchmark Microsoft'un yaptırdığı bir çalışmadır; kendi iş yükünüzle ölçüm yapın.
• Serverless auto-pause ve resume özelliği önizleme aşamasındadır.

Microsoft'un Azure SQL ekibinden Anna Hoffman, Hyperscale'in "dağıtık SQL" olup olmadığını tartışan yeni bir yazı yayımladı. Yazara göre Hyperscale, işlem motorunu compute replica'lar, log servisi, page server'lar ve Azure Storage üzerine dağıtıyor; ancak yalnızca tek bir primary yazma kabul ediyor. Bu tercih, dağıtık commit protokolü ve çakışma çözümü ihtiyacını ortadan kaldırıyor ve T-SQL yüzeyini koruyor.

Yazıda öne çıkan rakamlar arasında 128 TB'a kadar otomatik büyüme, 30 adet named replica, saniyede 150 MB log hızı ve 192 vCore'a kadar compute yer alıyor. Microsoft'un yaptırdığı bir karşılaştırmada, 16 vCore'da Hyperscale'in Aurora PostgreSQL I/O-Optimized'a göre %52'ye kadar daha yüksek performans sunduğu belirtiliyor. Yazar, sonuçların iş yükünüze göre değişebileceği uyarısını da yapıyor.

Gerçek dünyada kullanımı

• Büyüyen bir SaaS veritabanı; tek yazıcılı ama 10 TB üzerine çıkabilecek bir OLTP sistemi.
• Raporlama ve AI sorgularını ana yazma düğümünden ayırmak için named replica kullanan bir analitik ekip.
• Mevcut SQL Server uygulamasını T-SQL değiştirmeden bulut veritabanına taşıyan bir ekip.

Neden önemli

Veritabanı seçerken "dağıtık" etiketine takılmadan yazma kapasitesi, depolama, okuma ölçeği ve operasyon gereksinimlerini ayrı ayrı değerlendirmek gerekir. Hyperscale'de yazma tek primary'den geçtiği için çok bölgeli yazma ihtiyacınız varsa farklı bir mimari seçmeniz gerekebilir.

Benzer haberler

• Cosmos DB Change Feed ile işi birden çok worker arasında dengelemeCCC# Corner4 gün önce
• MCP Sunucularında Ölçekte Rate Limiting ve Kaynak YönetişimiDVDEV Community: #aspnetcore1 gün önce
• C# interface'lerinde collection dönüş tipleri: interface, view ve snapshot farkıDLNick Cosentino (Dev Leader)2 gün önce