DynamoDB On-Demand ve 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 fiyattan ayırır. Yanlışını 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. Bu trafik şekli kararın tamamıdır.

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

On-Demand istek başına ücret alır ve sıfıra ölçeklenir, bu da onu ani, yeni ya da öngörülemez trafik için güvenli varsayılan yapar. Provisioned, sabit bir okuma/yazma oranını çok daha düşük bir birim fiyattan ayırır ve yalnızca sürekli, istikrarlı trafik o rezervasyonu iyi kullanılır tuttuğunda kazanır. Hacminiz kanıtlanmış ve öngörülebilir olmadıkça On-Demand'i seçin.

• On-Demand = istek başına öde, sıfıra ölçeklen. Planlanacak kapasite yok; okuma/yazma başına daha yüksek bir fiyat ödersiniz ama yalnızca trafik olduğunda.
• Provisioned = istikrarlı bir oran ayır, her zaman öde. Oran iyi kullanılırsa birim başına çok daha ucuz; boşta kalan kapasitenin maliyetini yüklenirsiniz.
• Ani ya da bilinmeyen trafik On-Demand gerektirir. İstikrarlı, öngörülebilir, yüksek hacimli trafik Provisioned gerektirir (isteğe bağlı olarak otomatik ölçekleme ile).
• Modları değiştirebilirsiniz, ama sınır asimetriktir: Provisioned'dan On-Demand'e geçiş 24 saatte dört kez ile sınırlıdır, On-Demand'den Provisioned'a geçiş ise sınırsızdır — bu bir istek başına düğme değildir.

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

Provisioned kapasite ile, diyelim ki saniyede 1.000 yazma birimi taahhüt edersiniz. Denetim günlüğü ortalama saniyede 50 yazma yapıyorsa ama olay günü zirvesi için provizyon aldıysanız, gün boyu 1.000 için ödeme yaparsınız ve bunun yirmide birini kullanırsınız. Bunun yerine ortalamaya göre provizyon alın, olay günü seli kısıtlanır — yazmalar reddedilir.

Yani sabit kapasite, ani trafikte kötü bir seçim dayatır: sürekli fazla ödeyin ya da az provizyon alıp en önemli anda yazmaları düşürün. On-Demand tam da bu seçimi 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 yoktur — önceki trafik zirvenizin iki katına kadar olan ani artışları anında karşılar ve boştayken sıfıra ölçeklenir. Kısa bir pencere içinde o 2x sıçramanın ötesinde, hızlanırken yine de kısıtlama yapabilir. O esneklik için istek başına bir prim ödersiniz.

Provisioned, saniyede belirli sayıda Read Capacity Units (RCU) ve Write Capacity Units (WCU) ayırır. Birim başına fiyat çok daha düşüktür, ama kullanılsın kullanılmasın rezervasyon için sürekli ödersiniz. Aşarsanız ve otomatik ölçekleme yapılandırılmış sınırlar içinde kapasiteyi büyütmek için etkin değilse DynamoDB kısıtlama yapar — gerçi otomatik ölçekleme dakikalar içinde tepki verir, bu yüzden ani bir artış yetişmeden önce yine de kısıtlanabilir.

Kesişme noktası kullanımdır. Kabaca: sürekli, öngörülebilir trafiğiniz Provisioned kapasiteyi iyi kullanılır tutuyorsa, Provisioned fiyatta kazanır; trafik ani, patlamalı ya da bilinmiyorsa, On-Demand boşta rezervasyon için ücret almayarak kazanır.

İşlenmiş bir örnek: denetim günlüğünün faturası

Denetim günlüğü ortalama saniyede ~50 olay yazar ama olaylar sırasında binlere kadar patlar, okuma trafiği ise çok daha düşüktür (uyumluluk dışa aktarımları, ara sıra bir soruşturma). Her olay küçüktür — 1 KB'ın epey altında.

Provisioned'da, patlama için rezervasyon yapmak (ve 7/24 ödemek) ya da olay günü selini kısıtlama riskine girmek — denetim yazmalarını düşürmek için en kötü zaman — zorunda kalırsınız. On-Demand'de, sessiz saatler neredeyse hiçbir şeye mal olmaz ve son zirvenin iki katına kadar bir patlama yapılandırma olmadan emilir; tam olarak gerçekleşen yazmalar için ödersiniz.

Bu iş yükü için On-Demand doğru varsayılandır. Genel kural: her yeni ya da ani tabloda On-Demand'de başlayın ve yalnızca trafik bir rezervasyonu kullanılır tutacak kadar istikrarlı olduğu kanıtlandığında Provisioned'a geçin.

Kendi rakamlarınızı girin — saniye başına okuma/yazma, item boyutu, depolama — ve iki modu tek bir bölge için yan yana görün:

Free tier uygulanmış tam çok bölgeli görüntü için, DynamoDB Fiyatlandırma Hesaplayıcısını kullanın.

Bunu DynoTable'da yapın

Kapasite kararı gerçek rakamlardan başlar: item'lar ne kadar büyük, kaç tane var, ne kadar hızlı yazılıyorlar. Bunları tahmin etmek, tabloların yanlış provizyonlanmasının yoludur.

Örnek bir olayı gerçekte tükettiği RCU/WCU'ya çevirmek için onu item boyutu hesaplayıcısından geçirin. Ardından kararı gerçek tablonuza dayandırın: DynoTable metadata'sını — item sayısı ve boyutu — öne çıkarır ve temsili item'ları incelemenize izin verir, böylece onları doğru boyutlandırabilirsiniz.

Tuzaklar ve sonraki adımlar

• Mod değiştirme oran sınırlıdır ve asimetriktir. Provisioned'dan On-Demand'e geçiş 24 saatte dört değişiklikle sınırlıdır; On-Demand'den Provisioned'a geçiş sınırsızdır. Bunu döndürdüğünüz bir kadran değil, üzerinde düşünülmüş bir karar olarak ele alın.
• Otomatik ölçekleme anında değildir. Dakikalar içinde tepki verir, bu yüzden Provisioned'da keskin bir ani artış, kapasite büyümeden önce kısıtlayabilir. Gerçekten patlamalı trafik için, On-Demand ani artışı daha iyi karşılar — önceki zirvenizin iki katına kadar anında. Bir ani artışın bunu aşacağını biliyorsanız (bir lansman ya da satış), patlama için baş odayı önceden provizyonlamak üzere tabloda warm throughput ayarlayın.
• Sıcak bir partition, moddan bağımsız olarak kısıtlar. On-Demand'in bile partition başına limitleri vardır — dengesiz anahtarlar, tablo kapasitesinin altında görünürken kısıtlayabilir. Bkz. sıcak partition'lar.
• GSI'lerin kendi kapasitesi vardır. Her index ayrı faturalandırılır ve az provizyonlanmışsa temel tablo yazmalarını kısıtlayabilir — bkz. bir GSI temel tablo yazmalarını neden kısıtlar.

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

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