Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Bagian ini mencakup lapisan fondasi dengan memeriksa dua jenis desain tabel: tabel tunggal dan multitabel.
Fondasi desain tabel tunggal
Salah satu pilihan untuk fondasi skema DynamoDB adalah desain tabel tunggal. Desain tabel tunggal adalah pola yang memungkinkan Anda menyimpan beberapa jenis (entitas) data dalam tabel DynamoDB tunggal. Hal ini bertujuan untuk mengoptimalkan pola akses data, meningkatkan performa, dan mengurangi biaya dengan menghilangkan kebutuhan untuk memelihara beberapa tabel dan hubungan yang kompleks di antara tabel-tabel tersebut. Hal ini dimungkinkan karena DynamoDB menyimpan item dengan kunci partisi yang sama (dikenal sebagai koleksi item) pada partisi yang sama satu sama lain. Dalam desain ini, berbagai jenis data disimpan sebagai item dalam tabel yang sama, dan setiap item diidentifikasi dengan kunci urutan yang unik.
Keuntungan
-
Lokalitas data untuk mendukung kueri untuk beberapa jenis entitas dalam satu panggilan basis data
-
Mengurangi biaya keuangan dan latensi pembacaan secara keseluruhan:
-
Satu kueri untuk dua item dengan total kurang dari 4KB adalah 0,5 akhirnya konsisten RCU
-
Dua kueri untuk dua item dengan total kurang dari 4KB adalah 1 RCU akhirnya konsisten (masing-masing 0,5) RCU
-
Waktu untuk mengembalikan dua panggilan database terpisah akan rata-rata lebih tinggi dari satu panggilan
-
-
Mengurangi jumlah tabel untuk dikelola:
-
Izin tidak perlu dipertahankan di beberapa IAM peran atau kebijakan
-
Manajemen kapasitas untuk tabel dirata-ratakan di seluruh entitas, biasanya menghasilkan pola konsumsi yang lebih dapat diprediksi
-
Pemantauan membutuhkan alarm yang lebih sedikit
-
Kunci Enkripsi yang Dikelola Pelanggan hanya perlu dirotasi pada satu tabel
-
-
Memperlancar lalu lintas ke tabel:
-
Dengan menggabungkan beberapa pola penggunaan ke tabel yang sama, penggunaan secara keseluruhan cenderung lebih lancar (seperti performa indeks saham yang cenderung lebih lancar dibandingkan dengan saham individual) yang bekerja lebih baik untuk mencapai penggunaan yang lebih tinggi dengan tabel mode yang telah disediakan
-
Kekurangan
-
Kurva pembelajaran bisa curam karena desain paradoks dibandingkan dengan basis data relasional
-
Persyaratan data harus konsisten di semua jenis entitas
-
Pencadangan semuanya atau tidak sama sekali jadi jika beberapa data tidak penting untuk misi, pertimbangkan untuk menyimpannya di tabel terpisah
-
Enkripsi tabel dibagikan di semua item. Untuk aplikasi multi-penghuni dengan persyaratan enkripsi penghuni individual, enkripsi di sisi klien akan diperlukan
-
Tabel dengan campuran data historis dan data operasional tidak akan mendapatkan banyak manfaat dengan mengaktifkan Kelas Penyimpanan Akses Jarang. Untuk informasi selengkapnya, silakan lihat Kelas tabel DynamoDB
-
-
Semua data yang diubah akan disebarkan ke DynamoDB Streams meskipun hanya sebagian dari entitas yang perlu diproses.
-
Berkat filter peristiwa Lambda, hal ini tidak akan memengaruhi tagihan Anda saat menggunakan Lambda, tetapi akan menjadi biaya tambahan saat menggunakan Kinesis Consumer Library
-
-
Saat menggunakan GraphQL, desain tabel tunggal akan lebih sulit diterapkan
-
Saat menggunakan SDK klien tingkat yang lebih tinggi seperti Java DynamoDBMapperatau Enhanced Client, akan lebih sulit untuk memproses hasil karena item dalam respons yang sama dapat dikaitkan dengan kelas yang berbeda
Kapan harus digunakan
Desain tabel tunggal adalah pola desain yang direkomendasikan untuk DynamoDB kecuali kasus penggunaan Anda akan sangat dipengaruhi oleh salah satu kekurangan di atas. Bagi sebagian besar pelanggan, manfaat jangka panjang lebih besar daripada tantangan jangka pendeknya, yaitu merancang tabel mereka dengan cara ini.
Fondasi desain multitabel
Pilihan kedua untuk fondasi skema DynamoDB kita adalah desain multitabel. Desain multitabel adalah pola yang lebih mirip dengan desain basis data tradisional tempat Anda menyimpan satu jenis (entitas) data dalam setiap tabel DynamoDB. Data dalam setiap tabel tetap akan diatur oleh kunci partisi, sehingga performa dalam satu jenis entitas akan dioptimalkan untuk skalabilitas dan performa, tetapi kueri di beberapa tabel harus dilakukan secara independen.
Keuntungan
-
Perancangannya lebih sederhana bagi mereka yang tidak terbiasa bekerja dengan desain tabel tunggal
-
Implementasi resolver GraphQL yang lebih mudah karena setiap resolver dipetakan ke satu entitas (tabel)
-
Memungkinkan persyaratan data unik di berbagai jenis entitas:
-
Cadangan dapat dibuat untuk tabel individu yang sangat penting untuk misi
-
Enkripsi tabel dapat dikelola untuk setiap tabel. Untuk aplikasi multi-penghuni dengan persyaratan enkripsi penghuni individual, tabel penghuni terpisah memungkinkan setiap pelanggan memiliki kunci enkripsinya sendiri
-
Kelas Penyimpanan Akses Jarang dapat diaktifkan hanya pada tabel dengan data historis untuk merealisasikan manfaat penghematan biaya penuh. Untuk informasi selengkapnya, silakan lihat Kelas tabel DynamoDB
-
-
Setiap tabel akan memiliki aliran data perubahannya sendiri yang memungkinkan fungsi Lambda khusus dirancang untuk setiap jenis item daripada prosesor monolitik tunggal
Kekurangan
-
Untuk pola akses yang memerlukan data di beberapa tabel, beberapa pembacaan dari DynamoDB akan diperlukan dan data mungkin perlu diproses/digabungkan pada kode klien.
-
Operasi dan pemantauan beberapa tabel membutuhkan lebih banyak CloudWatch alarm dan setiap tabel harus diskalakan secara independen
-
Setiap izin tabel perlu dikelola secara terpisah. Penambahan tabel di masa depan akan membutuhkan perubahan pada IAM peran atau kebijakan yang diperlukan
Kapan harus digunakan
Jika pola akses aplikasi Anda tidak memiliki kebutuhan untuk melakukan kueri untuk beberapa entitas atau tabel bersama-sama, maka desain multitabel adalah pendekatan yang baik dan memadai.