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.