Azure SQL Hyperscale'in mimarisi: Socrates makalesi neyi değiştirdi

Microsoft'un Azure SQL Hyperscale hizmetinin temelindeki Socrates mimarisini anlatan 2019 makalesi yeniden ele alındı. Hesaplama, log, sayfa sunucuları ve depolama katmanlarına ayrılan tasarım, büyük veritabanlarında yedekleme ve replika işlemlerinin neden veri boyutundan bağımsız olduğunu açıklıyor. Hyperscale kullanan ya da değerlendiren geliştiriciler için mimarinin arkasındaki mantığı anlamak için iyi bir kaynak.

Kilit noktalar

• Socrates, Hyperscale'in kod adıdır ve makale 2019'da SIGMOD'da yayımlandı.
• Compute düğümleri tam veri kopyası tutmaz; RBPEX adlı yerel SSD önbelleği buffer pool'u genişletir.
• XLOG servisi işlem logunu yönetir ve log blokları page server'lara ve replikalara dağıtılır.
• GetPage@LSN, bir sayfayı belirli bir log konumuna kadar uygulanmış halde isteyerek bayat sayfa okunmasını önler.
• Makaleye göre maksimum boyut 4 TB'tan 100 TB'a çıkmış, ölçekleme işlemleri veri boyutundan bağımsız hale gelmiştir.
• Yazar, Hyperscale'in bugün 150 MB/s log throughput ve 128 TB'a kadar otomatik depolama sunduğunu belirtiyor.

Azure SQL ekibi, Hyperscale'in temelindeki Socrates tasarımını anlatan 2019 tarihli SIGMOD makalesini yeni bir blog serisinde ele alıyor. Geleneksel Business Critical mimarisinde her replika tam veri kopyası tuttuğu için depolama, yedekleme ve yeni replika ekleme işlemleri veritabanı büyüdükçe pahalılaşıyordu. Socrates bu yükü dört katmana ayırıyor: sorguyu çalıştıran hesaplama düğümleri, işlem logunu yöneten XLOG servisi, veriyi sayfa bazında tutan page server'lar ve Azure Storage üzerindeki kalıcı XStore.

Makaleye göre sayfa sunucuları GetPage@LSN çağrısıyla istenen sayfayı belirli bir log noktasına kadar uygulanmış halde döndürüyor, bu da eski sayfa okunmasını engelliyor. Ölçümlerde maksimum veritabanı boyutu 4 TB'tan 100 TB'a, ölçekleme işlemleri O(data)'dan O(1)'e düşmüş. Yazar, bu mimarinin bugün anlık yedekleme, veri boyutundan bağımsız geri yükleme, hızlı okuma replikaları ve 128 TB'a kadar otomatik büyüyen depolama olarak yaşadığını belirtiyor.

Gerçek dünyada kullanımı

• Onlarca TB'lık bir OLTP veritabanında yedekleme ve geri yükleme sürelerini kabul edilebilir tutmak isteyen ekipler.
• Okuma yükünü ayırmak için yeni named replica açıp raporlama veya analitik sorgularını transactional trafikten uzak tutmak.
• Küçük başlayıp büyüyen bir SaaS uygulamasında, veritabanını yeniden taşımadan Hyperscale'e geçiş planı yapmak.

Neden önemli

Hyperscale'in yedekleme, geri yükleme ve replika davranışının neden veri boyutundan bağımsız olduğunu anlamak, kapasite ve yüksek erişilebilirlik kararlarını daha bilinçli vermenizi sağlar. Mevcut T-SQL uygulamanız büyük ölçüde aynı kalır, değişen şey altyapının katmanlı yapısıdır.

Benzer haberler

• C# interface'lerinde collection dönüş tipleri: interface, view ve snapshot farkıDLNick Cosentino (Dev Leader)2 gün önce
• NebulaGraph'a .NET'ten idempotent toplu yükleme: VID ile çoğaltma sorunuDVDEV Community: #csharp3 gün önce
• C# olayları ve delegate'ler: sözleşme, abonelik ve bildirimDLNick Cosentino (Dev Leader)3 gün önce