DynamoDB ile Redshift

DynamoDB ve Amazon Redshift nadiren alternatiftir. DynamoDB operasyonel bir veritabanıdır — bilinen anahtarlara karşı tek haneli milisaniyelik okuma ve yazmalar, canlı uygulama trafiğine hizmet eder. Redshift ise "a fully managed, petabyte-scale data warehouse service in the cloud;" büyük veri kümelerini tarama ve toplama için raporlama ve analitik amacıyla inşa edilmiştir. İkisini birden çalıştıran ekipler normaldir ve AWS aralarında tek yönlü veri taşımak için yönetilen bir entegrasyon sunar.

DynamoDB mi Redshift mi kullanmalısınız?

Uygulamanın canlı verisi için DynamoDB'yi kullanın: verilen siparişler, okunan oturumlar, anahtarla getirilen kayıtlar. Birinin tüm veri kümesi genelinde soru sorması gerektiğinde — bölge ve aya göre gelir, kohort elde tutma, birkaç kaynağı birleştiren bir pano — Redshift'i kullanın. "Hangisi" sorusu genellikle "yazma yolu için DynamoDB, analistler için Redshift, arada zero-ETL entegrasyonu" şeklinde çözülür.

Bir bakışta DynamoDB ile Redshift

Özellik	DynamoDB	Redshift
İş yükü	Operasyonel (OLTP tarzı) — anahtarla yüksek hacimli okuma ve yazma	Analitik — büyük veri kümeleri üzerinde tarama ve toplamalar
Veri modeli	Şemasız NoSQL öğeleri 400 KB'ye kadar; öznitelikler öğe başına değişir	Dağıtım anahtarları ve sıralama anahtarları olan ilişkisel tablolar, bildirilmiş sütunlarla
Sorgu dili	Yerel API (`GetItem`, `Query`, `Scan`, …) artı PartiQL	Tam SQL; bunun getirdiği BI ve SQL araçlarıyla
Join'ler ve toplamalar	Sunucu tarafı join yok; toplama sunucu tarafı bir işlem değil	Join'ler, pencere fonksiyonları, `GROUP BY` ve analitik SQL'in geri kalanı
Erişim deseni	Bilinen anahtarlar etrafında tasarlanmış; taramalar pahalı istisnadır	Tarama için tasarlanmış — çok satır okumak normal durumdur
Gecikme	İstek başına tek haneli milisaniye	Analitik sorgu başına saniyelerden dakikalara, çok daha fazla veri üzerinde
Ölçeklenme	Sunucusuz; bölümleri AWS yönetir	Sunucusuz çalışma grupları veya sağlanan kümeler; kapasite sorgu iş yüküne göre boyutlandırılır
Güncellik	İsteğe bağlı read-your-write	Onu ne yüklüyorsa o kadar güncel — zero-ETL entegrasyonu güncellemeleri 15–30 dakikada bir indirir
Fiyatlandırma modeli	İstek başına veya sağlanan kapasite artı depolama	Hesaplama kapasitesi artı depolama; boştaki sunucusuz ambarlar için hesaplama faturalandırılmaz

DynamoDB ne zaman daha iyi seçim

Canlı uygulama trafiği. Bilinen anahtarlara karşı öngörülebilir tek haneli milisaniyelik okuma ve yazmalar, her istek hızında.
Öğe başına değişen şema. Bir tablodaki heterojen öğeler DynamoDB'de normaldir; bir veri ambarı bildirilmiş sütunlar ister.
Sunucusuz operasyonlar. Boyutlandırılacak, yamalanacak veya duraklatılacak küme yok.
Yazı ağırlıklı yollar. DynamoDB yüksek hacimli yazmaları birincil işi olarak emer; bir ambar toplu yükleme ve okuma için optimize edilmiştir.

Redshift ne zaman daha iyi seçim

Tüm tabloyu kesen sorular. Bir yıllık siparişleri toplamak doğası gereği bir taramadır; DynamoDB'nin kaçınmanızı istediği ve Redshift'in tasarlandığı erişim desenidir.
Birçok kaynak arasında join'ler. Ambarlar join yapar. DynamoDB'nin sunucu tarafı join'i yoktur.
BI araçları. Redshift JDBC/ODBC üzerinden SQL konuşur; mevcut panolara ve "the same SQL-based tools and business intelligence applications that you use today" ifadesine oturur.
Üretimi rahatsız etmemesi gereken analiz. Analitiği çoğaltılmış bir kopya üzerinde çalıştırmak, kullanıcılarınıza hizmet veren tablodan yükü uzak tutar.

İkisini birlikte kullanmak

Standart desen tek yönlüdür: DynamoDB uygulamaya hizmet eder, bir kopya Redshift'e iner, analistler kopya üzerinde çalışır. AWS iki yol sunar — "from Amazon S3 or Amazon DynamoDB into Amazon Redshift" doğrudan yükleyen eski COPY komutu ve kopyayı kendi başına güncel tutan yönetilen zero-ETL entegrasyonu.

Zero-ETL entegrasyonu gerçekte ne yapar

"Zero-ETL" canlı bir görünümü çağrıştırır. Öyle değildir ve bir panoyu bunun etrafında tasarlamadan önce ayrıntılar önemlidir.

Zamanlayıcılı bir çoğaltma hattıdır. AWS kesindir: "On activation, the integration exports the full DynamoDB table to populate the Amazon Redshift database." Ardından "the zero-ETL integration then incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." Yani Redshift'teki veri yarım saate kadar eskidir. Günlük raporlama için uygundur; kullanıcının son eylemini yansıtması beklenen her şey için yanlıştır.

Zamanında noktaya kurtarma zorunludur — ve nedeni artık açıktır. Önkoşul açıkça belirtilir: "A zero-ETL integration between Amazon DynamoDB and Amazon Redshift requires your source DynamoDB table to have Point-in-time recovery (PITR) enabled." AWS gereksinimi bir yerde, mekanizmayı başka yerde belgeler ve ikisini bağlamaz; ancak eklemeniz gereken kaynak tabanlı ilke ipucunu verir — redshift.amazonaws.com'a dynamodb:ExportTableToPointInTime eylemini verir. Entegrasyon DynamoDB'nin S3'e dışa aktarma altyapısı üzerine kuruludur ve bu altyapı sürekli yedekten okur. PITR yoksa dışa aktarma yok, entegrasyon da yok.

Bunun geç öğrenilen bir bütçe sonucu vardır: büyük bir tabloda PITR'yi etkinleştirmek, tablo boyutu üzerinden sürekli bir ücrettir; kurtarma için değil, analitik hattı için ödenir. Entegrasyonu yalnızca Redshift değil "Redshift artı PITR" olarak fiyatlayın — taahhüt etmeden önce depolama tarafını boyutlamak için ücretsiz DynamoDB fiyatlandırma hesaplayıcısı kullanın.

Mevcut tabloları engelleyen iki kısıt. İkisi de belgelenmiş sınırlamalardır ve sonradan düzeltmek zordur:

"The DynamoDB table and Amazon Redshift cluster need to be in the same Region." Birkaç Bölgeyi birleştiren bir ambar hepsini bu yoldan çekemez.
"The source DynamoDB table must be encrypted with either an Amazon-owned or Customer-managed AWS KMS key. Amazon managed encryption is not supported for the source DynamoDB table." AWS tarafından yönetilen şifreleme altında oluşturulan tablolar, entegrasyon oluşturulmadan önce şifreleme ayarlarının değiştirilmesini gerektirir.

Veri şeklinin ısırdığı yer. DynamoDB öğeleri tasarım gereği heterojendir; ambar tablolarının sütunları vardır. Tek bir bölüm anahtarı kuralı altında birden fazla varlık türünü tutan tek tablo tasarımı, çoğaltılarak temiz bir yıldız şemasına dönüşmez. Veri indikten sonra Redshift'te modelleme işi planlayın — entegrasyon hattı kaldırır, şema tasarımını değil.

Henüz bir ambara ihtiyacınız yokken

Her toplama bir analitik problemi değildir. "Bunu Redshift'e koyalım" cümlesinin büyük bir payı tek bir soruyla başlar — bu durumda kaç öğe var, bu müşteri için toplam ne, hangi bölüm anahtarları baskın — ara sıra, bir mühendis tarafından, tek bir tabloya karşı sorulur.

DynoTable'ın SQL Workbench'i bu soru sınıfına doğrudan, isteğe bağlı olarak DynamoDB'ye karşı yanıt verir: COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING ve DISTINCT ile gerçek SQL, artı INNER/LEFT JOIN. Konumlandırma kasıtlı olarak dar — DynamoDB'nin erişim deseni kuralları içinde SQL. Tek bir SELECT'tir; CTE yok, UNION yok, pencere fonksiyonu yok ve skaler alt sorgu yok; join hedefi bir bölüm anahtarı veya bir GSI bölüm anahtarı olmalıdır. Sonuçlar kısmi rozetiyle akar ve sorgu sona erdiğinde kesinleşir; veriyi okumak yine de okumanın maliyetine mal olur.

Bu bir ambarın yerine geçmez ve yukarıdaki sınırlar dürüst sınırdır. Ancak bir çoğaltma hattından, PITR ücretinden ve bir şema tasarımından daha hızlı bir yanıttır — ve sorunun bir ambara değip değmeyeceğini, bir tane inşa etmeden önce söyler. Workbench sorgularını çalıştırmak ücretli bir özelliktir; düzenleyici ve otomatik tamamlama ücretsizdir. DynoTable kapalı kaynaklı ticari bir uygulamadır; bu sayfa ne yaptığını anlatır, nasıl inşa edildiğini değil.

SSS

Redshift, DynamoDB'nin yerini alabilir mi?

Uygulama trafiği için hayır. Redshift tarama ve toplama için inşa edilmiş bir veri ambarıdır; tek haneli milisaniyelik gecikmeyle yüksek hacimli anahtar aramalarına hizmet etmek için tasarlanmamıştır. İkisi yan yana çalışır: DynamoDB uygulamaya hizmet eder, Redshift'teki çoğaltılmış kopya analitiğe hizmet eder.

Redshift'teki DynamoDB verisi ne kadar güncel?

Zero-ETL entegrasyonuyla yaklaşık 30 dakikaya kadar eski. AWS, ilk tam dışa aktarmadan sonra "incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports" diye belgeler. Bunu neredeyse gerçek zamanlı raporlama olarak kabul edin, canlı bir görünüm olarak değil.

Zero-ETL entegrasyonu neden PITR gerektirir?

DynamoDB'nin zamanında noktaya dışa aktarması üzerine kuruludur. Entegrasyonun ihtiyaç duyduğu kaynak tabanlı ilke, Amazon Redshift'e dynamodb:ExportTableToPointInTime eylemini verir ve bu dışa aktarma PITR'nin sürdürdüğü sürekli yedekten okur. PITR'yi etkinleştirmek bu nedenle entegrasyonun gerçek, süregelen bir maliyetidir.

İlgili

DynamoDB'yi ne zaman kullanmalı'yı ve taramaların neden pahalı olduğunu öğrenin.
Operasyonel ilişkisel soru için DynamoDB ve PostgreSQL karşılaştırmasına bakın.
Erişim desenlerini baştan tek tablo tasarımı ile modelleyin.
Depolama ve kapasite tarafını ücretsiz DynamoDB fiyatlandırma hesaplayıcısı ile boyutlayın.
DynamoDB tablolarınızı doğrudan sorgulamak ve toplamak için DynoTable'ı indirin.

Kaynaklar

Son doğrulama 2026-08-02, resmi AWS Redshift Management Guide ve DynamoDB Developer Guide'a göre yapıldı.