DynamoDB PartiQL ve SQL: Neler Farklı (ve Ne Bozulur)

DynamoDB PartiQL ile ilgili en büyük kafa karışıklığı kaynağı — hem insanlar hem de yapay zekâ asistanları için — onu ilişkisel SQL gibi ele almaktır. Değildir. PartiQL, DynamoDB'nin mevcut işlemleri üzerinde SQL ile uyumlu bir yüzeydir, birleştirme, gruplama veya toplama yapabilen bir sorgu motoru değil. Tanıdık anahtar sözcükler, altta çok farklı bir makineyi gizler.

Zihinsel model

Her PartiQL ifadesi, DynamoDB'nin yerel işlemlerinden birine derlenir:

İki tablodan okuyabilen, bir hash birleştirmesi kurabilen veya satırları bir COUNT içinde toplayabilen bir planlayıcı yoktur. Bir işlem tek bir Get/Query/Scan/Put/Update/Delete'e eşlenmiyorsa, PartiQL onu basitçe ifade edemez. Tüm hikâye bu — aşağıdaki her şey bu tek gerçeğin bir sonucudur.

Aynı eşleme, bir akış olarak — WHERE yan tümcesi bir SELECT'in ucuz bir Query mi yoksa tüm tablolu bir Scan mi olduğuna karar verir:

Her ifade tam olarak bir yerel işleme çözümlenir — bu birebir eşleme, PartiQL'in neden birleştirme, gruplama veya toplama yapamadığının nedenidir.

Neler farklı — özellik özellik

DynoTable'ın SQL Workbench'inin çalıştırabildiği her işaretlenmiştir. Workbench, tablolarınızı DynamoDB'nin gerçek sorgu çalışma zamanı üzerinden materyalize eder ve üstünde gerçek SQL çalıştırır — DynamoDB'nin erişim modeli kuralları içinde SQL.

Ne bozulur ve neden

Bunlar, sorgu hatta ulaşmadan önce DynoTable'ın PartiQL doğrulayıcısının işaretlediği hatalardır — her biri gerçek bir DynamoDB kısıtına dayanır.

• Partition key olmadan SELECT * gizli bir Scan'dir. PartiQL hata vermez; her item'ı okur ve sonradan filtreler, bu da dostça sözdizimin ardındaki klasik Query ve Scan maliyet tuzağıdır.
• UPDATE / DELETE tam birincil anahtarı gerektirir. Bunlar tek item'lık bir UpdateItem/DeleteItem'a eşlenir, bu yüzden WHERE partition key'i (ve bileşik anahtarlı bir tabloda sort key'i) sabitlemelidir. Tek bir ifadeyle "status = 'open' olan tüm satırları güncelle" yapamazsınız.
• Çift tırnaklar string değil, tanımlayıcıdır. DynamoDB PartiQL burada SQL standardını izler: "name" bir sütun/tablo adıdır, 'name' bir string değeridir. Bir değeri çift tırnakla yazmak en yaygın başlangıç hatasıdır — doğrulayıcının mesajı kelimesi kelimesine "Çift tırnaklar DynamoDB PartiQL'de string'leri değil, tanımlayıcıları sınırlar. String değerleri için tek tırnak kullanın."
• IN parantez değil köşeli parantez kullanır: WHERE pk IN ['a','b'], 50 PK değeri / 100 anahtar dışı değerle sınırlı.
• JOIN yok, toplama yok. Tabloları birleştirecek veya satırları toplayacak bir motor yoktur. Bu, single-table tasarımı ödünleşimidir: erişim modellerinizi önceden modellersiniz çünkü sorgu katmanı veriyi sonradan yeniden şekillendiremez.

Yapay zekâ asistanları bunu neden yanlış anlar

LLM'ler ilişkisel SQL okyanuslarıyla eğitilir, bu yüzden DynamoDB'ye karşı güvenle JOIN, GROUP BY, LIKE, satır içi LIMIT ve çift tırnaklı string değişmezleri üretirler — bunların hepsini DynamoDB reddeder. DynoTable'ın kendi model-sorgu otomatik düzeltmesi tam da bu yüzden vardır: ucuz modeller bu kalıpları güvenilir şekilde ürettiği için çift kaçışlı tırnakları çıkarır, LIKE '%x%' → contains, IS NULL → attribute_not_exists olarak yeniden yazar ve satır içi LIMIT'i istek parametresine taşır. Yapay zekânız Postgres gibi okunan bir "PartiQL" üretiyorsa, işaret budur.

SELECT o.id, c.name
FROM orders o
JOIN customers c ON o.customerId = c.PK

SELECT country, COUNT(*) AS orders, SUM(total) AS revenue
FROM orders
GROUP BY country

SELECT * FROM orders
WHERE customerId IN (SELECT PK FROM customers WHERE country = 'ES')

SELECT PK FROM orders
UNION
SELECT PK FROM archived_orders

SELECT * FROM orders

UPDATE orders SET status = 'shipped'
WHERE status = 'open'

SELECT * FROM users WHERE "name" = "Alice"

DynoTable'ın SQL Workbench'i: PartiQL'in çalıştıramadığı sorgular

Gerçekten bir JOIN veya bir GROUP BY'a ihtiyacınız olduğunda, DynoTable'ın SQL Workbench'i cevaptır. Her JOIN'in hedef tarafını bir partition key'e karşı doğrular, birleştirilen satırları DynamoDB'nin gerçek Query/Scan çalışma zamanı üzerinden materyalize eder, ardından tüm SQL'inizi (toplamalar, GROUP BY, DISTINCT, CASE, CAST) üstünde çalıştırır — DynamoDB'nin erişim modeli kuralları içinde SQL.

-- Runs in the DynoTable Workbench (NOT in PartiQL):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

Dürüst kısıtlamalar (Workbench, Postgres taklidi yapmaz, DynamoDB'nin erişim modelini uygular):

• Yalnızca INNER JOIN ve LEFT JOIN — ON hedef-attribute'u bir partition key veya GSI partition key olmalıdır. RIGHT / FULL / CROSS / virgül-birleştirme yok.
• Henüz öz-birleştirme yok, alt sorgu yok, türetilmiş tablo yok, pencere işlevi yok.
• Birleştirmeler ve projeksiyonlar skaler attribute'lar üzerinde çalışır.

Yalnızca ham API için koşulları ve anahtar ifadelerini oluşturmanız gerekiyorsa, DynamoDB Expression Builder doğru FilterExpression / KeyConditionExpression'ı PartiQL yüzeyi olmadan hiç üretir. PartiQL'i doğru yapmak için, işlenmiş PartiQL örnekleri'ne bakın; herhangi bir sorgunun ne kadara mal olacağını boyutlandırmak için item-boyutu hesaplayıcısı'nı kullanın. PartiQL'in wire formatını asla değiştirmediğini unutmayın — değerler hâlâ DynamoDB-JSON olarak taşınır. Bir istemci mi seçiyorsunuz? Workbench'in düz bir DynamoDB GUI veya Dynobase karşısında nerede durduğuna bakın.

SSS

PartiQL, SQL ile aynı mıdır? Hayır. PartiQL, SQL ile uyumlu bir sorgu dilidir, ancak DynamoDB'de yalnızca tek bir Get/Query/Scan/Put/Update/Delete'e eşlenen işlemleri açığa çıkarır. Birleştirme, toplama, alt sorgu veya GROUP BY yoktur.

DynamoDB PartiQL bir JOIN yapabilir mi? Hayır. DynamoDB PartiQL tabloları birleştiremez. DynoTable'ın SQL Workbench'i, veriyi DynamoDB'nin gerçek sorgu çalışma zamanı üzerinden materyalize ederek INNER/LEFT JOIN (bir partition key veya GSI partition key'e) çalıştırabilir.

DynamoDB PartiQL GROUP BY veya COUNT'u destekler mi? Hayır — DynamoDB PartiQL'de toplama veya GROUP BY yoktur. COUNT/SUM/AVG/GROUP BY/HAVING sorguları için DynoTable'ın SQL Workbench'ini kullanın.

SELECT *'ım neden bu kadar pahalıya mal oluyor? WHERE içinde bir partition key olmadan, PartiQL tüm tablo Scan'i çalıştırır ve filtre uygulanmadan önce okunan her item'ı metreler. Onu bir Query'ye dönüştürmek için bir partition-key yüklemi ekleyin.

PartiQL'de tek mi yoksa çift tırnak mı kullanmalıyım? String değerleri için tek tırnak ('CUSTOMER#42'), tablo ve attribute adları gibi tanımlayıcılar için çift tırnak ("AppData"). Bir değeri çift tırnaklamak en yaygın PartiQL hatasıdır.

DynamoDB'ye karşı gerçek SQL çalıştırmaya hazır mısınız? DynoTable'ı indirin ve bir Workbench sekmesi açın.