DynamoDB Maliyet Modeli: SQL Faturayı Neden Gizleyebilir

DynamoDB üzerinde gerçek SQL çalıştırmak güçlüdür — bunların hiçbirini yerel olarak sunmayan bir veritabanında JOIN'ler, GROUP BY ve keyfi WHERE ifadeleri elde edersiniz. Ama SQL, bir sorgu planlayıcısı ve her sütunda ikincil index'leri olan bir motor için tasarlandı; DynamoDB'nin ise ikisi de yok. Tamamen geçerli bir SELECT, tablodaki her item'ı okuyan — ve size faturalandıran — bir tam tablo Scan'ine derlenebilir.

İşte SQL soyutlamasının çift taraflı keskinliği budur: pahalı erişim desenlerini bedavaymış gibi gösterir. Bu kılavuz, kolaylığın asla sürpriz bir faturaya dönüşmemesi için altta yatan maliyet modelini açıklar ve DynoTable'ın maliyeti sorguyu çalıştırmadan önce nasıl gösterdiğini anlatır.

DynamoDB üzerinde SQL neden göründüğünden daha pahalıya mal olur?

İlişkisel bir veritabanı WHERE status = 'active' sorgusunu verimli şekilde yanıtlayabilir çünkü sorduğunuz her sütun için bir index oluşturur. DynamoDB bunu yapmaz. Tam olarak tek bir şey üzerinde verimli yanıt verir: partition key (isteğe bağlı olarak bir sort key veya bir global secondary index ile daraltılmış). Başka her şey bir Scan'dir.

• Bir partition-key eşitliği bir Query'dir. DynamoDB doğrudan o anahtarın altındaki item'lara atlar ve yalnızca onları okur. Sınırlı ve ucuz.
• Başka her şey bir Scan + Filter'dır. DynamoDB tablodaki her item'ı okur, ardından WHERE'inizi bir FilterExpression olarak — okumadan sonra — uygular. Taradığı her şey için faturalandırılırsınız, döndürülen bir avuç satır için değil.

İşte son nokta tuzaktır. Bir WHERE ifadesi işi daraltıyormuş gibi görünür. Anahtar olmayan bir attribute üzerinde yalnızca çıktıyı daraltır — okuma maliyeti çoktan harcanmıştır.

Query ve Scan: RCU matematiği

DynamoDB okumaları read capacity units (RCU) cinsinden faturalandırır:

• 1 RCU = 4 KB'a kadar bir item'ın bir güçlü tutarlı okuması. Nihai tutarlı okumalar bir birimin yarısı kadara mal olur. Okumalar her 4 KB için yukarı yuvarlanır.
• Bir Query yalnızca tek bir partition key altındaki item'ları okur — maliyet, tabloyla değil, eşleşen item'larla ölçeklenir.
• Bir Scan tüm tabloyu, her seferinde 4 KB olarak okur. 1 GB'lık bir tablo, tek bir tam geçiş için kabaca 262.000 nihai tutarlı RCU'dur — her geçiş, her seferinde.

Bir FilterExpression bu sayıyı azaltmaz. Filtreleme okumadan sonra gerçekleşir, bu yüzden filtrelenmiş bir Scan, filtrelenmemiş bir Scan ile tam olarak aynı maliyete sahiptir. Verileriniz için gerçek rakamları item boyutu hesaplayıcısı ve fiyatlandırma hesaplayıcısı ile hesaplayın.

Hangi SQL yapıları sessizce Scan'lere dönüşür?

• partition-key eşitliği olmayan WHERE → okuma sonrası filtreli tam bir Scan.
• JOIN → DynamoDB'de sunucu tarafı join yoktur. Birleştirilen her tablo ayrı ayrı getirilir ve istemci tarafında bir araya dikilir — bir N+1 erişim deseni, birleştirilen her satır için bir istek.
• COUNT, SUM, GROUP BY, toplamalar → sunucu tarafı toplama yoktur, bu yüzden eşleşen her item okunur. Bir Scan üzerinde bu, tüm tabloyu okumak demektir.
• Anahtar olmayan bir attribute üzerinde ORDER BY veya DISTINCT → sıralama ve yinelenenleri kaldırma, taranan her ne varsa onun üzerinde istemci tarafında gerçekleşir.

Bunları çalıştırmak yanlış değildir — bazen tam olarak istediğiniz şey bir Scan'dir. Mesele, birini ne zaman çalıştırdığınızı bilmektir.

SQL'i maliyet konusunda nasıl dürüst tutarım?

• Anahtarları erişim desenlerinize göre tasarlayın. En ucuz sorgu, anahtar şemanızın zaten yanıtladığıdır. Bunu tek tablo tasarımı aracı ve query ve scan kılavuzu ile planlayın.
• Scan yerine bir Query almak için WHERE'e bir partition-key eşitliği koyun.
• Taramak-ve-filtrelemek yerine ikinci bir erişim deseni için bir GSI ekleyin.
• Maliyeti çalıştırmadan önce okuyun. DynoTable'ın Workbench'i SQL'inizi gerçek DynamoDB operasyonuna derler ve planı gösterir — Scan mı Query mi, hangi index'i kullandığı, anahtar koşulu ile scan sonrası filtre, ve tahmini bir RCU maliyeti — ardından tam taramaları ve N+1 join'leri satır içinde işaretler. Bu, DynamoDB'nin hiçbir zaman göndermediği EXPLAIN'dir. Ayrıca bkz. scan'ler neden yavaş ve pahalıdır ve on-demand ve provisioned kapasite.

DynoTable'ın SQL'i maliyet sorununu daha kötü mü yapar?

Hayır — çünkü maliyeti görünür kılar. DynamoDB-üzerinde-SQL eleştirisi haklıdır: scan'leri gizleyen bir soyutlama, kendi ayağınıza sıkmanıza izin verir. DynoTable'ın yanıtı SQL'i kaldırmak değil, arkasına bir maliyet röntgeni koymaktır. Workbench'teki her sorgu, çalıştırılmadan önce gerçek DynamoDB şeklinin önizlemesini yapar, böylece SQL'in ergonomisini ve yerel modelin size verdiği RCU'lar ve anahtar tasarımı konusundaki dürüstlüğü korursunuz.

Bunların hiçbiri için AI aracısına ihtiyacım var mı?

Hayır — tablo görüntüleyici, SQL Workbench ve maliyet önizlemesi, o olmadan tamamen çalışır. AI aracısı, DynoTable'ın öne çıkan özelliklerinden biridir — şema bilinçli sorgular yazan, verileri dönüştüren ve daha fazlasını yapan, DynamoDB'ye özgü bir kodlama aracısıdır — ve ne zaman isterseniz oradadır. Kendi AWS Bedrock'unuz üzerinde çalışır, bu yüzden AWS'ye doğrudan maliyetine ödersiniz (ek ücret yok) ve verileriniz hesabınızdan asla çıkmaz. İşe yaradığında açın; çekirdek istemci her iki durumda da eksiksizdir.

Çalışmam taşınabilir mi?

Evet. DynoTable, duvarlarla çevrili bir bahçe değil, standartları konuşur: standart SQL, standart AWS kimlik bilgileri ve SSO, CSV/JSON dışa aktarımı, TypeScript, JSON-Schema veya Zod'a çıkarımsal şema dışa aktarımı ve kendi araçlarınızın ve aracılarınızın bağlanabilmesi için bir MCP sunucusu. Sorgularınız, yapılandırmalarınız ve şemalarınız temiz bir şekilde dışa aktarılır — hiçbir şey kilitli değildir.

Deneyin

DynoTable'ı indirin ve SQL Workbench'i kendi tablonuza karşı açın — maliyet önizlemesi, her sorgunun çalıştırmadan önce gerçekte ne kadara mal olduğunu gösterir.