Sanal çekirdek ve DTU satın alma modelleri arasında seçim Azure SQL Veritabanı SQL Yönetilen Örnek

  • Makale
  • Okumak için 10 dakika

Uygulama hedefi: Azure SQL Veritabanı Azure SQL yönetilen örneği

Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği, performans ve maliyet ihtiyaçlarına uygun, tam olarak yönetilen bir hizmet olarak platform (PaaS) veritabanı altyapısını kolayca satın alasınız. Uygulama için seçtiğiniz dağıtım modeline bağlı Azure SQL Veritabanı, size uygun satın alma modelini de kullanabilirsiniz:

  • Sanal çekirdek (sanal çekirdek) tabanlı satın alma modeli (önerilir). Bu satın alma modeli, sağlanan işlem katmanı ile sunucusuz işlem katmanı arasında bir seçenek sağlar. Sağlanan işlem katmanıyla, iş yükünüz için her zaman sağlanan işlem kaynaklarının tam miktarını seçersiniz. Sunucusuz işlem katmanı ile, yapılandırılabilir bir işlem aralığı üzerinden işlem kaynaklarının otomatik ölçeklendirmeyi belirtirsiniz. Bu işlem katmanıyla, iş yükü etkinliğine göre veritabanını otomatik olarak duraklatabilir ve sürdürebilirsiniz. Sağlanan işlem katmanında, zaman birimi başına sanal çekirdek birim fiyatı, sunucusuz işlem katmanına göre daha düşüktür.
  • Veritabanı işlem birimi (DTU) tabanlı satın alma modeli. Bu satın alma modeli, ortak iş yükleri için paketlenmiş işlem ve depolama paketleri sağlar.

Azure performansını geliştirmek için SQL!

İki satın alma modeli vardır:

Aşağıdaki tablo ve grafik, sanal çekirdek tabanlı ve DTU tabanlı satın alma modellerini karşıtlıklı olarak gösterir:

Satın alma modeli Açıklama En iyi kullanım alanı:
DTU tabanlı Bu model işlem, depolama ve I/O kaynaklarının paketlenmiş bir ölçüsüne dayalıdır. İşlem boyutları tek veritabanları için DTU cinsinden ve elastik havuzlar için elastik veritabanı işlem birimi (eDTU) cinsinden gösterilir. DTU’lar ve eDTU’lar hakkında daha fazla bilgi için bkz. DTU’lar ve eDTU’lar nedir?. Basit, önceden yapılandırılmış kaynak seçenekleri isteyen müşteriler
Sanal çekirdek tabanlı Bu model, işlem ve depolama kaynaklarını bağımsız olarak seçmenize olanak sağlar. Sanal çekirdek tabanlı satın alma modeli maliyetleri azaltmak için SQL Server’ın Azure Hibrit Avantajı’nı kullanmanıza da olanak tanır. Esneklik, denetim ve saydamlığa değer veren müşteriler

Fiyatlandırma modeli karşılaştırması

Bulut harcamalarınızı iyileştirmek ve tasarruf etmek ister misiniz?

Azure hizmetleri maliyet parayı. Azure Maliyet Yönetimi harcamaları denetim altına almak için bütçeleri ayarlamanıza ve uyarıları yapılandırmanıza yardımcı olur. Maliyet yönetimi ile Azure maliyetlerinizi çözümleyin, yönetin ve iyileştirin. Daha fazla bilgi edinmek için bkz. Maliyetlerinizi analiz etmeye hızlı başlangıç.

İşlem maliyetleri

Sağlanan işlem maliyetleri

Sağlanan işlem katmanında işlem maliyeti, uygulama için sağlanan toplam işlem kapasitesini yansıtıyor.

Bu İş Açısından Kritik katmanında otomatik olarak en az üç çoğaltma ayıracağız. İşlem kaynaklarının bu ek ayırmayı yansıtması için, sanal çekirdek tabanlı satın alma modelinde fiyat, İş Açısından Kritik hizmet katmanında, sanal çekirdek tabanlı satın alma modelinden yaklaşık 2,7 kat daha Genel Amaçlı daha yüksektir. Benzer şekilde, İş Açısından Kritik hizmet katmanında GB başına daha yüksek depolama fiyatı, SSD depolamanın daha yüksek IO sınırlarını ve daha düşük gecikme süresini yansıtıyor.

Her iki katman da yedeklemeler için standart depolama alanı İş Açısından Kritik depolama alanı Genel Amaçlı depolama alanı ve depolama katmanı için yedekleme depolama alanı maliyeti aynıdır.

Sunucusuz işlem maliyetleri

İşlem kapasitesinin nasıl tanımlandığı ve maliyetlerin sunucusuz işlem katmanı için nasıl hesaplandığı hakkında bir açıklama için bkz. SQL Veritabanı katmanı.

Depolama maliyetleri

Farklı depolama türleri farklı şekilde faturalandırıldı. Veri depolama için, sağlanan depolama için, seçerek maksimum veritabanı veya havuz boyutuna göre ücret alırsınız. Bu maksimum değeri azaltmadıkça veya artırmadıkça maliyet değişmez. Yedekleme depolaması örneğinizin otomatik yedeklemeleriyle ilişkilendirildi ve dinamik olarak ayrılır. Yedekleme saklama sürenizi artırmak, örneğinin tüketildiği yedekleme depolama alanını artırır.

Varsayılan olarak, veritabanlarınızı yedi günlük otomatik yedeklemeler okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) standart Blob depolama hesabına kopyalanır. Bu depolama, her beş dakikada bir kopyalanan haftalık tam yedeklemeler, günlük değişiklik yedekleri ve işlem günlüğü yedeklemeleri tarafından kullanılır. İşlem günlüklerinin boyutu, veritabanının değişiklik hızına bağlıdır. Ek ücret ödemeden veritabanı boyutunun yüzde 100'e eşit en düşük depolama alanı miktarı sağlanır. Yedekleme depolama alanı ek tüketimi aylık GB olarak ücrete tabidir.

Depolama fiyatları hakkında daha fazla bilgi için fiyatlandırma sayfasına bakın.

Sanal çekirdek tabanlı satın alma modeli

Sanal çekirdek (sanal çekirdek), mantıksal bir CPU'yu temsil eder ve donanım nesilleri ile donanımın fiziksel özellikleri (örneğin, çekirdek sayısı, bellek ve depolama boyutu) arasında seçim seçeneği sunar. Sanal çekirdek tabanlı satın alma modeli size esneklik, denetim, tek tek kaynak tüketiminin saydamlığını ve şirket içi iş yükü gereksinimlerini buluta çevirmenin kolay bir yolunu sağlar. Bu model, iş yükü ihtiyaçlarına göre işlem, bellek ve depolama kaynaklarını seçmenize olanak sağlar.

Sanal çekirdek tabanlı satın alma modelinde, Genel Amaçlı ve İş Açısından Kritik Yönetilen Örneği için SQL Veritabanı ve SQL katmanlarını seçebilirsiniz. Tek veritabanları için Hiper Ölçek hizmet katmanını da seçebilirsiniz.

Sanal çekirdek tabanlı satın alma modeli işlem ve depolama kaynaklarını bağımsız olarak seçmenize, şirket içi performansla eşleşmenizi ve fiyatı iyileştirmenizi sağlar. Sanal çekirdek tabanlı satın alma modelinde aşağıdakiler için ödeme siz ödersiniz:

  • İşlem kaynakları (hizmet katmanı + sanal çekirdek sayısı ve bellek miktarı + donanım oluşturma).
  • Veri türü ve miktarı ile günlük depolaması.
  • Yedekleme depolama alanı (RA-GRS).

Önemli

İşlem kaynakları, G/Ç ve veri ve günlük depolaması veritabanı veya elastik havuz başına ücrete tabidir. Yedekleme depolaması her veritabanı için ücrete tabidir. Yönetilen Örnek ücretlerini SQL daha fazla bilgi için bkz. SQL Yönetilen Örnek. Bölge sınırlamaları: Desteklenen bölgelerin geçerli listesi için bkz. bölgeye göre kullanılabilir ürünler. Şu anda destekçi olmayan bir bölgede yönetilen örnek oluşturmak için,Azure portal.

Veritabanınız 300'den fazla DTU tüketirse sanal çekirdek tabanlı satın alma modeline dönüştürmek maliyetlerinizi düşürebilirsiniz. Dönüştürmeyi tercih edin API'nizi kullanarak veya kapalı kalma süresi Azure portal kullanarak dönüştürebilirsiniz. Ancak dönüştürme gerekli değildir ve otomatik olarak yapılmaz. DTU tabanlı satın alma modeli performans ve iş gereksinimlerinizi karşılamıyorsa, kullanmaya devam edin.

DTU tabanlı satın alma modelinden sanal çekirdek tabanlı satın alma modeline dönüştürmek için bkz. DTU'dan sanal çekirdek'e geçiş.

DTU tabanlı satın alma modeli

Bir veritabanı işlem birimi (DTU), CPU, bellek, okuma ve yazma işlemlerinin harmanlanmış bir ölçüsünü temsil eder. DTU tabanlı satın alma modeli, farklı uygulama performansı düzeylerine sahip olmak için önceden yapılandırılmış bir dizi işlem kaynağı paketi ve dahil depolama alanı sunar. Önceden yapılandırılmış bir paketin ve her ay sabit ödemelerin basitliğini tercih ederseniz, DTU tabanlı model sizin için daha uygun olabilir.

DTU tabanlı satın alma modelinde, temel, standart ve premium hizmet katmanları arasında seçim Azure SQL Veritabanı. DTU tabanlı satın alma modeli, Azure yönetilen SQL kullanılamaz.

Veritabanı işlem birimleri (DTU)

Hizmet katmanı içindeki belirli bir işlem boyutuna sahip tek bir veritabanı için Azure,bu veritabanı için belirli bir kaynak düzeyini garantiler (Azure bulutu içindeki diğer veritabanılardan bağımsız olarak). Bu garanti, tahmin edilebilir bir performans düzeyi sağlar. Bir veritabanı için ayrılan kaynak miktarı bir dizi DTA olarak hesaplanır ve işlem, depolama ve I/O kaynaklarının paketlenmiş bir ölçüsüdür.

Bu kaynaklar arasındaki oran başlangıçta gerçek olTP iş yüklerinin tipik bir sonucu olacak şekilde tasarlanmış bir çevrimiçi işlem işleme (OLTP) karşılaştırma iş yükü tarafından belirlenir. İş yükünüz bu kaynaklardan herhangi biri miktarını aştı mı, aktarım hızınız kısıtlandı ve bu da daha yavaş performans ve zaman aşımları ile sonuçlandı.

İş yükünüz tarafından kullanılan kaynaklar, Azure bulut üzerindeki diğer veritabanlarında bulunan kaynakları etkilemez. Benzer şekilde, diğer iş yükleri tarafından kullanılan kaynaklar veritabanınız için kullanılabilir kaynakları etkilemez.

Sınırlayıcı kutu

DTI'lar en çok farklı işlem boyutları ve hizmet katmanlarına sahip veritabanları için ayrılan göreli kaynakları anlamak için kullanışlıdır. Örnek:

  • Veritabanının işlem boyutunu artırarak DKU'ları iki katına, bu veritabanı için kullanılabilir olan kaynak kümelerini iki katına artırmaya eşit olur.
  • 1750 DTU'ya sahip bir premium hizmet katmanı P11 veritabanı, 5 DTU'ya sahip temel bir hizmet katmanı veritabanından 350 kat daha fazla DTU işlem gücü sağlar.

İş yüklerinizi kaynak (DTU) kullanımıyla ilgili daha derin içgörüler elde etmek için sorgu performansı içgörülerini kullanarak şunların için:

  • İyi performans için ayarlanabilecek CPU/süre/yürütme sayısına göre en iyi sorguları belirleme. Örneğin, yoğun bellek kullanan bir sorgu, belirli bir hizmet katmanında ve işlem boyutunda kullanılabilir belleği daha iyi kullanmak için bellek içi iyileştirme tekniklerinden yararlanabilir.
  • Metnini ve kaynak kullanımı geçmişini görüntülemek için sorgunun ayrıntılarına inin.
  • SQL Veritabanı Advisor tarafından yapılan eylemlerin yer SQL Veritabanı erişin.

Elastik veritabanı işlem birimleri (eDU)

Her zaman kullanılabilir olan veritabanları için, her zaman gerekebilecek ayrılmış bir kaynak kümesi (DTU) sağlamak yerine, bu veritabanlarını elastik bir havuza yerebilirsiniz. Elastik havuza sahip veritabanları tek bir sunucudadır ve bir kaynak havuzunu paylaşır.

Elastik havuza paylaşılan kaynaklar esnek veritabanı işlem birimleri (eDDU) ile ölçülür. Elastik havuzlar, çok çeşitli ve öngörülemeyen kullanım düzenlerine sahip birden çok veritabanı için performans hedeflerini yönetmek için basit, uygun maliyetli bir çözüm sağlar. Elastik havuz, havuza her bir veritabanının her zaman en az miktarda gerekli kaynağın mevcut olmasını sağlarken, tüm kaynakların havuz içinde bir veritabanı tarafından tüketilmemesi garantisini verir.

Havuza, ayarlanmış bir fiyat için ayarlanmış sayıda eDTI verilir. Elastik havuzda, tek tek veritabanları yapılandırılan sınırlar içinde otomatik olarak ölçeklenebitir. Yükü daha ağır olan bir veritabanı talebi karşılamak için daha fazla eDDU kullanır. Daha hafif yükler altındaki veritabanları daha az eDTI tüketir. Yükü olan veritabanları eDTI'leri tüketir. Kaynaklar veritabanı başına değil havuzun tamamı için sağlanmış olduğundan, elastik havuzlar yönetim görevlerinizi basitleştirir ve havuz için öngörülebilir bir bütçe sağlar.

Veritabanı kapalı kalma süresine gerek kalmadan ve havuz üzerindeki veritabanlarını etkilemeden var olan bir havuza ek eDTI'lar eklersiniz. Benzer şekilde, artık ek eDTI'lere ihtiyacınız yoksa, bunları istediğiniz zaman mevcut havuzdan kaldırın. Ayrıca, veritabanlarını herhangi bir zamanda havuza ekleyebilir veya havuzdan çıkarabilirsiniz. Diğer veritabanlarına eDTI'ları rezervasyon yapmak için, bir veritabanının ağır yük altında kullanabileceği eDTI sayısını sınırla. Bir veritabanı tutarlı bir şekilde kaynakları az kullanırsa, bunu havuzdan dışarı taşı ve öngörülebilir miktarda gerekli kaynakla tek bir veritabanı olarak yapılandır.

Bir iş yükü için gereken DTUS sayısını belirleme

Mevcut bir şirket içi veya sanal makine SQL Server yükünü SQL Veritabanı DTU hesaplayıcısını kullanarak gereken yaklaşık DTU sayısını hesaplayabilirsiniz. Mevcut bir SQL Veritabanı için sorgu performansı içgörülerini kullanarak veritabanı kaynak tüketiminizi (DTU) anlı ve iş yüklerinizi iyileştirmeye yönelik daha ayrıntılı içgörüler elde edin. Dinamik sys.dm_db_resource_stats görünümü (DMV) son bir saat için kaynak tüketimini görüntülemenizi sağlar. Katalog sys.resource_stats görünümü son 14 gün için kaynak tüketimini görüntüler, ancak beş dakikalık ortalamaların daha düşük bir uygunluktadır.

DTU kullanımını belirleme

Bir veritabanının veya elastik havuzun DTU/eDTU sınırına göre ortalama DTU/eDTU kullanımı yüzdesini belirlemek için aşağıdaki formülü kullanın:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

Bu formülün giriş değerleri sys.dm_db_resource_stats , sys.resource_statsve DMV'sys.elastic_pool_resource_statselde edilir. Başka bir deyişle, bir veritabanının veya elastik havuzun DTU/eDTU sınırına yönelik DTU/eDTU kullanımının yüzdesini belirlemek için, şu değerden en büyük yüzde değerini seçin: , ve belirli bir avg_cpu_percent avg_data_io_percent zaman avg_log_write_percent noktasında.

Not

Veritabanının DTU sınırı CPU, okuma, yazma ve veritabanında kullanılabilen bellek tarafından belirlenir. Ancak, SQL Veritabanı altyapısı performansı artırmak için genellikle veri önbelleği için tüm kullanılabilir belleği kullandığından, geçerli veritabanı yüküne bakılmaksızın değer genellikle yüzde avg_memory_usage_percent 100'e yakın olur. Bu nedenle bellek, DTU sınırını dolaylı olarak etkilese de DTU kullanım formülünde kullanılmaz.

Elastik kaynak havuzundan yararlanan iş yükleri

Havuzlar, düşük kaynak kullanım ortalaması ve nispeten seyrek kullanım artışları olan veritabanları için çok uygun. Daha fazla bilgi için bkz. Elastik havuzu ne SQL Veritabanı göz önünde bulundurabilirsiniz?.

DTU tabanlı satın alma modelinde donanım nesilleri

Müşteriler, DTU tabanlı satın alma modelinde veritabanları için kullanılan donanım neslini seçemektedir. Belirli bir veritabanı genellikle belirli bir donanım nesli üzerinde uzun süre (genellikle birden çok ay) kalsa da, veritabanının başka bir donanım nesline taşınmaya neden olan bazı olaylar vardır.

Örneğin, farklı bir hizmet hedefine ölçeklendirilen veya indirilen bir veritabanı, farklı bir donanım nesline taşınarak veya bir veri merkezinde bulunan mevcut altyapının kapasite sınırlarına yaklaştığında ya da kullanım ömrü sona erer nedeniyle o anda kullanılan donanımın kullanımdan kaldırılamayacak olması.

Bir veritabanı farklı donanıma taşınırsa iş yükü performansı değişebilir. DTU modeli, hizmet hedefi (DTU sayısı) aynı olduğu sürece veritabanı farklı bir donanım oluşturma modeline geçişte DTU karşılaştırma iş yükünün aktarım hızı ve yanıt süresi önemli ölçüde aynı kalacaktır.

Ancak, Azure SQL Veritabanı'da çalışan çok çeşitli müşteri iş yükleri genelinde, aynı hizmet hedefi için farklı donanım kullanmanın etkisi daha belirgin olabilir. Farklı iş yükleri, farklı donanım yapılandırması ve özelliklerinden faydalanır. Bu nedenle DTU karşılaştırması dışında iş yükleri için veritabanı bir donanım neslinden diğerine taşınırsa performans farklarını görmek mümkündür.

Örneğin, Ağ gecikme süresine duyarlı bir uygulama, Gen5'te Hızlandırılmış Ağ kullanımı nedeniyle Gen5 donanımlarında ve 4. Nesil'de daha iyi performans görebilir, ancak yoğun okuma IO'su kullanan bir uygulama, 4. Nesil'de çekirdek başına bellek oranı daha yüksek olduğu için Gen4 donanımlarında ve Gen5'te daha iyi performans görebilir.

Donanım değişikliklerine duyarlı iş yükleri olan müşteriler veya veritabanı için donanım oluşturma tercihini kontrol etmek isteyen müşteriler, veritabanı oluşturma ve ölçeklendirme sırasında tercih edilen donanım neslini seçmek için sanal çekirdek modelini kullanabilir. Sanal çekirdek modelinde, hem tek veritabanları hem de elastik havuzlar için her donanım oluşturmada her bir hizmet hedefinin kaynak sınırları belgelenmiş olur. Sanal çekirdek modelinde donanım nesilleri hakkında daha fazla bilgi için bkz. SQL Veritabanı için donanım nesilleri veya SQL Yönetilen Örneği için donanım nesilleri.

Sık sorulan sorular (SSS)

DTU tabanlı hizmet katmanından sanal çekirdek tabanlı hizmet katmanına dönüştürmek için uygulamamı çevrimdışı duruma getirmem gerekiyor mu?

Hayır. Uygulamayı çevrimdışı duruma getirmeniz gerek yok. Yeni hizmet katmanları, veritabanlarını standarttan premium hizmet katmanına yükseltmeye ve diğer yollara benzer basit bir çevrimiçi dönüştürme yöntemi sağlar. Azure portal, PowerShell, Azure CLI, T-SQL veya REST API. Bkz. Tek veritabanlarını yönetme ve Elastik havuzları yönetme.

Bir veritabanını sanal çekirdek tabanlı satın alma modelinde bir hizmet katmanından DTU tabanlı satın alma modelinde bir hizmet katmanına dönüştürün.

Evet, Azure portal, PowerShell, Azure CLI, T-SQL veya REST API. Bkz. Tek veritabanlarını yönetme ve Elastik havuzları yönetme.

Sonraki adımlar