Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Bulut bilişim, veri tabanı barındırma ortamını önemli ölçüde yeniden şekillendirdi. Ekiplere ölçeklenebilirlik, dayanıklılık, genel erişim ve önceden ulaşılamayan özelliklere erişim sağlar. Ekipler, mümkün olan en büyük iş yükünü planlayarak (ve bu maliyeti ilk günden itibaren taşıyarak) önemli maliyetler ve ek yükler sağlamak yerine artık ihtiyaç duydukları hassas ölçek etrafında iyileştirme yapabilir ve talepleri değiştikçe uyum sağlayabilir.
Introduction
Kaynakların uygun bakiyesini seçme esnekliği özellikle PostgreSQL veritabanı dağıtımları için önemlidir. PostgreSQL veritabanı iş yükleri küçük başlayabilir, hızla büyüyebilir, mevsimsel olarak ani artış gösterebilir, yoğun okumadan yazma ağıra geçiş yapabilir veya işlem iş yüklerinden gerçek zamanlı olarak hibrit operasyonel ve analitik sistemlere dönüşebilir. PostgreSQL için Azure Veri Tabanı işlem, depolama, kullanılabilirlik, çoğaltma, güvenlik, yedekleme ve işletim yönetimi gibi çeşitli seçenekler sunarak çözümlerinizin hedeflerinize ulaşmasını sağlar.
Ancak tüm bu güç, özellikle dağıtımlarınızı planlarken sorumluluk getirir. Mümkün olan en iyi performansı elde etmek için dağıtım kararlarınızın genel iş yükünüzün gereksinimlerine uyması gerekir.
Başarılı bir PostgreSQL için Azure Veri Tabanı dağıtımı yalnızca "ihtiyacımız olan en çok çekirdeği ve belleği" seçmekle ilgili değildir. Bunun yerine, en yüksek işlem performansı uygulamanızın davranışlarını, istemcinin davranışlarını, işlem, depolama ve veritabanı büyüme özelliklerini ve bunların nasıl kesişip etkileşime geçtiğini anlamaktan kaynaklanabilir.
En iyi mimari, bu parçaların kasıtlı olarak hizalandığı mimaridir.
Bulut performansı planlaması paylaşılan bir sorumluluk
Güvenilir bir bulut platformuna geçmenin başlıca avantajlarından biri paylaşılan sorumluluk modelidir. Microsoft küresel altyapı, yönetilen hizmetler, donanım yenilikleri, güvenilirlik, güvenlik ve operasyonel mühendislik sağlar. Ekipleriniz belirli uygulama bağlamı uzmanlığını getirir: iş açısından kritiklik, iş yükü davranışı, veri modeli tasarımı, ağ trafiği profili, büyüme beklentileri, kurtarma hedefleri ve son kullanıcı deneyimi gereksinimleri.
En güçlü sonuçlar, bu iki kuvvet bir araya geldiğinde ortaya çıkar.
Azure yüksek oranda ölçeklenebilir Postgres altyapısı sağlar, ancak ekibinizin şu alanlara içgörüler getirmesi gerekir:
- Normal ve yoğun dönemlerde kaç eşzamanlı kullanıcı bekleniyor?
- En önemli işlemler okuma ağırlıklı mı, yazma ağırlıklı mı yoksa karma mı?
- Ay sonu, üç aylık dönem sonu, tatiller, lansmanlar veya raporlama pencereleri sırasında talep artışı mı var?
- Veri kümesi ne kadar hızlı büyüyor?
- Hangi işlemler gecikme süresine duyarlıdır?
- Hangi sorgular veya işler daha uzun çalışma zamanlarını tolere edebilir?
- İş yükü öncelikle OLTP, OLAP veya karma mı?
- İstemciler veritabanı bölgesinin yakınında mı, genel olarak dağıtılmış mı yoksa tek bir coğrafyada mı yoğunlaşmış?
Bu ayrıntıları üretim olayından sonra değil dağıtımdan önce yakalayın. Bulut dağıtımları ölçeklendirmeyi kolaylaştırır, ancak en yüksek performanslı ve en uygun maliyetli tasarımlar yine de ses gereksinimlerinin toplanması ve doğru planlama ile başlar. Çoğu durumda, bu sorular eş zamanlı bağlantılar arasındaki ilişkilere, maksimum IOPS'ye ve gerekli aktarım hızına indirgenebilir.
Performansın birden çok katmanı vardır
Veritabanı performansı nadiren tek bir ayar tarafından belirlenir. Başarılı dağıtım deneyimleri, birlikte çalışan birkaç katmana bağlıdır:
-
Uygulama katmanı performansı.
Bu katman uygulama kodu, sorgu desenleri, dizin kapsamı, tetikleyici kullanımı, veri bölümleme, bağlantı işleme, önbelleğe alma, yeniden deneme mantığı, havuz oluşturma, ORM davranışı, işlem tasarımı ve arka plan işi davranışını içerir. -
İstemci ve ağ katmanı performansı.
Bu katman istemcilerin nerede bulunduklarını, nasıl bağlandıklarını, bölgeler arası isteklerin ve kullanılabilirlik alanlarının, ağ gecikme süresinin, TLS ek yükünün, bağlantı değişim sıklığının ve uygulamanın bağlantı havuzunu verimli bir şekilde kullanıp kullanmadığını içerir. -
Veritabanı platformu performansı.
Bu katman Postgres dağıtım yapılandırması, işlem boyutu, bellek, CPU, depolama türü, depolama boyutu, depolama IOPS, depolama aktarım hızı, yüksek kullanılabilirlik, çoğaltmalar ve bakım işlemlerini içerir.
Bu makale öncelikli olarak üçüncü katmana odaklanır: Azure Postgres veritabanı dağıtımını planlayarak işlem ve depolama seçeneklerinin gerekli performans profilini desteklemesini sağlamak.
PostgreSQL için Azure Veri Tabanı esneklik sunar, ancak planlama çok önemlidir
PostgreSQL için Azure Veri Tabanı Esnek Sunucu, aşağıdakiler dahil olmak üzere çok çeşitli dağıtım seçenekleri sunar:
| Dağıtım alanı | Kullanılabilir seçenekler |
|---|---|
| Compute | İşlem katmanları, sanal makine (VM) nesilleri, Genel Amaçlı yapılandırmalar ve Bellek için İyileştirilmiş yapılandırmalar. |
| Storage | Azure Premium SSD v1, Premium SSD v2, depolama ölçeklendirme, IOPS yapılandırması ve aktarım hızı yapılandırması. |
| Availability | Desteklenen yapılandırmalarda yüksek kullanılabilirlik, yedekleme ve geri yükleme ile coğrafi yedekli yedeklemeler. |
| Replication | Okuma replikaları ve coğrafi replikalar. |
| Security | Müşteri tarafından yönetilen anahtarlar ve kurumsal güvenlik tümleştirmesi. |
Farklı iş yükleri farklı özellikler gerektirdiği için bu esneklik güçlüdür. Yoğun yazma işlem sistemi, raporlama ağırlıklı sistemle aynı profile ihtiyaç duymaz. Genel SaaS uygulaması, iç bölgesel uygulamayla aynı tasarıma ihtiyaç duymaz. Yılda 5% büyüyen bir veritabanı, ayda 200% büyüyen bir veritabanıyla aynı depolama planına ihtiyaç duymaz.
Planlama hedefi, iş yükü performans profili gereksinimlerinizi belirlemek ve ardından uçtan uca çözümlerinizi başarıyla sunmak için hem işlem hem de depolama seçeneklerinde uygun seçimleri uygulamaktır.
İş yükü profiliyle başlayın
İşlem veya depolamayı seçmeden önce iş yükünü tanımlayın. Yararlı planlama boyutları şunlardır:
| Planlama alanı | Yanıtlamak için sorular |
|---|---|
| Coğrafya | Kullanıcılar, uygulamalar, çoğaltmalar ve tümleştirmeler nerede bulunur? |
| Concurrency | Kaç eşzamanlı bağlantı ve etkin sorgu beklenir? |
| Veri boyutu | Geçerli veritabanı boyutu nedir ve beklenen büyüme oranı nedir? |
| Değişiklik oranı | Veriler aydan aya ne kadar hızlı büyür? Ne kadar ön yazım günlüğü (WAL) oluşturuluyor? |
| İş yükü türü | Sistem OLTP, OLAP, raporlama ağırlıklı, toplu iş ağırlıklı mı yoksa karma mı? |
| Okuma/yazma karışımı | İşlemlerin ne kadarı okuma ve yazma? |
| En yüksek davranış | Tahmin edilebilir iş döngüleri, mevsimsel zirveler veya toplu iş pencereleri var mı? |
| Gecikme süresi duyarlılığı | Hangi işlemler kullanıcıya yöneliktir ve gecikme süresi açısından kritiktir? |
| Aktarım hızı gereksinimleri | Büyük veri taramaları, dışarı aktarmalar, içeri aktarmalar veya ayıklama, dönüştürme ve yükleme (ETL) işlemleri var mı? |
| Beklentileri ölçeklendirme | İş yükünün geçici ani artışlara veya daha yüksek performansa ihtiyacı olacak mı? |
Amaç, geleceği mükemmel bir şekilde tahmin etmek değildir. Amaç, körü körüne tasarlamaktan kaçınmaktır.
Üç temel depolama performansı kavramını anlama
Azure depolama performansı planlaması genellikle ilgili ancak farklı üç kavramla ilgilidir: IOPS, aktarım hızı ve gecikme süresi. Bu faktörler uygulama performans planlaması için önemlidir.
IOPS
IOPS , saniye başına giriş/çıkış işlemleri anlamına gelir. Veritabanının depolama alanına saniyede kaç okuma veya yazma işlemi gönderebileceğini ölçer.
IOPS özellikle OLTP iş yükleri için önemlidir. Bu sistemler genellikle eklemeler, güncelleştirmeler, dizin aramaları, nokta okumaları ve kısa işlemler gibi çok sayıda küçük, rastgele okuma ve yazma işlemi gerçekleştirir. Her bir işlem küçük olsa bile, binlerce eşzamanlı kullanıcı içeren bir işlem iş yükü yüksek IOPS'ye ihtiyaç duyabilir.
IOPS'ye duyarlı yaygın senaryolar şunlardır:
- Yüksek hacimli sipariş işleme
- Kullanıcı profili güncelleştirmeleri
- Envanter sistemleri
- Olay alımı
- Ödeme veya faturalama sistemleri
- Yüksek oranda eş zamanlı SaaS uygulamaları
Aktarım hızı
Bazen bant genişliği olarak adlandırılan aktarım hızı, zaman içinde depolama alanından ne kadar veri okunabileceğini veya yazabileceğini ölçer. MB/sn cinsinden ifade edilir.
İşlemler büyük miktarda veriyi taşıdığında aktarım hızı önemlidir. Analiz sorguları, yedeklemeler, geri yüklemeler, toplu işler, dizin derlemeleri, tablo taramaları ve ETL iş akışları en yüksek IOPS'yi gerektirmese bile yüksek aktarım hızına ihtiyaç duyabilir.
Aktarım hızına duyarlı yaygın senaryolar şunlardır:
- Büyük tablolar üzerinden sorguları raporlama
- Toplu ithalat veya ihracat
- Veri ambarı stili taramalar
- Yedekleme ve geri yükleme işlemleri
- Büyük dizin oluşturma veya yeniden oluşturma işlemleri
- Toplu işleme
Gecikme
Gecikme süresi, tek bir G/Ç isteğinin tamamlanması için geçen süredir. Düşük gecikme süresi, özellikle birçok küçük işlemin bir işlemde zincirlendiği, kullanıcıya yönelik veritabanı işlemleri için önemlidir.
Bir sistemin teorik IOPS'leri yüksek olabilir, ancak gecikme süresi yüksekse yine de yavaş hisseder. Postgres iş yükleri için depolama gecikme süresi sorgu yanıt sürelerini, işlem işleme davranışını, denetim noktası davranışını ve genel uygulama yanıt hızını doğrudan etkileyebilir.
Uyarı
Premium SSD v1 diskleri çoğu G/Ç işlemi için tek basamaklı milisaniyelik gecikme süreleri için tasarlanmıştır ve özellikle disk önbelleğe alma, 4 TB altındaki disk yapılandırmaları için okuma gecikmesini daha da azaltabilir. Premium SSD v2 ve Ultra Disk, milisaniyenin altında gecikme süresi sunar.
IOPS, aktarım hızı ve gecikme süresi birlikte değerlendirilmelidir
IOPS ve aktarım hızı birbirine bağlıdır. Birkaç küçük 8 KiB işlem veren bir iş yükü, yüksek aktarım hızı olmadan yüksek IOPS'yi yönlendirebilir. Çok MB'lı büyük işlemler veren bir iş yükü, daha düşük IOPS ile yüksek aktarım hızı sağlayabilir.
Bunu düşünmenin basit bir yolu:
IOPS x G/Ç boyutu = Aktarım hızı
Postgres için, iş yükü depolama planlamasının yalnızca veritabanı boyutuna değil, gözlemlenen veya tahmini iş yükü davranışına dayalı olması gerekir. Örneğin:
- Yüksek eşzamanlılık OLTP sistemi daha fazla IOPS ve daha düşük gecikme süresine ihtiyaç duyabilir.
- Yoğun raporlamaya sahip bir sistem daha fazla aktarım hızına ihtiyaç duyabilir.
- Hibrit bir sistemin özellikle yoğun döngüler sırasında her ikisi de gerekebilir.
- Yüksek eşzamanlılık OLTP sistemi daha fazla IOPS ve daha düşük gecikme süresine ihtiyaç duyabilir.
- Yoğun raporlamaya sahip bir sistem daha fazla aktarım hızına ihtiyaç duyabilir.
- Hibrit bir sistemin özellikle yoğun döngüler sırasında her ikisi de gerekebilir.
Dağıtım seçenekleriniz depolama performansını doğrudan etkiler
Sık karşılaşılan bir hata, seçtiğiniz işlem SKU'sunun aynı performans düzeylerini kullanıp kullanamayacağını tam olarak dikkate almadan depolama alanınızı hedef performans numarasına ayarlamaktır.
Azure depolama performansında dikkat edilmesi gereken birçok nokta vardır. Bu ayrıntılar şunlardır:
- İşlem özelliği kümesi (maksimum işlem IOPS'si ve aktarım hızı sınırları).
- Depolama oluşturma (SSD v1, SSD v2, Ultra Disk).
- Depolama diski boyutu (4.096 GB'ın altındaki SSD v1 diskleri, standart taban çizgilerinin üzerinde IOPS serileri sağlayan ana bilgisayar önbelleğini içerir).
- Depolama IOPS kapasitesi.
- Depolama veri aktarım kapasitesi.
Pratik anlamda: Etkili performans tavanınız zincirdeki ilgili en düşük sınırınızdır.
Depolama yapılandırması 80.000 IOPS sağlayabilirse ancak işlem SKU'su yalnızca 20.000 IOPS'yi yönlendirebiliyorsa dağıtım 80.000 IOPS sağlamaz. Buna karşılık, VM nesli yüksek IOPS'yi destekliyorsa ancak seçilen depolama katmanı daha düşük bir seviyede sınırlandırılmışsa, depolama katmanı sınırlayıcı hale gelir.
İşlem ve depolama planlaması birlikte gerçekleşmelidir.
Premium SSD v1: önemli önbelleğe alma davranışıyla güçlü temel performans
Premium SSD v1, öngörülebilir, sağlanan performans gerektiren Postgres iş yükleri Azure üretim için yaygın bir seçimdir. Azure Postgres SSD v1 depolama 32 TB alanı, 20.000 IOPS ve 900 MB/sn aktarım hızını destekler.
Premium SSD v1, konak önbelleğinden yararlanan iş yükleri için iyi çalışır. Azure Postgres, 4.096 GB'ten küçük SSD v1 disk boyutları için konak önbelleğe almayı destekler. 4.095 GB'a kadar sağlanan tüm diskler konak önbelleğinden yararlanabilir. Depolama 4.096 GB veya daha yüksek olarak sağlandığında, konak önbellekleme desteklenmez. Bu sınır önemli. 4 TB'ın altındaki Premium SSD v1 dağıtımları için önbelleğe alma okuma performansını artırabilir ve okuma gecikmesini azaltabilir. Bu önbelleğe alma, önbelleğe alma eşik değerinin altına sığan yoğun okuma veya karma iş yükleri için mükemmel maliyet-performans verimliliği sağlar.
4 TB sınırı neden önemlidir?
Premium SSD v1 dağıtımı önbelleğe alma destekli aralığın ötesine geçtiğinde performans profili değişebilir:
- Okuma işlemleri artık ana makine önbelleğinden yararlanamaz.
- Daha fazla okuma işlemi doğrudan altta yatan diskten gelir.
- Disk IOPS ve aktarım hızı limitlerine karşı okuma işlemleri sayılır.
- Gecikmeye duyarlı okuma iş yükleri farklı davranışlar görebilir.
- Daha önce verimli olan bir yapılandırma için daha fazla sağlanan IOPS, daha fazla aktarım hızı, işlem ölçeklendirme, sorgu ayarlama veya farklı bir depolama seçeneği gerekebilir.
4 TB'ın üzerinde geçmek kötü bir şey değildir, ancak bunu planlamanız gerekir.
Veritabanının 4 TB'ın ötesine geçmesini bekliyorsanız, mimari tasarımı sırasında gelecekteki durumu göz önünde bulundurun. Önbelleğe alma ile 2 TB'da iyi performans gösteren bir tasarım için önbelleğe alma olmadan 5 TB'da farklı bir performans planı gerekebilir.
Ani artışlar yük dalgalanmalarına yardımcı olur, ancak sürekli kapasitenin yerini almaz.
Azure'nin 4 TB altındaki Postgres Premium SSD v1 depolama tahsisleri, aşağıdaki gibi durumlarda yardımcı olabilecek konak önbelleğe alma dalgalanmalarını destekler:
- Başlangıç etkinliği
- Kısa toplu işler
- Trafik artışları
- Ay sonu işleme
- Geçici iş yükü artışları
Patlatma yararlı olsa da ancak dikkatli kullanın. Geçici ani artışları absorbe edebilir, ancak sürekli iş yükü talebinin temeli olmamalıdır. İş yükü genellikle taban çizgisinin üzerinde çalışıyorsa, daha yüksek bir performans katmanı sağlamak, depolama performansı ayarlarını ayarlamak, işlemi ölçeklendirmek veya iş yükü düzenini yeniden tasarlamak daha iyidir.
İyi bir planlama sorusu şudur: Bu geçici bir ani artış mı yoksa yeni normal mi?
Geçici ani artışlar patlama için iyi adaylar olabilir. Kasıtlı kapasite planlaması ile sürekli talebi ele alın.
Premium SSD v2 kapasiteyi, IOPS'yi ve aktarım hızını ayrıştırır
Premium SSD v2, disk boyutunu, IOPS'yi ve aktarım hızını birbirinden kaldırarak planlama modelini değiştirir. PostgreSQL için Azure Veri Tabanı esnek sunucu Premium SSD v2 destekler:
- 32 GB ile 64 TB kapasite.
- En fazla 80.000 IOPS.
- En fazla 1.200 MB/sn aktarım hızı.
- 1 GB artışlarla ince ayarlı kapasite ayarlamaları.
- Esnek IOPS ve aktarım hızı yapılandırması.
- Premium SSD v1'den daha düşük gecikme süresi.
- Ana bilgisayar önbelleğe alma yok.
Bu değişiklik önemli bir değişikliktir. Premium SSD v1 ile performans, disk boyutuna daha sıkı bir şekilde bağlanmış olur. Premium SSD v2 ile performansı doğrudan iş yükü gereksinimine göre yapılandırabilirsiniz.
Örneğin yoğun işlem içeren bir veritabanı, büyük miktarda depolama alanına gerek kalmadan yüksek IOPS'ye ihtiyaç duyabilir. Azure Postgres ek ücret ödemeden temel IOPS ve aktarım hızı sağlar ve ek ücret karşılığında ek IOPS ve aktarım hızı sağlar. Premium SSD v2 teklifleri:
- 399 GB'a kadar olan diskler 3.000 IOPS ve 125 MB/sn taban çizgisi alır.
- 400 GB veya daha büyük diskler 12.000 IOPS ve 500 MB/sn taban çizgisi alır.
- Diskler en az 160 GB kullanılabilir alana boyutlandırıldığında 80.000 IOPS'ye kadar ulaşabilir.
- Aktarım hızı 1.200 MB/sn'ye kadar ölçeklendirilebilir.
Premium SSD v2 genellikle maliyet ve performans üzerinde daha hassas bir denetime ihtiyacınız olduğunda caziptir. Depolama kapasitesini yalnızca performansın kilidini açmak için ölçeklendirmek yerine, performansı daha bilinçli bir şekilde sağlayabilirsiniz.
Ultra Disk (Önizleme): üst düzey Azure disk performans sınıfı
Ultra Disk en yüksek performanslı disk seçeneğidir. Azure Ultra Disk aşağıdakilere kadar performans düzeyleri sunar:
- 400.000 IOPS
- 10.000 MB/sn aktarım hızı
- 64 TB kapasite
- Milisaniyenin altında gecikme süresi tasarım hedefleri
- Bağımsız olarak yapılandırılabilir kapasite, IOPS ve aktarım hızı
Ultra Disk depolama, en üst seviye veritabanları, SAP HANA ve işlem yoğunluklu sistemler için GÇ yoğunluklu iş yüklerini güçlendirecek şekilde tasarlanmıştır. Bu yeni depolama teklifi, görev açısından kritik iş yükleriniz için en üst düzey performans sağlar. Ancak ekibinizin dağıtım planlarken bazı önemli dağıtım özelliklerini, bölgesel kullanılabilirlik kısıtlamalarını ve yapılandırma seçeneklerini göz önünde bulundurması gerekir:
- Ultra Disk kullanan sunucular için depolama otomatik büyütme desteklenmez
- Müşteri tarafından yönetilen anahtarlarla veri şifreleme, Ultra Disk'e sahip sunucular için desteklenmez
- Ultra Diskler disk önbelleğe almayı desteklemez
Daha geniş Azure depolama performansı ortamının bir parçası olarak Ultra Disk özelliklerini anlamak önemlidir. Ancak, belirli Azure Postgres iş yükünüz için hizmet kullanılabilirliğini ve desteğini doğrulamanız gerekir. Azure Postgres dağıtımınız için Ultra Disk Önizlemesi'nin kullanılabilir olup olmadığını Microsoft temsilcinize danışın.
Pratik çözüm: Ultra Disk, Azure depolama performansının üst ucunu temsil eder, ancak uçtan uca Postgres tasarımınız seçili işlem SKU'su, bölgesi ve yayın düzeyi için benzer şekilde desteklenen birleşimler içermelidir.
VM oluşturma önemlidir: V5 ve V6 işlem depolama tavanları farklıdır
İşlem oluşturma, depolama performansını önemli ölçüde etkileyebilir. Azure depolama performansının en yüksek ucunu keşfederken, "büyük işlem"in otomatik olarak "maksimum depolama" anlamına geldiğini yanlış anlamaktan kaçının. Seçili işlem SKU'sunu hedeflenen depolama katmanına göre doğrulamanız gerekir. Şimdi, benzer boyuttaki iki işlem neslini, Ddsv5 ve Ddsv6, göz önünde bulundurarak bu noktayı gösterelim:
Ddsv5 serisi VM ailesi düzeyinde Premium Depolama (önbelleğe alma ile), Premium SSD v2 ve Ultra Disk'i destekler. Ancak, VM'nin toplam uzak depolama sınırları yine de bu VM'nin neleri kullanabileceğine ilişkin tavanı tanımlar.
Ddsv5-series, 80.000 IOPS ve 2.600 MB/sn'ye kadar depolama performansı sağlar.
Ddsv6-serisi, 400.000 IOPS ve 12.000MB/sn'ye kadar daha yüksek bir depolama zarfı sağlar. V6 serisi işlem ayrıca 192 vCPU ve 768 GiB belleğe kadar önceki nesillere göre daha yüksek ölçeklenebilirlik sunar.
Bu nesil değişikliği, yüksek performanslı Postgres tasarımı için önemlidir. Hedef mimariniz yüksek depolama performansı gerektiriyorsa, daha düşük bir toplama depolama tavanı ile işlem oluşturmanın seçilmesi dağıtımın tam depolama özelliğini kullanmasını engelleyebilir.
Örnek: Uçtan uca hizalama neden önemlidir?
400.000 IOPS depolama hedefi olan bir PostgreSQL iş yükü düşünün.
Azure Ultra Disk, disk katmanında disk başına en fazla 400.000 IOPS'yi destekler. Premium SSD v2, disk başına en fazla 80.000 IOPS'yi destekler ve daha yüksek toplama tasarımları, hizmet desteğine bağlı olarak birden çok disk veya platform düzeyinde soyutlama gerektirebilir.
Ancak depolama özelliği tek başına yeterli değildir.
V5 serisi yapılandırmanın hedeften daha düşük bir depolama tavanı olabilir. Daha önce belirtildiği gibi V5 serisi SKU'lar Premium SSD uzak disk aktarım hızı için 260.000'e kadar IOPS'yi destekler. Bu durumda, bu hedef için V5 serisi işlem katmanını seçmek, 400.000 IOPS hedeflerine ulaşılana kadar sınırlayıcı faktör haline gelir.
Buna karşılık Ddsv6 serisi belgeler 400.000 IOPS ve 12.000 MB/sn'ye kadar sunar. Bu, işlem ve depolamayı en yüksek depolama performansı sınıfları etrafında hizalaması gereken tasarımlar için V6 serisi ve yeni nesilleri stratejik olarak önemli hale getirir.
Ders basittir: En yüksek veritabanı performansı yalnızca depolama özelliği değil uçtan uca bir özelliktir.
Yalnızca kararlı durumu değil, aynı zamanda iş döngülerini de planlayın.
Birçok sistemde tek bir performans profili yoktur. Bunların birkaçı vardır:
| Normal hafta içi trafik. | Yoğun iş saatleri. |
| Ay sonu veya çeyrek sonu işleme. | Tatil veya mevsimsel talep. |
| Ürün lansman etkinlikleri. | Raporlama pencereleri. |
| Bakım pencereleri. | Azure Batch veri alma dönemleri. |
| Yedekleme ve geri yükleme senaryoları. | Felaket kurtarma durumları. |
Ortalama kullanım için boyutlandırılmış bir veritabanı, en önemli anlarda zorlanabilir. Buna karşılık, ayda bir kez zirve için kalıcı olarak boyutlandırılmış bir veritabanı gereksiz pahalı olabilir.
Azure esnekliği, ekiplerin daha ayrıntılı seçimler yapmasına olanak tanır. Örneğin:
- İş yükü gereksinimleri geliştikçe IOPS ve aktarım hızını ayarlamak için Premium SSD v2 kullanın.
- Okumaya yoğun iş yüklerini uygun yerlerde aktarmak için okuma replikalarını kullanın.
- Bilinen yoğun dönemler için işlemi ölçeklendirin.
- Altyapıyı ölçeklendirmeden önce sorguları, dizinleri ve bağlantı havuzunu ayarlayın.
- Performans sorununun CPU, bellek, IOPS, aktarım hızı, kilit çekişmesi, bağlantı baskısı veya sorgu tasarımı olup olmadığını belirlemek için gözlemlenebilirliği kullanın.
En iyi dağıtım her zaman en büyük dağıtım değildir. İş yüküyle eşleşen ve güvenli bir şekilde gelişebilen tasarımdır.
Gözlemlenebilirlik mimarinin bir parçasıdır
Performans planlaması dağıtım sırasında durmamalıdır. Postgres iş yükleri zaman içinde değişir. Veriler büyür, sorgu desenleri kayar, yeni özellikler başlatılır, müşteri trafiği değişiklikleri ve operasyonel işler birikir.
| İzleme alanı | Gözden geçirilmesi gereken sinyaller |
|---|---|
| Compute | CPU kullanımı ve bellek baskısı. |
| Bağlantılar | Etkin bağlantılar, boşta bağlantılar ve bağlantı havuzu davranışı. |
| Queries | Sorgu süresi, sorgu planı değişiklikleri ve dizin kullanımı. |
| Storage | Depolama yüzdesi, okuma gecikmesi, yazma gecikme süresi, IOPS kullanımı ve aktarım hızı istatistikleri. |
| Maintenance | Tablo şişkinliği, dizin şişkinliği, WAL özellikleri, yedekleme zamanlamaları ve bakım zamanlamaları. |
| Replication | Çoğaltma gecikmesi, uygun olduğunda. |
PostgreSQL için Azure Veri Tabanı belgelerde depolama sınırı, depolama yüzdesi, kullanılan depolama alanı ve G/Ç yüzdesi gibi Azure portal veya Azure CLI ölçümleri aracılığıyla G/Ç tüketiminin izlenmesi vurgulanır.
Bu ölçümler, en önemli operasyonel soruyu yanıtlamaya yardımcı olur: Performansı sınırlayan katman hangisidir?
Gözlemlenebilirlik olmadan ekipler yanlış şeyi ölçeklendirebilir. Sorgu planı sorunu depolama sorunu gibi görünebilir. Bağlantı fırtınaları CPU baskısı gibi görünebilir. Eksik bir dizin yetersiz IOPS gibi görünebilir. Bölgesel istemci yerleştirme sorunu veritabanı gecikme süresi gibi görünebilir.
İzleme, ekiplerin pahalı tahminler yerine hedeflenen değişiklikler yapmasına yardımcı olur.
Pratik planlama denetim listesi
PostgreSQL için Üretim Azure Veritabanı yapılandırmasını seçmeden önce aşağıdaki bilgileri toplayın.
| Category | Girişleri planlama |
|---|---|
| İş yükü türü | OLTP, OLAP, hibrit, raporlama, toplu, ve veri alma. |
| Okuma/yazma karışımı | Okuma, yazma, rastgele G/Ç ve sıralı G/Ç yüzdesi. |
| Mevcut performans | Temel IOPS, aktarım hızı, gecikme süresi, CPU, bellek ve bağlantılar. |
| En yüksek performans | 90. yüzdebirlik ve 99. yüzdebirlik iş yükü gereksinimleri. |
| Veri boyutu | Geçerli boyut, beklenen büyüme, büyük nesne kullanımı ve dizin büyümesi. |
| Büyüme oranı | Aydan aya ve yıldan yıla depolama projeksiyonları. |
| Concurrency | Etkin oturumlar, boşta oturumlar ve bağlantı havuzu davranışı. |
| İş döngüleri | Günlük, haftalık, aylık, mevsimsel ve fırlatma odaklı zirveler. |
| Availability | Yüksek kullanılabilirlik, çoğaltmalar, yedekleme, geri yükleme, olağanüstü durum kurtarma, kurtarma noktası hedefi (RPO) ve kurtarma süresi hedefi (RTO). |
| Depolama seçeneği | Premium SSD, Premium SSD v2, desteklenen bölgeler ve desteklenen özellikler. |
| Önbelleğe alma etkisi | Premium SSD v1 ana bilgisayar önbelleğinin 4 TB'ın altında uygulanıp uygulanmadığı. |
| Hesaplama Üretimi | Seçilen SKU'nun gerekli IOPS ve aktarım hızını kullanıp kullanamayacağı. |
| Ölçeklendirme modeli | El ile ölçeklendirme, zamanlanmış ölçeklendirme, performans ayarlama ve çoğaltmalar. |
| Observability | Ölçümler, uyarılar, sorgu içgörüleri ve iş yükü gözden geçirme işlemi. |
Önerilen tasarım ilkeleri
İşletimsel performans için Postgres dağıtımlarını Azure planlarken aşağıdaki ilkeleri kullanın.
-
Yalnızca veri boyutuna değil, iş yükü gereksinimlerine göre boyutlandırın.
500 GB'lık bir veritabanı yüksek işlem ve gecikme süresine duyarlıysa 5 TB'lık bir veritabanından daha fazla IOPS'ye ihtiyaç duyabilir. Boyut önemlidir, ancak iş yükü davranışı daha önemlidir. -
İşlem ve depolamayı birlikte doğrulayın.
Depolamayı yalnızca disk sınırlarına göre seçmeyin. Seçilen işlem SKU'sunun gerekli IOPS ve aktarım hızını yönlendirebileceğini onaylayın. -
4 TB Premium SSD önbelleğe alma sınırını bir tasarım kilometre taşı olarak değerlendirin.
4 TB'ın altındaki Premium SSD dağıtımları konak önbelleğinden yararlanabilir. 4.096 GB ve üzerinde konak önbelleğe alma desteklenmez. Büyüme bu eşiği aşacaksa gelecekteki performans modelini erken planlayın. -
Esnek performans ayarlaması için Premium SSD v2'ye göz atın.
Premium SSD v2, kapasite, IOPS ve aktarım hızı için daha ayrıntılı denetim sağlar. Performans gereksinimleri sabit disk boyutlarıyla düzgün bir şekilde eşlenmiyorsa bu güçlü bir uyum olabilir. -
Sürekli talep için değil, ani talepler için patlamaları kullanın.
Patlamalar, kısa süreli ani artışlarla başa çıkmada yardımcı olabilir, ancak sık veya sürekli patlamalar genellikle temel yapılandırmanın yeniden gözden geçirilmesi gerektiği anlamına gelir. -
Nesli hırsla eşleştir.
Üst düzey performans hedefleri için, v6 serisi gibi daha yeni işlem nesilleri, önceki genel amaçlı nesillere göre daha yüksek toplu uzak depolama sınırları ortaya çıkarabilir. Hedef 400.000 IOPS sınıfı bir mimariyse, işlem neslini uygun şekilde seçin. -
Değişikliklerden önce ve sonra ölçün.
Bulutta ölçeklendirme daha kolaydır, ancak ölçeklendirmeyi etkili hale getiren ölçümdür. Performans kararlarının kanıt tabanlı olması için temel, en yüksek ve değişiklik sonrası ölçümleri yakalayın.
Gerçek dünya karşılaştırması: Yük altındaki depolama yapılandırmalarını karşılaştırma
Bu makalede özetlenen ilkeler teorik değildir. İşlem, depolama ve iş yükünün uygulamada nasıl etkileşimde bulunduğunu göstermek için bu bölümde, denetlenen, ölçülen koşullar altında depolama yapılandırmalarını ve işlem katmanlarını karşılaştıran karşılaştırmalar özetlenmiştir pgbench .
Karşılaştırma kurulumu ve metodolojisi
Karşılaştırmalar, beş farklı depolama ve işlem yapılandırmasında işlem iş yükünün benzetimini yapmak için standart PostgreSQL karşılaştırma aracını kullanır pgbench. Test, 500 eşzamanlı bağlantıyla başlar ve ilk dönemden sonra 750 eşzamanlı bağlantıya kadar çıkar ve test penceresinin geri kalanında bu yükseltilmiş bağlantı yükünü korur. Bu artış düzeni, trafik arttıkça zaman içinde kaç gerçek uygulamanın yükü artıracağının benzetimini oluşturur ve veritabanının hem ilk ani artışa hem de sürekli yüksek eşzamanlılığa nasıl yanıt verdiğini ölçer.
Tüm kıyaslamalar aynı bölgedeki PostgreSQL için Azure Veri Tabanı Esnek Sunucuda, aynı kullanılabilirlik alanında, aynı test veritabanı ve iş yükü profili kullanılarak çalıştırılır. Depolamayı ve işlemi değişkenler olarak yalıtarak, performans farklılıklarının ağ, uygulama veya iş yükü varyasyonu yerine gerçek platform özelliklerini yansıtmasını sağlarsınız.
Yapılandırma ayrıntıları
Temel planlama kavramlarını göstermek için hem depolama katmanını hem de işlem boyutunu değiştirerek beş ayrı yapılandırmayı test edin.
| Configuration | Hesaplama SKU'su | vCores | Memory | En fazla işlem IOPS'si | Depolama türü | Capacity | IOPS | Aktarım hızı |
|---|---|---|---|---|---|---|---|---|
| Yapılandırma 1 | Standard_D16ds_v5 | 16 | 64GB | 25.600 (40.000 patlama) | Premium SSD (P50) | 4.095 GB | 7,500 | 250 MB/sn |
| Yapılandırma 2 | Standard_D16ds_v5 | 16 | 64GB | 25.600 (40.000 patlama) | Premium SSD (P50) | 4.096 GB | 7,500 | 250 MB/sn |
| Yapılandırma 3 | Standard_D16ds_v5 | 16 | 64GB | 25.600 (40.000 patlama) | Premium SSD (P80) | 32 Terabayt (TB) | 20,000 | 900 MB/sn |
| Yapılandırma 4 | Standard_D16ds_v5 | 16 | 64GB | 25.600 (40.000 patlama) | Premium SSD v2 | 4.095 GB | 40,000 | 1.200 MB/sn |
| Yapılandırma 5 | Standard_D32ds_v5 | 32 | 128 GB | 51.200 | Premium SSD v2 | 4.095 GB | 60,000 | 1.200 MB/sn |
Yapılandırma tasarımından temel gözlemler:
- Yapılandırma 1 ile Yapılandırma 2: Bu yapılandırmalar yalnızca depolama boyutu bakımından 4.095 GB ile 4.096 GB arasında farklılık gösterir. Bu karşılaştırma, Premium SSD v1 diskleri için ana bilgisayar önbelleğe alma sınırını test eder.
- Yapılandırma 2 ile Yapılandırma 3 karşılaştırması: Her iki yapılandırma da SSD v1 kullanır, ancak Config 3, daha yüksek IOPS ve aktarım hızının kilidini açmak için 32 TB kapasiteye ölçeklendirilir.
- Yapılandırma 3 ile Yapılandırma 4 karşılaştırması: Her iki yapılandırma da aynı işlem kullanır, ancak Config 4 premium SSD v2 esnek IOPS ve aktarım hızını kapasiteden bağımsız olarak gösterir.
- Yapılandırma 4 ile Yapılandırma 5 karşılaştırması: Yapılandırma 5, daha yüksek katmanlı işlemlerin daha fazla depolama performansı alanının kilidini nasıl açduğunu göstermek için işlem SKU'sunu ikiye katlar.
Performans sonuçları
Yapılandırma 1: Konak önbelleğe alma ile 4.095 GB Premium SSD v1
Yapılandırma 1, 4,095 GB Premium SSD v1 boyutunu kullanır ve bu boyut Premium SSD v1'de host önbelleğinden yararlanır. İş yükü sırasında bu yapılandırma şu şekilde devam etti:
- Maksimum IOPS: 24.773, Premium SSD v1 üzerinde sağlanan 7.500 IOPS ile sınırlandırılır ve önbelleğe alma, etkin performansı artırır.
- En fazla okuma IOPS'si: 21.330, yoğun okuma işlemleri için konak önbelleğinden yararlanır.
- Maksimum yazma IOPS: 7.610.
Ana makinada önbellekleme, okuma amplifikasyonu sağlar, bu nedenle etkin IOPS, diskin sağlanan 7.500 IOPS sınırını kısa süreliğine aşarak işlem depolama sınırlarına ulaşabilir.
Yapılandırma 2: Ana bilgisayar önbelleklemesi olmadan 4.096 GB Premium SSD v1
Yapılandırma 2, 4.096 GB Premium SSD v1 boyutunu kullanarak önbelleğe alma sınırını aşıyor ve konak önbelleğe alma avantajlarını kaybediyor. Etki görünür:
- En Fazla IOPS: Önbellek kaybı nedeniyle Konfigürasyon 1'e kıyasla daha düşük etkili IOPS.
- En fazla okuma IOPS'i: Konak önbelleği olmadan önemli ölçüde azaltıldı.
- Maksimum yazma IOPS: 7.610, değişmedi.
Bu yapılandırma, 4 TB önbelleğe alma sınırının pratik önemini gösterir. 4.095 GB'tan 4.096 GB'a geçmek, önbelleğe alınmış okumaları kaldırarak performans profilini değiştirir. Bu eşiğe yaklaşan büyüyen veritabanları için önceden plan yapın.
Yapılandırma 3: Daha yüksek IOPS ile 32 TB Premium SSD v1
Yapılandırma 3, 32 TB kapasiteye ölçeklendirilerek Premium SSD v1 üst IOPS ve aktarım hızı sınırlarını giderir. Bu yapılandırmaya ulaşıldı:
- Maksimum IOPS: 20.000.
- En fazla okuma IOPS'i: Yaklaşık 12.000.
- En fazla yazma IOPS'i: Yaklaşık 5.000.
Temel premium SSD v1 depolama kapasitesini artırmak IOPS ve aktarım hızını artırır. Yoğun iş yükleri için işlem depolama aralığının üst sınırlarına yine de ulaşabilirsiniz.
Yapılandırma 4: 40.000 IOPS ile Premium SSD v2
Yapılandırma 4, 4.095 GB kapasitede 40.000 IOPS ve 1.200 MB/sn aktarım hızı sağlayarak Premium SSD v2 esnek performans yapılandırmasını gösterir:
- En Fazla IOPS: Premium SSD v2'nin gecikme ve aktarım hızı özellikleri nedeniyle daha yüksek etkin kullanım.
- En fazla okuma IOPS'i: Premium SSD v1 yapılandırmalarına göre geliştirilmiş performans.
- En fazla yazma IOPS'i: Daha yüksek sürdürülebilir yazma kapasitesi.
Premium SSD v2, büyük depolama kapasitesi gerektirmeden yüksek IOPS sağlanmasına olanak sağlayarak yoğun işlem gerektiren iş yükleri için verimli hale getirir.
Yapılandırma 5: D32ds_v5 işlemde 60.000 IOPS ile Premium SSD v2
Yapılandırma 5, hem 60.000 IOPS depolama performansını hem de işlem gücünü, Standard_D32ds_v5 ve 32 vCore ile ölçeklendirir. Bu yapılandırma uçtan uca hizalama ilkesini gösterir:
- En Fazla IOPS: Önceki tüm yapılandırmalardan önemli ölçüde daha yüksek.
- En fazla okuma IOPS değeri: Ekstra işlem kapasitesi ile performansta güçlü bir iyileşme.
- En fazla yazma IOPS'i: Daha yüksek yazma kapasitesine sahiptir.
Bu yapılandırma, hem işlem hem de depolamayı daha yüksek performans katmanlarına hizalayarak en iyi aktarım hızına ve en düşük CPU baskısına ulaşır. D32ds_v5 yüksek depolama tavanı, 60.000-IOPS Premium SSD v2 diskinin daha tam olarak kullanılmasını sağlar.
Kıyaslamalardan alınan dersler
Bu beş yapılandırma, bu makaledeki temel ilkeleri gösterir:
-
4 TB önbelleğe alma sınırı önemlidir.
Yapılandırma 1 ile Config 2 karşılaştırması, ana bilgisayar önbelleğinin 4 TB'ın altında ölçülebilir okuma performansı amplifikasyonu sağladığını gösterirken, 4.096 GB'a geçmek bu avantajı kaldırır. -
Kapasite performans değildir.
Yapılandırma 3, 32 TB sağladı ancak en yüksek IOPS'yi sunmadı. Yalnızca depolama kapasitesi işlem aktarım hızını belirlemez. -
Premium SSD v2 esnek performans ayarlaması sağlar.
Dördüncü yapılandırma, Premium SSD v2'nin etkinleştirdiği ayrık modeli doğrulayarak mütevazı kapasitede yüksek IOPS gösterdi. -
İşlem ve depolama hizalanmalıdır.
Beş numaralı yapılandırma, depolama performansını en üst düzeye çıkarmak için yeterli hesaplama kapasitesine ihtiyaç duyulduğunu gösterir. 60.000 IOPS kapasitesinden daha fazla yararlanmak için D32ds_v5 yüksek depolama tavanına ihtiyaç vardı.
Karşılaştırma sonuçları temel ilkeyi doğrular: maksimum performans uçtan uca bir özelliktir. Sonucu depolama, işlem veya ağ gibi tek bir katman belirlemez. Başarı, iş yükleri geliştikçe tüm katmanlar arasında kasıtlı hizalama, ölçülen doğrulama ve sürekli gözlem gerektirir.
Sonuç
Azure Postgres, modern, bulutta barındırılan veritabanı çözümleri oluşturmak için güçlü ve esnek bir platform sağlar. Azure İşlem, depolama, ağ, yüksek kullanılabilirlik, çoğaltma, güvenlik ve gözlemlenebilirlik genelindeki mühendislik, kullanılabilir en yüksek performanslı ve dayanıklı Postgres mimarilerinden bazılarını etkinleştirir.
Maksimum performans yanlışlıkla gerçekleşmez.
Maksimum işlem performansı, uygulamayı, istemcileri, iş yükünü, veri büyüme profilini, okuma/yazma karışımını ve talebi şekillendiren iş döngülerini anlamanızı gerektirir. Ayrıca IOPS, aktarım hızı ve gecikme süresi hedeflerine uçtan uca ulaşılması için hem işlem hem de depolama seçeneklerinin hizalanması gerekir.
Premium SSD v1, özellikle konak önbelleğe alma 4 TB sınırı altındaki verilere uygulandığında güçlü tahmin edilebilir performans sağlayabilir. Premium SSD v2, kapasite, IOPS ve aktarım hızını ayrıştırarak daha esnek performans yapılandırması ekler. Ultra Disk, en yüksek Azure yönetilen disk performans sınıfını temsil ederken, daha yeni işlem nesilleri üst düzey mimariler için önemli ölçüde daha yüksek toplu uzak depolama tavanları sağlar.
En iyi Azure Postgres dağıtımları, platform özelliğini kasıtlı planlama, sürekli izleme ve net operasyonel sahiplik ile birleştirir. Doğru gereksinimler ve doğru mimari sayesinde ekipler en yüksek performansı sağlayan birinci sınıf Postgres deneyimleri sunabilir.
İlgili içerik
- Azure Premium Depolama: yüksek performanslı tasarım
- Azure disk patlama
- Ddv5 ve Ddsv5 serisi VM boyutları
- Ddsv6 serisi VM boyutları
- PostgreSQL için Azure Veri Tabanı'de Premium SSD depolama seçeneği
- PostgreSQL için Azure Veri Tabanı'de Premium SSD v2 depolama seçeneği
- Azure yönetilen disk türleri
- PostgreSQL için Azure Veritabanı'nda ölçümleri izleme