SQL untuk DynamoDB: Apa yang Bekerja, Apa yang Tidak, dan Workbench

DynamoDB adalah penyimpanan key-value NoSQL, tapi ia menjawab pertanyaan berbentuk-SQL lebih dari yang orang kira — dan jauh lebih sedikit dari yang mereka harapkan. Inilah peta yang jujur: SQL-di-DynamoDB apa yang benar-benar kamu dapat di luar kotak, di mana ia berhenti, dan beberapa cara untuk menjalankan kueri JOIN / GROUP BY / agregat yang tak bisa diekspresikan permukaan native.

Bisakah kamu mengkueri DynamoDB dengan SQL? Jawaban singkat

Sebagian. DynamoDB membawa PartiQL, yang dokumen AWS gambarkan sebagai "a SQL-compatible query language, to select, insert, update, and delete data in Amazon DynamoDB." Jadi kamu bisa menulis SELECT * FROM "Orders" WHERE OrderID = 100 dan itu bekerja.

Tapi PartiQL adalah permukaan kompatibel-SQL di atas API DynamoDB, bukan mesin SQL. Ia berbicara sintaksnya; ia tidak menambah daya kueri relasional. AWS eksplisit bahwa "Amazon DynamoDB supports a subset of the PartiQL query language" (referensi). Saat kamu menjangkau JOIN, GROUP BY, atau COUNT(*), kamu di luar apa yang bisa dilakukan PartiQL — lihat PartiQL vs SQL untuk perbandingan fitur demi fitur lengkapnya.

PartiQL: permukaan kompatibel-SQL, bukan mesin SQL

PartiQL memetakan pernyataan yang terlihat SQL ke operasi data-plane yang sama yang dipaparkan SDK. Sebuah SELECT dengan kesetaraan partition-key dikompilasi ke Query; sebuah SELECT tanpanya dikompilasi ke Scan. Per referensi SELECT AWS:

Using the SELECT statement can result in a full table scan if an equality or IN condition with a partition key is not provided in the WHERE clause.

Jadi aturan pola-akses yang sama yang mengatur Query dan Scan tetap berlaku — PartiQL hanya menyembunyikannya di balik sintaks familiar. Ia tak menambah query planner, tanpa join, dan tanpa agregasi berbasis-set. Setiap pernyataan runtuh ke satu operasi native:

Jika sebuah operasi tak menyusut ke satu Get/Query/Scan/Put/Update/Delete, PartiQL sederhananya tak bisa mengekspresikannya. Semua di bawah ini adalah konsekuensi dari satu fakta itu.

Apa yang dicakup PartiQL

PartiQL DynamoDB mendukung empat pernyataan DML/kueri:

• SELECT — baca item (dikompilasi ke Query atau Scan)
• INSERT — tambah item (PutItem)
• UPDATE — modifikasi item (UpdateItem)
• DELETE — hapus item (DeleteItem)

Ia juga mendukung transaksi dan operasi batch. Sebuah baca yang well-formed menarget partition key dengan kesetaraan atau IN:

SELECT OrderID, Total
FROM "Orders"
WHERE OrderID IN [1, 2, 3] ORDER BY OrderID DESC

ORDER BY diizinkan, tapi referensi AWS membatasi kunci pengurutan ke "a hash key or a sort key" — partition atau sort key, bukan kolom sembarang. Itulah plafon dari apa yang diterima SELECT PartiQL. Untuk pernyataan siap-tempel, lihat contoh PartiQL.

Apa yang tak bisa dilakukan PartiQL

Inilah hal-hal yang paling sering pengembang harapkan dari "SQL," dan PartiQL mendukung tak satu pun darinya:

• Tanpa JOIN. Sintaks SELECT PartiQL adalah FROM {{table}}[.{{index}}] tunggal — satu tabel atau satu index, tak pernah dua tabel berhubungan pada sebuah key. Ini tradeoff single-table-design: kamu memodelkan untuk pola aksesmu di depan karena lapisan kueri tak bisa membentuk ulang data setelahnya.
• Tanpa GROUP BY. Ia tak ada dalam grammar; tak ada klausa untuk mengelompokkan baris.
• Tanpa fungsi agregat. Referensi fungsi PartiQL mencantumkan tepat satu fungsi di bawah "Aggregate functions": SIZE, yang mengembalikan ukuran atribut dalam byte untuk satu item. Tak ada COUNT, SUM, AVG, MIN, atau MAX lintas baris. AWS menyatakan terus terang: "Any SQL functions that are not included in this list are not currently supported in DynamoDB."
• Tanpa LIKE, tanpa subkueri, tanpa UNION, tanpa fungsi window. Pencocokan pola memakai contains / begins_with; sisanya tak punya ekuivalen sama sekali.

Jadi "total pendapatan per pelanggan bulan lalu" — satu baris GROUP BY di basis data relasional mana pun — tak bisa diekspresikan di PartiQL. Kamu harus scan datanya keluar dan mengagregasinya di kode aplikasi.

Satu-satunya cara mendapat perilaku JOIN / GROUP BY / agregat sungguhan atas data DynamoDB adalah alat yang menjalankan mesin SQL aktual di atasnya. Ada dua: konektor federasi Amazon Athena, dan SQL Workbench DynoTable.

Cara mengkueri DynamoDB dengan SQL sungguhan via Amazon Athena

Jawaban AWS sendiri untuk "SQL sungguhan atas DynamoDB" adalah konektor DynamoDB Amazon Athena, yang "enables Amazon Athena to communicate with DynamoDB so that you can query your tables with SQL." Karena Athena adalah mesin SQL penuh, ini memang memberimu JOIN dan agregat — walkthrough AWS berjudul "Access, query, and join Amazon DynamoDB tables using Athena."

Jebakannya adalah penyiapan dan biaya:

• Ini konektor federasi berbasis-Lambda yang kamu deploy ke akunmu (via konsol Athena atau Serverless Application Repository), terkabel melalui AWS Glue untuk skema dan menumpahkan hasil ke bucket S3 (dokumen konektor).
• Di balik layar ia tetap memakai operasi API Query dan Scan DynamoDB. AWS memperingatkan bahwa "queries that use scans can consume a large number of read capacity units (RCUs)," jadi kueri analitik atas tabel besar membaca — dan menghitung — banyak item (biaya konektor). Gunakan kalkulator ukuran-item untuk mengukur berapa biaya kueri yang berat-scan.
• Operasi tulis seperti INSERT INTO tidak didukung melalui konektor.

Athena adalah alat yang tepat untuk analitik terjadwal dan dasbor BI. Ia berat untuk kasus sehari-hari "saya cuma perlu join dua tabel dan melihat hasilnya" — itulah celah yang diisi bagian berikutnya.

SQL Workbench DynoTable: SQL dalam aturan pola-akses DynamoDB

SQL Workbench DynoTable menjalankan SQL sungguhan — JOIN, GROUP BY, COUNT/SUM/AVG — terhadap tabel DynamoDB live-mu dari klien desktop, tanpa Lambda, Glue, atau S3 yang harus disiapkan. Ia memmaterialisasi baris melalui runtime Query/Scan nyata DynamoDB, lalu menjalankan SQL penuhmu di mesin in-memory di atasnya:

-- Berjalan di DynoTable Workbench (BUKAN di 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

Bagian "dalam aturan pola-akses DynamoDB" itu penting. Workbench tak berpura-pura DynamoDB adalah Postgres — ia tetap membaca melalui Query/Scan di balik layar, jadi kamu tetap sadar berapa biaya tiap kueri, dan ia menegakkan model akses DynamoDB alih-alih menyembunyikannya:

• Hanya INNER JOIN dan LEFT JOIN — atribut-target ON harus partition key atau partition key GSI. Tanpa RIGHT / FULL / CROSS / comma-join.
• Belum ada self-join, tanpa subkueri, tanpa tabel turunan, tanpa fungsi window.
• Join dan proyeksi beroperasi pada atribut skalar.

Jika kamu hanya butuh menyusun kondisi dan ekspresi key untuk API mentah — bukan pernyataan SQL penuh — DynamoDB Expression Builder menghasilkan FilterExpression / KeyConditionExpression yang benar tanpa permukaan PartiQL sama sekali.

Jika tujuanmu adalah klien SQL DynamoDB untuk menjelajah, men-debug, dan menganalisis tabel, Workbench mengisi celah itu — dan sisa DynoTable adalah GUI DynamoDB penuh di sekitarnya.

Coba DynoTable untuk menjalankan SQL sungguhan terhadap tabelmu sendiri.

FAQ

Bisakah kamu menjalankan SQL pada DynamoDB? Kamu bisa menjalankan PartiQL, subset kompatibel-SQL (SELECT/INSERT/UPDATE/DELETE berdasarkan key). Untuk SQL penuh — JOIN, GROUP BY, agregat — kamu butuh mesin SQL di atas: konektor DynamoDB Amazon Athena, atau SQL Workbench DynoTable.

Apakah PartiQL DynamoDB mendukung JOIN? Tidak. Sintaks SELECT PartiQL punya satu tabel atau index FROM dan tanpa grammar join. Join membutuhkan mesin yang dilapiskan di atas DynamoDB.

Apakah PartiQL mendukung GROUP BY atau agregat seperti COUNT dan SUM? Tidak. Tak ada klausa GROUP BY, dan satu-satunya fungsi "agregat" adalah SIZE (ukuran byte atribut untuk satu item). COUNT, SUM, AVG, MIN, dan MAX lintas baris tidak didukung.

Apakah DynamoDB SQL atau NoSQL? NoSQL — penyimpanan key-value dan dokumen. PartiQL menambah bahasa kueri kompatibel-SQL di atas, tapi DynamoDB tak punya mesin relasional, join, atau agregat.

Apakah PartiQL bagus untuk kueri ad-hoc? Untuk pencarian berbasis-key, ya. Untuk kueri ad-hoc analitik (count, rollup, join), tidak — PartiQL tak bisa mengekspresikannya, dan SELECT tak-terbatas diam-diam menjadi full table scan.

Adakah klien SQL DynamoDB yang menangani JOIN dan GROUP BY? Ya — SQL Workbench DynoTable menjalankan JOIN/GROUP BY/agregat terhadap tabel live dari desktop, dan Amazon Athena melakukannya via konektor federasi yang kamu deploy di akun AWS-mu.