SQL untuk DynamoDB dan Batas PartiQL

DynamoDB adalah penyimpan nilai kunci NoSQL, tetapi lebih banyak menjawab pertanyaan berbentuk SQL dari yang diperkirakan orang – dan jauh lebih sedikit dari yang mereka harapkan. Ini adalah peta yang jujur: apa SQL-on-DynamoDB Anda benar-benar keluar dari kotak, di mana ia berhenti, dan beberapa cara untuk menjalankan kueri JOIN / GROUP BY / agregat yang tidak dapat dilakukan oleh permukaan asli mengungkapkan.

Bisakah Anda menanyakan DynamoDB dengan SQL?

Sebagian. DynamoDB dikirimkan PartiQL, bahasa yang kompatibel dengan SQL SELECT/INSERT/UPDATE/DELETE dengan kunci, jadi PILIH * DARI "Pesanan" DI MANA OrderID = 100 berfungsi. Tapi ini adalah permukaan yang kompatibel dengan SQL dibandingkan DynamoDB API, bukan mesin SQL — AWS hanya mendukung subset, jadi JOIN, GROUP BY, dan COUNT(*) keluar. Untuk itu Anda membutuhkan mesin berlapis di atasnya.

AWS menggambarkan PartiQL sebagai "bahasa kueri yang kompatibel dengan SQL, untuk memilih, menyisipkan, memperbarui, dan menghapus data Amazon DynamoDB", tetapi sama eksplisitnya bahwa "Amazon DynamoDB mendukung subset dari PartiQL bahasa permintaan." Saat Anda meraih JOIN, GROUP BY, atau COUNT(*), Anda berada di luar apa yang dapat dilakukan PartiQL — lihat PartiQL vs SQL untuk fitur demi fitur lengkap perbandingan.

PartiQL: permukaan yang kompatibel dengan SQL, bukan mesin SQL

PartiQL memetakan pernyataan yang tampak seperti SQL ke operasi bidang data yang sama dengan SDK mengekspos. SELECT dengan kesetaraan partition-key dikompilasi menjadi Query; sebuah SELECT tanpa ada yang mengkompilasi ke Scan. Menurut Referensi AWS SELECT:

Menggunakan pernyataan SELECT dapat menghasilkan pemindaian tabel penuh jika persamaan atau Kondisi IN dengan kunci partisi tidak disediakan dalam klausa WHERE.

Jadi aturan pola akses yang sama yang mengatur Query dan Scan masih berlaku — PartiQL hanya menyembunyikannya di balik sintaksis yang sudah dikenal. Itu tidak menambahkan perencana kueri, tidak bergabung, dan tidak ada agregasi berbasis set. Setiap pernyataan diciutkan menjadi satu pernyataan asli operasi:

SELECT tanpa kesetaraan kunci partisi dikompilasi menjadi Scan tabel lengkap. Di us-east-1 sesuai permintaan yang menagih 0,5 RCU per 4 KB pada akhirnya konsisten untuk setiap item diperiksa — tabel 500 MB yang berisi baris 2 KB kira-kira 125.000 RCU sebelum filter WHERE mempersempit kumpulan hasil. Berbentuk PartiQL laju garis terbaca di kalkulator harga.

Jika operasi tidak direduksi menjadi satu Dapatkan/Kueri/Pindai/Put/Perbarui/Hapus, PartiQL tidak bisa mengungkapkannya. Segala sesuatu di bawah ini adalah akibat dari hal tersebut fakta.

Apa yang dicakup oleh PartiQL

PartiQL DynamoDB mendukung empat pernyataan DML/query:

• PILIH — membaca item (dikompilasi ke Query atau Scan)
• INSERT — menambahkan item (PutItem)
• UPDATE — memodifikasi item (UpdateItem)
• DELETE — menghapus item (DeleteItem)

Ini juga mendukung transaksi dan operasi batch. Target baca yang terbentuk dengan baik kunci partisi dengan kesetaraan atau IN:

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

ORDER BY diperbolehkan, tetapi referensi AWS membatasi kunci pengurutan ke "a kunci hash atau kunci pengurutan" — partisi atau sort key, bukan kolom sembarang. Itulah batas atas apa yang diterima SELECT PartiQL. Untuk copy-paste-siap pernyataan, lihat Contoh PartiQL.

Apa yang PartiQL tidak bisa lakukan

Ini adalah hal yang paling sering diharapkan oleh pengembang dari "SQL" dan PartiQL mendukung tidak satupun dari mereka:

• Tidak ada JOIN. Itu Sintaks PartiQL SELECT adalah satu FROM XTK0X[.XTK1X] — satu tabel atau satu indeks, tidak pernah dua tabel terkait pada kunci. Ini adalah Pengorbanan desain tabel tunggal: yang Anda modelkan pola akses Anda di awal karena lapisan kueri tidak dapat membentuk ulang data sesudahnya.
• Tidak ada GROUP BY. Itu tidak ada dalam tata bahasa; tidak ada klausa untuk mengelompokkan baris.
• Tidak ada fungsi agregat. The Referensi fungsi PartiQL mencantumkan tepat satu fungsi di bawah "Fungsi agregat": SIZE, yang kembali ukuran atribut dalam byte untuk item tunggal. Tidak ada COUNT, SUM, AVG, MIN, atau MAX melintasi baris. AWS menyatakan dengan jelas: "SQL apa pun fungsi yang tidak termasuk dalam daftar ini saat ini tidak didukung DynamoDB."
• Tanpa LIKE, tanpa subkueri, tanpa UNION, tanpa fungsi jendela. Pencocokan pola menggunakan contains / begins_with; sisanya tidak ada padanannya sama sekali.

Jadi "total pendapatan menurut pelanggan bulan lalu" — GROUP BY satu baris di mana saja database relasional — tidak dapat diungkapkan dalam PartiQL. Anda akan memindai data dan menggabungkannya dalam kode aplikasi.

Satu-satunya cara untuk mendapatkan perilaku JOIN / GROUP BY / agregat yang nyata melalui DynamoDB data adalah alat yang menjalankan mesin SQL sebenarnya di atasnya. Untuk interaktif, kueri ad-hoc ada dua: konektor gabungan Amazon Athena, dan Meja Kerja SQL DynoTable. (Untuk analisis terjadwal, zero-ETL integrasi ke Amazon Redshift juga menjalankan gabungan dan agregat SQL.)

Cara menanyakan DynamoDB dengan SQL asli melalui Amazon Athena

Jawaban AWS sendiri untuk "SQL asli dibandingkan DynamoDB" adalah Konektor Amazon Athena DynamoDB, yang "memungkinkan Amazon Athena berkomunikasi dengan DynamoDB sehingga Anda dapat melakukan kueri meja Anda dengan SQL." Karena Athena adalah mesin SQL lengkap, ini _memang bermanfaat bagi Anda JOIN dan agregat — Panduan AWS diberi judul "Akses, kueri, dan gabung dengan tabel Amazon DynamoDB menggunakan Athena."

Tangkapannya adalah pengaturan dan biaya:

• Ini adalah konektor gabungan berbasis Lambda yang Anda terapkan ke akun Anda (melalui konsol Athena atau Repositori Aplikasi Tanpa Server), berkabel melalui Lem AWS untuk skema dan menumpahkan hasil ke bucket S3 (dokumen konektor).
• Di bawah tenda masih menggunakan operasi Query dan Scan API DynamoDB. AWS memperingatkan bahwa "kueri yang menggunakan pemindaian dapat memakan banyak waktu baca unit kapasitas (RCU)," jadi kueri analitis pada tabel besar berbunyi — dan meter — banyak item (biaya konektor). Gunakan kalkulator ukuran item untuk mengukur berapa a permintaan pemindaian yang berat akan dikenakan biaya.
• Operasi tulis seperti INSERT INTO tidak didukung melalui konektor.

Athena adalah alat yang tepat untuk analisis terjadwal dan dasbor BI. Itu berat untuk kasus sehari-hari "Saya hanya perlu menggabungkan dua tabel dan melihat hasilnya" — itulah celah yang diisi bagian selanjutnya.

DynoTable SQL Workbench: SQL dalam aturan pola akses DynamoDB

SQL Workbench DynoTable menjalankan SQL asli — JOIN, GROUP BY, COUNT/SUM/AVG — dibandingkan tabel DynamoDB langsung Anda dari klien desktop, tanpa Lambda, Lem, atau S3 untuk berdiri. Itu mewujudkan baris-barisnya Runtime Query/Scan asli DynamoDB, lalu menjalankan satu SELECT di atasnya secara lokal di desktop Anda:

-- 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

Bagian "dalam aturan pola akses DynamoDB" penting. Meja Kerja tidak anggaplah DynamoDB adalah Postgres — ia masih membaca Query/Scan di bawah hood, sehingga Anda tetap mengetahui berapa biaya setiap kueri, dan ini menerapkan DynamoDB mengakses model daripada menyembunyikannya:

• Hanya INNER JOIN dan LEFT JOIN — atribut target ON harus a kunci partisi atau kunci partisi GSI. Tanpa RIGHT / FULL / CROSS / gabung koma.
• Belum ada self-join, tidak ada subquery, tidak ada tabel turunan, tidak ada fungsi jendela.
• Gabungan dan proyeksi beroperasi pada atribut skalar.

Jika Anda hanya perlu menyusun kondisi dan ekspresi kunci untuk API mentah — bukan pernyataan SQL lengkap - itu Pembuat Ekspresi DynamoDB menghasilkan benar FilterExpression / KeyConditionExpression tanpa permukaan PartiQL sama sekali.

Jika sasaran Anda adalah DynamoDB klien SQL untuk menjelajah, melakukan debug, dan menganalisis tabel, Meja Kerja mengisi celah tersebut — dan DynoTable lainnya terisi penuh DynamoDB GUI di sekitarnya.

Coba DynoTable untuk menjalankan SQL nyata pada tabel Anda sendiri.

FAQ

Dapatkah Anda menjalankan SQL di DynamoDB? Anda dapat menjalankan PartiQL, subset yang kompatibel dengan SQL (SELECT/INSERT/UPDATE/DELETE oleh kunci). Untuk GABUNG, GROUP BY, dan agregat Anda memerlukan mesin SQL di atas: Amazon Konektor Athena DynamoDB, atau Meja Kerja SQL DynoTable — satu dialek SELECT dengan INNER/LEFT JOIN, tanpa CTE, gabungan, atau subkueri.

Apakah DynamoDB PartiQL mendukung GABUNG? Tidak. Sintaks PartiQL SELECT memiliki tabel atau indeks FROM tunggal dan tidak ada gabungan tata bahasa. Bergabung memerlukan mesin berlapis DynamoDB.

Apakah PartiQL mendukung GROUP BY atau agregat seperti COUNT dan SUM? Tidak. Tidak 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 nilai kunci dan dokumen. PartiQL menambahkan kueri yang kompatibel dengan SQL bahasa di atas, tetapi DynamoDB tidak memiliki mesin relasional, gabungan, atau agregat.

Apakah PartiQL bagus untuk kueri ad-hoc? Untuk pencarian berbasis kunci, ya. Untuk kueri analitis ad-hoc (penghitungan, rollup, bergabung), tidak — PartiQL tidak dapat mengekspresikannya, dan SELECT tidak dibatasi secara diam-diam menjadi pemindaian tabel penuh.

Apakah ada klien DynamoDB SQL yang menangani JOIN dan GROUP BY? Ya — SQL Workbench DynoTable menjalankan JOIN/GROUP BY/aggregates secara langsung tabel dari desktop, dan Amazon Athena melakukannya melalui konektor gabungan Anda terapkan di akun AWS Anda.