Kapan TIDAK Menggunakan Single-Table Design di DynamoDB

Single-table design adalah saran default untuk DynamoDB, dan ia layak: satu Query mengembalikan sebuah induk dan anak-anaknya, tanpa join, tanpa N+1.

Tapi ia adalah sebuah trade — Anda membeli kecepatan baca dengan skema yang kaku dan opak. Beberapa beban kerja tak mampu membayar harga itu, dan memaksakan satu tabel pada mereka adalah jebakannya sendiri.

Kapan sebaiknya Anda tidak menggunakan single-table design di DynamoDB?

Hindari single-table design ketika beban kerja Anda adalah analitik OLAP berat, CRUD sederhana atas sejumlah entitas yang tidak berkaitan, atau entitas yang scale dan gagal secara independen. Dalam kasus-kasus tersebut, multiple table lebih mudah dibaca, biayanya sama, dan tetap fleksibel. Single-table design hanya unggul ketika pola akses sudah diketahui, saling terkait, dan bervolume tinggi.

• Analitik berat? Jangan single-table. Key ter-overload itu hostil terhadap OLAP — ekspor ke columnar store dan query di sana sebagai gantinya.
• CRUD biasa dengan segelintir pola akses? Satu tabel per entitas itu baik-baik saja, mudah dibaca, dan tak membebani Anda apa pun dalam performa.
• Entitas yang scale atau gagal secara independen? Tabel terpisah membiarkan Anda menyetel, menagih, dan membatasi blast-radius mereka secara terpisah.
• Single-table tetap menang saat pola Anda diketahui, terkait, dan bervolume tinggi — itulah kasus yang ia dibangun untuknya.

Ketahui apa yang single-table sebenarnya biayai

Single-table design tidak gratis; ia hanya memindahkan biayanya dari jalur baca ke segala yang lain. Anda membayar dalam legibilitas dan fleksibilitas.

Sebuah tabel yang menampung lima tipe entitas di balik PK/SK sulit dibaca, sulit di-onboard, dan sulit diubah. Sebuah pola akses baru bisa berarti sebuah backfill di seluruh tipe item dalam partition.

Jadi pertanyaannya bukan "apakah single-table bagus?" Tapi "apakah pola akses saya membenarkan kekakuannya?" Saat tidak, jangkau multiple table.

Jangan single-table beban kerja analitik

DynamoDB dibangun untuk OLTP — pembacaan point-and-range yang kecil dan diketahui. Analitik adalah OLAP: GROUP BY, agregat besar, pengirisan ad-hoc di seluruh dataset. Keduanya menarik ke arah berlawanan.

Single-table design membuat OLAP lebih buruk, bukan lebih baik. Key ter-overload dan tipe entitas campuran berarti sebuah job analitik harus lebih dulu mengurai item mana yang mana sebelum ia bisa menjumlahkan apa pun — kebalikan dari sebuah columnar scan yang bersih.

Datang dari SQL, refleksnya adalah menulis agregat terhadap tabel yang hidup. Di DynamoDB itu sebuah Scan penuh — Anda membayar dan membaca setiap item, yang adalah jebakan Scan pada volume penuh.

Solusinya bukan key yang lebih pintar. Ia adalah store yang berbeda. Panduan AWS sendiri adalah mengekspor DynamoDB ke S3 dan menjalankan analitik dengan query engine seperti Athena.

Jaga OLTP dan OLAP pada engine terpisah (AWS DynamoDB Developer Guide, S3DataExport.html).

Jangan single-table CRUD sederhana

Jika aplikasi Anda membaca dan menulis beberapa entitas tak terkait berdasarkan id-nya sendiri, dan Anda punya mungkin tiga pola akses, single-table tak membeli Anda apa pun.

Ambil sebuah tabel Tenants dan sebuah tabel ApiKeys untuk sebuah tool B2B kecil:

Setiap query adalah sebuah GetItem berdasarkan id, atau sebuah Query pada sebuah GSI ber-key TenantId. Tak ada pengambilan induk-dan-anak untuk dioptimasi, jadi tak ada yang bisa dimenangkan sebuah partition ter-overload. Dua tabel yang jelas terbaca lebih baik daripada satu yang keruh.

Jebakannya adalah cargo-culting single-table karena ia "best practice." Best practice adalah access-pattern-first. Jika pola-nya sepele, bentuk sederhana adalah bentuk yang tepat.

Pisahkan tabel yang scale atau gagal secara independen

Sebuah tabel tunggal berbagi satu permukaan throughput, satu backup, satu blast radius. Saat dua entitas punya laju tulis atau kebutuhan durabilitas yang sangat berbeda, nasib bersama itu menjadi sebuah liabilitas.

Bayangkan sebuah sistem pelacakan armada. Kendaraan jarang berubah; telemetri mereka mengucur masuk setiap detik:

Dua tabel membiarkan Anda menyediakan telemetri untuk sebuah firehose, menjaga kendaraan tetap mungil dan murah, mengatur sebuah TTL pada telemetri saja, dan menghentikan sebuah badai tulis telemetri dari men-throttle pembacaan katalog kendaraan. Satu tabel mengkopling semua itu.

Sesuai paper Amazon Dynamo 2007, partisi dan availabilitas adalah perhatian first-class — tabel independen memberi Anda kendali independen atas keduanya.

Petakan keputusan sebelum Anda mengomit

Telusuri beban kerja melalui satu gerbang: apakah entitasnya terkait, dan apakah pola-nya diketahui dan bervolume tinggi? Jika tidak, multiple table.

Berikut keputusannya sebagai sebuah alur — mulai dari atas dan ikuti cabang pertama yang cocok:

Hanya leaf kanan-bawah yang layak single-table; setiap jalur lain lebih baik dilayani oleh lebih dari satu tabel.

Single vs multiple, adu langsung

Jebakan + langkah berikutnya

Kesalahan kebalikannya adalah over-correcting — memecah entitas yang sungguh terkait dan bervolume tinggi menjadi tabel-per-entitas dan membangun ulang join gaya-SQL di aplikasi Anda. Itulah jebakan N+1 yang single-table bunuh.

Pilih bentuk yang diminta pola akses, bukan dogmanya.

Saat Anda memang memodelkan relasi, andalkan tipe indeks yang tepat — lihat GSI vs LSI sebelum Anda menambahkan satu.

Saat Anda memang menulis sebuah query terhadap skema multi-tabel, sketsakan KeyConditionExpression di DynamoDB Expression Builder lebih dulu.

Dengan begitu Anda menangkap sebuah bentuk full-Scan sebelum ia mengenai produksi.

Lalu coba DynoTable untuk menjelajahi kedua bentuk terhadap tabel Anda sendiri dan melihat mana yang sebenarnya diinginkan pola akses Anda.