DynamoDB On-Demand ile Provisioned Kapasite

DynamoDB throughput'u iki şekilde faturalandırır. On-Demand istek başına ücret alır — kullandığınız kadar ödersiniz, sıfıra kadar ölçeklenir. Provisioned, kullansanız da kullanmasanız da ödediğiniz sabit bir okuma/yazma oranını, çok daha düşük bir birim fiyatla rezerve eder. Yanlış olanı seçmek, fazla ödemenin en kolay yollarından biridir.

Denetim günlüğü seçimi somutlaştırır. Denetim yazmaları ani ve öngörülemezdir: gece boyunca sessiz, sonra bir müşteri toplu bir işlem çalıştırdığında ya da bir olay binlerce olay ürettiğinde bir sel. O trafik şekli kararın tamamıdır.

DynamoDB On-Demand mi yoksa Provisioned kapasite mi kullanmalıyım?

On-Demand, istek başına ücret alır ve sıfıra kadar ölçeklenir; bu nedenle ani, yeni veya öngörülemeyen trafik için güvenli varsayılandır. Provisioned, çok daha düşük birim fiyatıyla sabit bir okuma/yazma oranı rezerve eder ve yalnızca sürekli, istikrarlı trafik bu rezervasyonu iyi değerlendirdiğinde avantajlıdır. Hacminiz kanıtlanmış ve öngörülebilir değilse On-Demand'i tercih edin.

• On-Demand = istek başına ödeme, sıfıra ölçeklenir. Planlanacak kapasite yok; okuma/yazma başına daha yüksek bir fiyat ödersiniz ama yalnızca trafik olduğunda.
• Provisioned = sabit bir oran rezerve et, hep onu öde. Oran iyi kullanılırsa birim başına çok daha ucuz; atıl kapasitenin maliyetini yersiniz.
• Ani / bilinmeyen trafik → On-Demand. Sabit, öngörülebilir, yüksek hacimli trafik → Provisioned (isteğe bağlı olarak auto-scaling ile).
• Modları değiştirebilirsiniz, ama yalnızca 24 saatte sınırlı sayıda — istek başına bir anahtar değil.

Sorun: kullanmadığınız kapasite için ödemek

Provisioned kapasiteyle, diyelim ki saniyede 1.000 yazma birimine taahhütte bulunursunuz. Denetim günlüğü ortalama saniyede 50 yazma yaparsa ama olay-günü zirvesi için provision yaptıysanız, gün boyu 1.000 için ödeyip yirmide birini kullanırsınız. Bunun yerine ortalamaya göre provision yapın, olay-günü seli throttle olur — yazmalar reddedilir.

Yani sabit kapasite, ani trafikte kötü bir takas dayatır: sürekli fazla ödeyin ya da yetersiz provision yapıp en önemli anda yazmaları düşürün. On-Demand tam da bu takası ortadan kaldırmak için vardır.

İki mod nasıl çalışır

On-Demand, gerçekten tükettiğiniz okuma ve yazma istek birimleri için ücret alır, yapılandırılacak kapasite olmadan — trafik ani artışlarına anında uyum sağlar ve atılken sıfıra ölçeklenir. Bu esneklik için istek başına bir prim ödersiniz.

Provisioned, saniyede bir Read Capacity Unit (RCU) ve Write Capacity Unit (WCU) sayısı rezerve eder. Birim başına fiyat çok daha düşüktür, ama kullanılsın ya da kullanılmasın rezervasyonu sürekli ödersiniz. Onu aşarsanız, auto-scaling yapılandırılan sınırlar içinde kapasiteyi büyütmek için etkin olmadıkça DynamoDB throttle yapar — gerçi auto-scaling dakikalar boyunca tepki verir, bu yüzden ani bir artış yetişmeden önce yine de throttle olabilir.

Geçiş noktası kullanım oranıdır. Kabaca: sürekli, öngörülebilir trafiğiniz Provisioned kapasiteyi iyi kullanıyorsa Provisioned fiyatta kazanır; trafik ani, patlamalı ya da bilinmiyorsa, On-Demand atıl rezervasyon için ücret almayarak kazanır.

Çalışılmış bir örnek: denetim günlüğünün faturası

Denetim günlüğü ortalama ~50 olay/saniye yazar ama olaylar sırasında binlere fırlar, okuma trafiği çok daha düşük (uyumluluk dışa aktarımları, ara sıra bir soruşturma). Her olay küçüktür — 1 KB'nin oldukça altında.

Provisioned'da, patlama için rezerve etmeniz (onu 7/24 ödemeniz) ya da olay-günü selini throttle etme riski almanız gerekir — denetim yazmalarını düşürmenin en kötü zamanı. On-Demand'de, sessiz saatler neredeyse hiçbir şeye mal olmaz ve patlama otomatik olarak emilir; tam olarak gerçekleşen yazmaları ödersiniz.

Bu iş yükü için On-Demand doğru varsayılandır. Genel kural: yeni ya da ani herhangi bir tablo için On-Demand ile başlayın ve yalnızca trafiğin bir rezervasyonu kullanacak kadar sabit olduğu kanıtlandığında Provisioned'a geçin.

Kendi sayılarınızı girin — saniyede okuma/yazma, öğe boyutu, depolama — iki modu tek bir bölge için yan yana görmek için:

Free tier uygulanmış tam çok bölgeli tablo için DynamoDB Fiyatlandırma Hesaplayıcısı'nı kullanın.

DynoTable'da yapın

Kapasite kararı gerçek sayılardan başlar: öğeler ne kadar büyük, kaç tane var, ne kadar hızlı yazılıyorlar. Bunları tahmin etmek, tabloların yanlış-provision olmasının yoludur.

Örnek bir olayı gerçekten tükettiği RCU/WCU'ya dönüştürmek için öğe boyutu hesaplayıcısından geçirin. Sonra kararı gerçek tablonuza dayandırın: DynoTable, tablonun meta verisini — öğe sayısı ve boyutu — yüzeye çıkarır ve temsili öğeleri inceletir, böylece bunları doğru boyutlandırabilirsiniz.

Tuzaklar ve sonraki adımlar

• Mod değiştirme oran-sınırlıdır. On-Demand ile Provisioned arasında geçiş yapabilirsiniz, ama yalnızca 24 saatte sınırlı sayıda — bunu çevirdiğiniz bir kadran değil, üzerinde düşünülmüş bir karar olarak ele alın.
• Auto-scaling anlık değildir. Dakikalar boyunca tepki verir, bu yüzden Provisioned'da keskin bir artış kapasite büyümeden önce throttle olabilir. Gerçekten patlamalı trafik için On-Demand artışı doğrudan emer.
• Sıcak bir partition moddan bağımsız throttle olur. On-Demand'in bile partition başına sınırları vardır — dengesiz anahtarlar tablo kapasite altındaymış gibi görünürken throttle olabilir. Bkz. sıcak partition'lar.
• GSI'lerin kendi kapasitesi vardır. Her index ayrı faturalandırılır ve yetersiz provision yapılırsa temel-tablo yazmalarını throttle edebilir — bkz. bir GSI'nin temel-tablo yazmalarını neden throttle ettiği.

Kapasite modu, tabloyu tek bir bölgede çalıştırmak için ne ödediğinizi belirler. Sonraki: onu bölgeler arasında çoğaltmak — DynamoDB Global Tables.

Bir kapasite moduna karar vermeden önce tablonuzun gerçek boyutunu ve öğe sayısını okumak için DynoTable'ı indirin.