Takip et

Neden Microsoft Azure SQL Veritabanı?

Microsoft Azure’u seviyoruz. Azure sizler için yönetim açısından iyi düşünülmüş, birçok yönünü kontrol etmek için güçlü API ve hayal edebileceğiniz kadar geliştirici odaklı hizmet sunar.

Azure ortamı, Amazon’a çok benzer şekilde, çeşitli Veritabanlarını da benim de yoğun olarak kullandığım bir hizmet olarak sunuyor.

Aşağıdaki özelliklerden bazıları bence Azure üzerinde saklanan veritabanlarının avantajları:

  • Dinamik bellek önbellekleri
  • Sütun bazlı store dizinleri
  • Şeffaf veri şifreleme

Son olarak, mümkün olduğunca çok ülkeyi kapsayan bir Servis sağlayıcı ağına sahip diyebiliriz

Veritabanı Performansı ve Boyutlandırma

Veritabanı boyutlandırması ve yapılandırması kolay değildir.

Farklı donanım ve farklı iş yükleri, şema ve hacim altında bir veritabanına ince ayar yapmak için çok sayıda test ve izleme yinelemesi gerektirir.

Belirli bir donanım konfigürasyonu altında iyi performans gösteren bir sorgu, konfigürasyon daha iyi olarak algılansa bile, başka bir sorguda iyi performans göstermeyebilir.

Azure’un Veritabanı tekliflerinde gezinmek daha da karmaşıktır. Gelir modelleri, altyapıları ve ölçeklendirmeleri müşterilere karşı şeffaf olmadığından, teklifleri performansı ölçmek için soyut ölçekler kullanır.

Bu ölçekler gerçek dünya örnekleriyle kolayca uyumlu değildir. Temel olarak bugün, DTU tabanlı model ve sanal çekirdek tabanlı bir model olmak üzere iki ana mod sunuyorlar.

vCore Modeli

Microsoft geçtiğimiz yıllarda vCore serisini de yayınladı.

Bu veritabanı için diskin boyutunu ve vCores sayısını seçebildiğiniz için vCore serisinin daha iyi olduğu varsayılır.

vCore’un 2 çeşidi vardır: Genel Amaçlı ve İş Açısından Kritik.

Ek olarak, 2 nesil işlemci / konfigürasyona sahipler: 4. Nesil ve 5. Nesil.

Genel Amaç, sanal çekirdek başına 500 IOPS’den maksimum 7000’e kadar, İş Açısından Kritik sanal çekirdek başına 5000 IOPS’ye kadar maksimum 200.000 IOPS’ye sahiptir.

vCore, veritabanlarını boyutlandırmak için çok daha makul bir model gibi görünüyor, ancak kendi tutarsızlıkları var.

Örnek olarak Genel Amaçlı. Temel olarak, 14 çekirdekten sonra mümkün olan maksimum IOPS’ye ulaşırsınız. GP, 8, 16, 24, 32, 40, 64 ve 80 vCores adımlarında satıldığı için, özünde, 8 çekirdekten sonra mümkün olan maksimum IOPS’de olduğunuz anlamına gelir.

Peki, gerçek darboğaz sizin diskiniz olduğunda 80 sanal çekirdek gerektiren sorgularınızda hangi durumlarda bu kadar çok paralelliğe ihtiyaç duyarsınız? Eminim bundan fayda sağlayabilecek sorular vardır, ancak çoğu durumda değil.

Ayrıca, hem Genel Amaçlı hem de İş Açısından Kritik olarak 4. Nesil veya 5. Nesil seçildiğinde, bazen hem Azure Portal hem de Fiyatlandırma Hesaplayıcı’da farklı değerler verilir.

Yorumlar
İçeriği beğendiniz mi? Bir tartışma başlatın veya görüşlerinizi paylaşın.
Yorum Yaz

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

E-posta Bülteni
Yazılım Topluluğuna Katılın
En son güncellemeleri, yaratıcı ipuçlarını ve özel kaynakları doğrudan e-posta kutunuza alın. Tasarım ve inovasyonun geleceğini birlikte keşfedelim.