DynamoDB'yi AI ile (Doğal Dille) Nasıl Sorgularsınız

"Geçen haftanın başarısız siparişlerini göster", kafanızda tek satırlık bir cümle, telde ise yer tutucu eşlemeli bir KeyConditionExpression'dır. O boşluğu kapatmak, "DynamoDB'yi AI ile sorgulamak"ın gerçekte anlamıdır — çünkü DynamoDB API'sinin kendisinin doğal dil uç noktası yoktur. Her istek hâlâ ifadeler veya 'dir; AI, niyetinizi onlara çeviren araç katmanında oturur.

O çeviri, tek bir şeye bağlı olarak gerçekten harika ya da sessizce tehlikeli olabilir: modelin gerçek şemanızı görüp göremediği. Bu kılavuz, çalışan üç kurulumu ve her birinin nerede kırıldığını kapsar.

DynamoDB'yi doğal dil kullanarak nasıl sorgularım?

Üç gerçek seçenek: genel bir LLM'den PartiQL taslağı isteyin ve kendiniz çalıştırın (hızlı, ama model öznitelik adlarınızı tahmin ediyordur), bir AI ajanını gerçekten inceleyip sorgulayabilmesi için bir MCP sunucusu aracılığıyla DynamoDB'ye bağlayın veya yerleşik şema-farkında bir asistana sahip bir DynamoDB istemcisi kullanın — DynoTable'ın AI sohbeti, sade dili gerçek dizinlenmiş şemanıza karşı PartiQL'e veya SQL'e çevirir, kesin tam-tablo toplulaştırmaları hesaplar ve her yazmayı gözden geçirmeniz için hazırlar.

Seçenek 1: LLM taslaklı PartiQL, sizin çalıştırdığınız

Sıfır kurulumlu sürüm: sorguyu yetenekli herhangi bir modele tarif edin, PartiQL'i geri alın, konsolun PartiQL düzenleyicisinde veya CLI ile çalıştırın:

aws dynamodb execute-statement \
  --statement "SELECT * FROM \"Orders\" WHERE PK = 'ORDER#1001'"

İşe yarar — ve öngörülebilir üç şekilde başarısız olur:

Model tablonuzu göremez. Öznitelik adlarını ve anahtar şekillerini kendinden emin bir şekilde uydurur (sizinki PK = ORDER#<id> iken orderId). Sorguyu yazmak yerine halüsinasyon görülmüş şemayı ayıklarken bulursunuz kendinizi.
PartiQL'in sınırları hâlâ geçerlidir. Bir SELECT tam olarak tek bir tablo okur ve bir anahtarı sabitlemeyen bir WHERE, bir tam tablo taramasına dönüşür — tıpkı kendiniz yazmışsınız gibi, sessizce pahalı. Model nadiren sizi uyarır; PartiQL ve SQL, SQL yüzeyinin neyi sağlayıp neyi sağlamadığını açıklar.
Bir sohbet robotuna şema veya veri yapıştırmak bir veri yönetişimi kararıdır. Bir istemdeki örnek öğeler, sınırınızı terk eden üretim verisidir.

Bellekten yapıştırabildiğiniz bir şemadaki tek seferlik sorgular için iyi; bir iş akışı olarak sallantılı.

Seçenek 2: MCP ile bağlanmış bir AI ajanı

"Model tablonuzu göremez" sorununun yapısal çözümü, ajana istem içine yapıştırılmış bir şema yerine araçlar vermektir. Model Context Protocol (MCP) tam olarak bunu yapar: bir MCP sunucusu, DynamoDB işlemlerini türlenmiş araçlar olarak açığa çıkarır ve MCP yetenekli herhangi bir ajan (Claude, IDE asistanları, özel ajanlar) tabloları listeleyebilir, anahtarları inceleyebilir ve gerçek sonuçları konuşmaya geri beslenerek sorgular çalıştırabilir.

Tam kurulumu — ve bir ajanın bir veritabanına dokunmasına izin vermekle gelen onay, kapsam belirleme ve yazma güvenliği sorularını — Bir MCP sunucusuyla DynamoDB kullanımı bölümünde ele alıyoruz. DynoTable'ın kendisi bir tane içerir: dış ajanlara bağlantı başına onay ve kapsamlarla, kapılı, yalnızca-loopback araçlar açığa çıkarabilir.

Ajanın ürün olduğu durumlarda doğru mimari budur — bir destek botu, dahili bir Slack asistanı. Etkileşimli günlük iş içinse ajanı, sunucuyu ve kimlik bilgilerini kendiniz birleştirmenizi gerektirir.

Seçenek 3: DynamoDB istemcinizde şema-farkında bir asistan

DynoTable'ın yerleşik asistanı, entegre sürümdür: tablolarınızın yanında yaşar (⌘;) ve dizinlenmiş şemanızı okur — aktif profil altındaki tablolar, anahtarları ve dizinleri, tablo dizinlemenin keşfettiği öznitelik yolları ve türleri, hatta örnek değerler — böylece "bunu geçen haftaya filtrele", bir tahmine değil, gerçek öznitelik adlarınıza karşı çözümlenir. Bir @table, @column veya @gsi'ye açıkça başvurmak için @ yazın.

Bir tablo sekmesinin yanına yerleştirilmiş DynoTable AI sohbeti: sade dilde bir soru, üretilen sorgu ve bir görünüm olarak açılan sonuç.

Bir soruyla ne yaptığı, yetenek kataloğuna göre:

Sorguyu sizin için yazar — salt okunur PartiQL veya soru JOIN / GROUP BY / toplulaştırmalar gerektirdiğinde (DynamoDB API'sinin sahip olmadığı analitik) Workbench SQL'i — ve sonucu, gerçek bir sekme olarak açmak için tıkladığınız bir çip olarak önerir.
Kesin tam-tablo yanıtları hesaplar. Bir sayım, toplam, ortalama veya grup başına döküm isteyin; örneklenmiş bir sayfayı değil, eşleşen her öğeyi okur — "geçen ay kaç sipariş?" gerçek tabloyu yansıtır. Aynı geçişi dönüştürülmüş bir dışa aktarma dosyasına da şekillendirebilir.
Her yazmayı hazırlar. Bir satırı düzeltmesini isteyin; değişiklik, gözden geçirilebilir bir diff olarak hazırlama alanına düşer — asistan hiçbir izin modunda DynamoDB'ye doğrudan yazamaz, bir tabloyu toplu silemez veya tablo yapısını değiştiremez. Siz gözden geçirirsiniz, siz commit edersiniz.
Paranızı harcamadan önce sorar. AWS'ye giden ve kapasiteye mal olan okumalar izin kapılıdır (profil başına Manual / Auto / Full Auto) ve her kapılı karar, yerel, her zaman açık bir denetim günlüğüne düşer.

Güven modeli, özellikler kadar önemlidir: asistan kendi AWS Bedrock kimlik bilgileriniz üzerinde, hesabınızdaki Bedrock ile doğrudan konuşarak çalışır — istemler, şema ve tablo verisi asla DynoTable'ın sunucularından geçmez ve çıkarım, hiçbir kâr payı olmadan Bedrock'un kendi tarifeleriyle size faturalandırılır. Araç sonuçları güvenilmeyen veri olarak ele alınır, dolayısıyla "önceki talimatları yok say" içeren bir satır ajanı ele geçiremez.

AI'nın DynamoDB hakkında değiştirmediği şeyler

Dürüst her AI katmanı, veritabanının fiziğini devralır:

Erişim desenleri hâlâ hükmeder. Anahtar olmayan bir öznitelik üzerinde "where status = X", kim yazarsa yazsın filtrelenmiş bir taramadır — model sadece pahalı sorguyu daha hızlı yazar. Bir soru sürekli taramaları zorluyorsa, çözüm modellemedir (bir GSI, daha iyi bir sıralama anahtarı), daha iyi bir istem değil.
Okumalar gerçek kapasiteye mal olur. Kesin bir tam-tablo toplulaştırması, bir tam-tablo okumasıdır. İyi araçlar bunu kapılar ve söyler; fiyatlandırma hesaplayıcısı, onaylamadan önce tam bir geçişin neye mal olduğunu söyler.
Determinizmin yeri vardır. Üretimde sonsuza dek çalıştıracağınız bir sorgu için, ifadeyi bir kez İfade Oluşturucu'da elle kurun ve tam ad/değer eşlemelerini gönderin — AI keşif içindir, oluşturucu commit ettiğiniz kod içindir.

SSS

DynamoDB'yi sade Türkçeyle sorgulayabilir miyim? API'nin kendisine karşı değil — DynamoDB yalnızca ifadeler ve PartiQL konuşur. Ama bir AI katmanı çevirebilir: PartiQL taslağı çıkaran bir LLM, MCP bağlantılı bir ajan veya sorguyu gerçek şemanıza karşı üretip çalıştıran DynoTable'ınki gibi şema-farkında bir asistan.

DynamoDB'nin yerleşik bir AI sorgulama özelliği var mı? DynamoDB API'sinin doğal dil uç noktası yoktur. Elde ettiğiniz her AI sorgulama, üstteki araç katmanından gelir — bu yüzden değerlendirilecek şey, o aracın güvenlik modelidir (okuma kapıları, hazırlanmış yazmalar, kendi kimlik bilgileriniz).

AI'yı üretim verisinin yakınına bırakmak güvenli mi? Bu bir izinler sorusudur. Şunlara bakın: açık onayın arkasına kapılanmış okumalar, doğrudan yürütülmek yerine gözden geçirilebilir bir hazırlama alanına düşen yazmalar, bir denetim günlüğü ve denetlediğiniz kimlik bilgileriyle çıkarım. DynoTable'ın asistanı dördünü de karşılar; verinizi yapıştırdığınız bir sohbet robotu hiçbirini karşılamaz.

AI tabloları join'leyebilir veya GROUP BY yapabilir mi? DynamoDB API'si üzerinden değil — bunun için bir motor yoktur. DynoTable'ın asistanı bu soruları, salt okunur Workbench SQL'i aracılığıyla yanıtlar (DynamoDB'nin erişim-deseni kuralları içinde gerçek JOIN, GROUP BY ve toplulaştırmalar) — sayım/toplam/ortalama soruları da oraya düşer.

Neye mal olur? İki sayaç: sorguların dokunduğu her şey için DynamoDB okuma kapasitesi (asistan kapılı okumalardan önce sorar) ve kendi AWS hesabınıza faturalandırılan Bedrock çıkarımı — DynoTable kâr payı eklemez ve hiçbir şeyi vekillemez.

Bir sonraki sorunuzu sade dille sorun — DynoTable'ı indirin, AI'yı kendi Bedrock'unuza yöneltin ve her yazmayı bir gözden geçirmenin arkasında tutun.