Single-Table Design di DynamoDB

Datang dari SQL, insting kita adalah satu tabel per entitas: customers, orders, order_items. Di DynamoDB insting itu biasanya keliru. Satu tabel yang menyimpan setiap entitas, dibedakan oleh prefiks key yang dibebani, membuat Anda bisa mengambil sebuah induk dan anak-anaknya dalam satu Query — tanpa join, tanpa N+1.

Apa itu single-table design di DynamoDB?

Single-table design menyimpan setiap entitas — customer, order, order item — dalam satu tabel DynamoDB, dibedakan oleh prefiks partition key dan sort key yang dibebani. Karena key dirancang seputar pola akses Anda alih-alih entitas Anda, sebuah induk dan semua anaknya berada dalam satu koleksi Item dan kembali dalam satu Query — tanpa join, tanpa pembacaan N+1.

Idenya

Pilih nama key generik (PK, SK) dan encode tipe entitas ke dalam nilainya:

Kini satu Query PK = "CUSTOMER#42" mengembalikan profil dan setiap order dalam satu pembacaan tertagih. SK begins_with "ORDER#" mempersempitnya hanya ke order.

Secara visual, Item yang dibebani menumpuk di bawah satu partition key sebagai satu koleksi Item:

Satu pembacaan partisi mengembalikan customer dan setiap order sekaligus.

GSI yang dibebani

Trik yang sama berlaku pada index. Pasang GSI1PK/GSI1SK generik pada Item, dan satu GSI melayani beberapa pola akses bergantung pada apa yang ditulis setiap Item ke atribut tersebut:

Kini Query GSI1 WHERE GSI1PK = "STATUS#OPEN" menampilkan order terbuka berdasarkan tanggal — pola yang tidak bisa dijawab tabel dasar. Entitas berbeda bisa memakai ulang GSI1 dengan makna sendiri (mis. CATEGORY#books). Satu index, banyak query.

Many-to-many: adjacency list

Untuk relasi (satu user di banyak team, satu team dengan banyak user), tulis edge dua kali dengan id yang ditukar: PK=USER#1, SK=TEAM#9 dan PK=TEAM#9, SK=USER#1. Melakukan query pada salah satu sisi menampilkan sisi lainnya — pengganti join table di DynamoDB.

Kapan tidak melakukan single-table

Ini tidak gratis. Satu tabel yang dibebani lebih sulit dinalar, lebih sulit dievolusi, dan tidak ramah analitik. Jika pola akses Anda benar-benar tak diketahui atau berubah terus-menerus, atau datanya sebagian besar analitis, tabel terpisah (atau store lain) bisa jadi pilihan yang lebih waras. Single-table menang ketika polanya diketahui dan bervolume tinggi.

Biaya dari bentuk yang salah

Memodelkan sebagai tabel terpisah memaksa Scan atau join di sisi klien untuk merakit ulang seorang customer, dan itulah jebakan Scan. Modelkan pola akses terlebih dahulu, lalu rancang key agar tiap pola menjadi sebuah Query. (Untuk pertanyaan lintas-entitas ad-hoc yang tak pernah Anda modelkan, SQL Workbench DynoTable menjalankan JOIN-nya di sisi klien — eksplorasi tidak harus menunggu pemodelan ulang.)

Buat sketsa desainnya sendiri dengan alat Single-Table Design gratis — ia mengubah daftar pola akses Anda menjadi sebuah rencana PK/SK/GSI dengan contoh item dan petunjuk biaya. Perkirakan berapa biaya Item-item ini per pembacaan dengan kalkulator ukuran Item & kapasitas, dan coba DynoTable untuk menjelajahi skema single-table dan melihat koleksi yang dibebani berdampingan.