DynamoDB bir NoSQL veritabanı mı?

Evet. DynamoDB bir NoSQL veritabanıdır — ilişkisel olmayan, tamamen yönetilen bir anahtar-değer ve doküman deposu. Sabit şemalı tablolardaki satırlar yerine şemasız öğeler tutar ve SQL join'leri ile anlık sorguları, öngörülebilir tek haneli milisaniyelik performans ve fiilen her boyuta yatay ölçeklenme karşılığında takas eder.

Ne tür bir NoSQL

DynamoDB hem anahtar-değer hem de doküman veri modellerini destekler. Her öğeye bir birincil anahtarla erişilir ve öznitelikler eşleme ve liste olarak 32 düzeye kadar iç içe geçebilir — modelin doküman tarafı budur.

SQL'den nasıl ayrılır

Sabit şema yok — önden yalnızca birincil anahtar tanımlanır; diğer öznitelikler öğeden öğeye değişir.
Join yok — bunun yerine denormalize eder ve erişim desenleri etrafında modellersiniz.
Öngörülebilir performans — okumalar bir bölüm anahtarını hedefler, dolayısıyla veri büyüdükçe gecikme düz kalır.

Motor bir JOIN ile ne yapar

PartiQL, DynamoDB'yi SQL biçimli gösterir; dolayısıyla sınırı kaçırmak kolaydır. AWS'nin belgelenmiş SELECT sözdizimi dilbilgisinin tamamıdır ve içinde JOIN yan tümcesi yoktur:

SELECT {{expression}}  [, ...]
FROM {{table}}[.{{index}}]
[ WHERE {{condition}} ] [ [ORDER BY {{key}} [DESC|ASC] , ...]

Yine de bir tane gönderin; ayrıştırıcı ikinci tabloda durur:

await client.send(
  new ExecuteStatementCommand({
    Statement: `SELECT o.pk FROM "orders" o JOIN "customers" c ON o.pk = c.pk`
  })
);

Gerçek çıktı:

ValidationException: Only select from a single table or index is supported.
HTTP 400

Ret, hiç veri okunmadan önce, ayrıştırma zamanında gerçekleşir; hiçbir indeks tasarımının sana bir join kazandırmamasının nedeni de budur. Bir NoSQL deposunda birleştirme uygulamanızın işidir.

Bu, herhangi bir istemcinin dürüstçe sunabileceğini de sınırlar. DynoTable'ın SQL Workbench'i INNER JOIN, LEFT JOIN, GROUP BY ve COUNT/SUM/AVG/MIN/MAX kabul eder.

Bunları yerel Query ve Scan çağrılarına derler, sonra sonuçları senin makinenizde birleştirir ve toplar. DynamoDB yine yalnızca tek tablolu okumalar görür.

Ne zaman uyar

DynamoDB, OLTP iş yükleri için kurulmuştur: yüksek hacimli, bilinen nokta ve aralık okumaları ile yazmaları. Ağır analitik, dışa aktarımla beslenen ayrı bir sütunlu depoya aittir.

Production'da hâlâ hissettiğiniz NoSQL sınırları

"NoSQL", kısıtların kaldırıldığını değil, erişim modelini tanımlar. DynamoDB sizi hâlâ öğe başına 400 KB ile, TransactWriteItems başına 25 eylemle ve işlem başına 100 okuma ya da yazma eylemiyle sınırlar. İç içe bir doküman 32 seviye derin olabilir. GSI'lar yalnızca adını verdiğiniz attribute'ları projekte eder; geri düşülecek gizli bir şema yoktur.

Bu sınırlar önemlidir, çünkü sorgu zamanında birleştirerek onlardan sıyrılamazsınız. Onların etrafında baştan modellersiniz — seyrek dizinler, denormalize edilmiş attribute'lar ve tek tablo anahtarları — sonra partition'a göre okursunuz. Sorgu oluşturucu, bir filtreyi DynamoDB'nin gerçekten çalıştıracağı Query ya da Scan isteğine dönüştürür.

DynoTable'da: ilişkisel bir soru meşru olduğunda, SQL Workbench JOIN ve GROUP BY'ı makinenizde yerel Query ve Scan çağrılarına derler — DynamoDB yine tek tablo okumaları görür. Desteklenen gramer ve dürüst sınırlar için bkz. SQL Workbench.

Daha derine inin

DynamoDB ne zaman kullanılır sayfasına ve verinin nasıl biçimlendirileceği için DynamoDB'de veri nasıl modellenir sayfasına bakın. NoSQL tablolarınıza göz atmak ve DynamoDB'nin erişim deseni kuralları içinde onlar üzerinde SQL çalıştırmak için DynoTable'ı indirin.

Kaynaklar

En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı; PartiQL SELECT dilbilgisi 2026-07-28 tarihinde yeniden kontrol edildi.

2026-07-28 tarihinde @aws-sdk/client-dynamodb 3.1095.0 ile Node v24.18.0 üzerinde DynamoDB Local 3.3.0'a karşı yeniden üretildi. Yukarıdaki ValidationException birebir motor çıktısıdır.