Contoh memodelkan data relasional di DynamoDB

Contoh ini menjelaskan cara memodelkan data relasional di Amazon DynamoDB. Desain tabel DynamoDB sesuai dengan skema entri urutan relasional yang ditampilkan dalam Pemodelan relasional. Desain ini mengikuti Pola desain daftar kedekatan, yang merupakan cara umum untuk merepresentasikan struktur data relasional di DynamoDB.

Pola desain mengharuskan Anda untuk menentukan set jenis entitas yang biasanya berkorelasi dengan berbagai tabel dalam skema relasional. Item entitas kemudian ditambahkan ke tabel menggunakan kunci primer gabungan (partisi dan urutan). Kunci partisi pada item entitas ini adalah atribut yang mengidentifikasi item secara unik dan disebut secara umum pada semua item sebagai PK. Atribut kunci urutan berisi nilai atribut yang dapat Anda gunakan untuk indeks terbalik atau indeks sekunder global. Hal ini umumnya disebut sebagai SK.

Anda menentukan entitas berikut, yang mendukung skema entri urutan relasional.

Setelah menambahkan item entitas ini ke tabel, Anda dapat menentukan hubungan di antara item entitas tersebut dengan menambahkan item edge ke partisi item entitas. Tabel berikut menunjukkan langkah ini.

Dalam contoh ini, partisi Employee, Order, dan Product Entity pada tabel memiliki item edge lain yang berisi penunjuk ke item entitas lain pada tabel. Selanjutnya, tentukan beberapa indeks sekunder global (GSIs) untuk mendukung semua pola akses yang ditentukan sebelumnya. Tidak semua item entitas menggunakan jenis nilai yang sama untuk atribut kunci primer atau kunci urutan. Yang diperlukan hanyalah atribut primer utama dan kunci urutan untuk dimasukkan ke dalam tabel.

Fakta bahwa beberapa entitas ini menggunakan nama yang tepat dan yang lain menggunakan entitas lain IDs sebagai nilai kunci pengurutan memungkinkan indeks sekunder global yang sama untuk mendukung beberapa jenis kueri. Teknik ini disebut GSIoverloading. Teknik ini secara efektif menghilangkan batas default 20 indeks sekunder global untuk tabel yang berisi beberapa jenis item. Ini ditunjukkan pada diagram berikut sebagai GSI1.

GSI2 dirancang untuk mendukung pola akses aplikasi yang cukup umum, yaitu untuk mendapatkan semua item di atas meja yang memiliki keadaan tertentu. Untuk tabel besar dengan distribusi item yang tidak merata di seluruh status yang tersedia, pola akses ini dapat menghasilkan hot key, kecuali jika item didistribusikan ke lebih dari satu partisi logis yang dapat dikueri secara paralel. Pola desain ini disebut write sharding.

Untuk mencapai ini untuk GSI 2, aplikasi menambahkan GSI 2 atribut kunci utama untuk setiap item Order. Aplikasi mengisinya dengan nomor acak dalam kisaran 0-N, dengan N secara umum dapat dihitung menggunakan rumus berikut, kecuali ada alasan khusus untuk melakukan sebaliknya.

ItemsPerRCU = 4KB / AvgItemSize

PartitionMaxReadRate = 3K * ItemsPerRCU

N = MaxRequiredIO / PartitionMaxReadRate

Sebagai contoh, misalkan Anda mengharapkan hal berikut:

Untuk tabel tersebut, penghitungan faktor N akan seperti berikut ini.

ItemsPerRCU = 4KB / 250B = 16

PartitionMaxReadRate = 3K * 16 = 48K

N = (0.2 * 3M) / 48K = 13

Dalam hal ini, Anda perlu mendistribusikan semua pesanan di setidaknya 13 partisi logis pada GSI 2 untuk memastikan bahwa pembacaan semua Order item dengan OPEN status tidak menyebabkan partisi panas pada lapisan penyimpanan fisik. Memasukkan jumlah ini untuk memungkinkan anomali dalam set data adalah praktik yang baik. Jadi, model yang menggunakan N = 15 mungkin baik-baik saja. Seperti disebutkan sebelumnya, Anda melakukan ini dengan menambahkan nilai 0-N acak ke atribut GSI 2 PK masing-masing Order dan OrderItem catatan yang dimasukkan pada tabel.

Perincian ini mengasumsikan bahwa pola akses yang memerlukan pengumpulan semua faktur OPEN relatif jarang terjadi sehingga Anda dapat menggunakan kapasitas lonjakan untuk memenuhi permintaan. Anda dapat mengkueri indeks sekunder global berikut menggunakan syarat Kunci Urutan State dan Date Range untuk menghasilkan sebagian atau semua Orders dalam status tertentu sesuai kebutuhan.

Dalam contoh ini, item didistribusikan secara acak ke 15 partisi logis. Struktur ini berfungsi karena pola akses memerlukan sejumlah besar item untuk diambil. Oleh karena itu, kecil kemungkinannya bahwa salah satu dari 15 thread akan mengembalikan set hasil kosong yang berpotensi mewakili kapasitas yang terbuang. Kueri selalu menggunakan 1 unit kapasitas baca (RCU) atau 1 unit kapasitas tulis (WCU), bahkan jika tidak ada yang dikembalikan atau tidak ada data yang ditulis.

Jika pola akses memerlukan kueri kecepatan tinggi pada indeks sekunder global ini yang mengembalikan set hasil yang jarang, sebaiknya gunakan algoritma hash untuk mendistribusikan item daripada pola acak. Dalam hal ini, Anda dapat memilih atribut yang diketahui ketika kueri dijalankan pada saat runtime dan meng-hash atribut tersebut ke dalam ruang kunci 0–14 saat item dimasukkan. Kemudian, item tersebut dapat dibaca secara efisien dari indeks sekunder global.

Terakhir, Anda dapat meninjau kembali pola akses yang ditetapkan sebelumnya. Berikut ini adalah daftar pola akses dan ketentuan kueri yang akan Anda gunakan dengan versi DynamoDB baru pada aplikasi untuk mengakomodasinya.