DynamoDB PartiQL ve SQL: Neyin Bozulduğu

DynamoDB PartiQL ile ilgili en büyük kafa karışıklığı kaynağı — hem insanlar hem de yapay zeka asistanları için — onu ilişkisel SQL olarak ele almaktır. Öyle değil. PartiQL, DynamoDB'nin mevcut işlemleri üzerine bir SQL uyumlu yüzeydir, join, gruplama veya toplama yapabilen bir sorgu motoru değil. Tanıdık anahtar kelimeler, altta çok farklı bir makineyi gizler.

DynamoDB PartiQL, SQL'den nasıl farklıdır?

PartiQL, SQL'in sözdizimini ödünç alır ama motorunu almaz. DynamoDB'de her ifade tek bir yerel işleme eşlenir — GetItem, Query, Scan, PutItem, UpdateItem veya DeleteItem — dolayısıyla JOIN, GROUP BY, alt sorgu veya toplama yoktur. SQL gibi okunur ama yalnızca bu anahtar-değer işlemlerinin zaten yapabildiğini yapabilir.

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

İki tablodan okuyabilen, bir hash join oluşturabilen veya satırları bir COUNT'a katlayan bir planlayıcı yoktur. Bir işlem tek bir Get/Query/Scan/Put/Update/Delete'e eşlenmiyorsa, PartiQL onu basitçe ifade edemez. Bütün hikaye budur — aşağıdaki her şey bu tek gerçeğin sonucudur.

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

Her ifade tam olarak tek bir yerel işleme çözülür — işte PartiQL'in join, gruplama veya toplama yapamamasının nedeni bu bire-bir eşlemedir.

Neyin farklı olduğu — özellik özellik

Workbench sütununun bir PartiQL Hayır'ına karşı Evet dediği her yerde, bu DynoTable'ın SQL Workbench'inin kapattığı bir boşluktur. Workbench, tablolarınızı DynamoDB'nin gerçek sorgu çalışma zamanı aracılığıyla maddeleştirir ve üzerinde gerçek SQL çalıştırır — DynamoDB'nin erişim-deseni kuralları içinde SQL.

Neyin bozulduğu ve nedeni

Bunlar, sorgu tele ulaşmadan önce DynoTable'ın PartiQL doğrulayıcısının işaretlediği başarısızlıklardır — her biri gerçek bir DynamoDB kısıtlamasına dayanır.

• Bölüm anahtarı olmadan SELECT * gizli bir Scan'dir. PartiQL hata vermez; sadece her öğeyi okur ve sonrasında filtreler, ki bu da dostça sözdiziminin ardındaki klasik Query-vs-Scan maliyet ayak-silahıdır.
• UPDATE / DELETE tam birincil anahtara ihtiyaç duyar. Bunlar tek öğeli bir UpdateItem/DeleteItem'e eşlenir, bu yüzden WHERE bölüm anahtarını (ve bir bileşik anahtar tablosunda sıralama anahtarını) sabitlemelidir. Tek bir ifadede "status = 'open' olan tüm satırları güncelle" yapamazsınız.
• Çift tırnak dizeler değil, tanımlayıcılardır. DynamoDB PartiQL burada SQL standardını izler: "name" bir sütun/tablo adıdır, 'name' bir dize değeridir. Bir değeri çift tırnakla alıntılamak en yaygın acemi hatasıdır — doğrulayıcının mesajı tam anlamıyla şudur: "DynamoDB PartiQL'de çift tırnaklar dizeleri değil tanımlayıcıları sınırlar. Dize 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-olmayan değerle sınırlıdır.
• JOIN yok, toplama yok. Tabloları birleştirecek veya satırları katlayacak bir motor yoktur. Bu, tek tablo tasarımı takasıdır: sorgu katmanı sonradan veriyi yeniden şekillendiremediği için erişim desenlerinize göre önceden modellersiniz.

Yapay zeka asistanları bunu neden yanlış yapar

LLM'ler okyanuslar dolusu ilişkisel SQL üzerinde eğitilmiştir, bu yüzden DynamoDB'ye karşı kendinden emin bir şekilde JOIN, GROUP BY, LIKE, satır içi LIMIT ve çift tırnaklı dize sabitleri üretirler — bunların hepsini DynamoDB reddeder. DynoTable'ın kendi model-sorgu otomatik düzeltmesi tam da bunun için vardır çünkü ucuz modeller bu desenleri güvenilir bir şekilde üretir: çift kaçışlı tırnakları soyar, LIKE '%x%' → contains, IS NULL → attribute_not_exists olarak yeniden yazar ve satır içi LIMIT'i istek parametresine yükseltir. Yapay zekanı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'e veya bir GROUP BY'a ihtiyacınız olduğunda, DynoTable'ın SQL Workbench'i cevaptır. Her JOIN'in hedef tarafını bir bölüm anahtarına karşı doğrular, birleştirilmiş satırları DynamoDB'nin gerçek Query/Scan çalışma zamanı aracılığıyla maddeleştirir, sonra üzerinde tek bir SELECT (toplamalar, GROUP BY, DISTINCT, CASE, CAST) çalıştırır — DynamoDB'nin erişim-deseni 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, DynamoDB'nin erişim modelini uygular, Postgres gibi davranıyormuş gibi yapmaz):

• Yalnızca INNER JOIN ve LEFT JOIN — ON hedef özniteliği bir bölüm anahtarı veya GSI bölüm anahtarı olmalıdır. RIGHT / FULL / CROSS / virgül-join yok.
• Henüz kendine-join yok, alt sorgu yok, türetilmiş tablo yok, pencere fonksiyonu yok.
• Join'ler ve yansıtmalar skaler öznitelikler üzerinde çalışır.

Ham API için yalnızca koşulları ve anahtar ifadelerini oluşturmanız gerekiyorsa, DynamoDB İfade Oluşturucu, PartiQL yüzeyi hiç olmadan doğru FilterExpression / KeyConditionExpression'ı üretir. Doğru yapılan PartiQL için, işlenmiş PartiQL örneklerine bakın; herhangi bir sorgunun maliyetini ölçmek için öğe boyutu hesaplayıcısını kullanın. PartiQL'in tel biçimini asla değiştirmediğini unutmayın — değerler yine DynamoDB-JSON olarak seyahat eder. Bir istemci mi seçiyorsunuz? Workbench'in sade bir DynamoDB GUI veya Dynobase karşısında nerede durduğuna bakın.

SSS

PartiQL, SQL ile aynı mı? Hayır. PartiQL, SQL 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. Join, 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ı aracılığıyla maddeleştirerek INNER/LEFT JOIN (bir bölüm anahtarına veya GSI bölüm anahtarına) ç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'de bir bölüm anahtarı olmadan, PartiQL tam tablo bir Scan çalıştırır ve filtre uygulanmadan önce okunan her öğeyi ölçer. Onu bir Query'e dönüştürmek için bir bölüm anahtarı yüklemi ekleyin.

PartiQL'de tek mi çift tırnak kullanmalıyım? Dize değerleri için tek tırnak ('CUSTOMER#42'), tablo ve öznitelik adları gibi tanımlayıcılar için çift tırnak ("AppData"). Bir değeri çift tırnakla yazmak 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.