Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Evaluasi pola penggunaan tabel DynamoDB Anda

Bagian ini memberikan gambaran umum tentang cara mengevaluasi apakah Anda menggunakan tabel DynamoDB secara efisien. Ada pola penggunaan tertentu yang tidak optimal untuk DynamoDB, dan pola tersebut memberikan ruang untuk pengoptimalan baik dari sudut pandang performa maupun biaya.

Lakukan lebih sedikit operasi bacaan sangat konsisten

DynamoDB memungkinkan Anda mengonfigurasi konsistensi baca berdasarkan permintaan. Permintaan baca pada akhirnya konsisten secara default. Akhirnya pembacaan yang konsisten dibebankan pada 0,5 RCU untuk data hingga 4 KB.

Sebagian besar beban kerja terdistribusi bersifat fleksibel dan dapat menoleransi konsistensi akhir. Namun, mungkin ada pola akses yang membutuhkan bacaan sangat konsisten. Pembacaan yang sangat konsisten dikenakan biaya 1 RCU hingga 4 KB data, yang pada dasarnya menggandakan biaya baca Anda. DynamoDB memberi Anda fleksibilitas untuk menggunakan kedua model konsistensi pada tabel yang sama.

Anda dapat mengevaluasi beban kerja dan kode aplikasi untuk mengonfirmasi apakah bacaan sangat konsisten hanya digunakan jika diperlukan.

Lakukan lebih sedikit transaksi untuk operasi baca

DynamoDB memungkinkan Anda untuk mengelompokkan tindakan tertentu dengan cara tertentu, all-or-nothing yang berarti Anda memiliki kemampuan untuk ACID melakukan transaksi dengan DynamoDB. Namun, seperti halnya basis data relasional, pendekatan ini tidak perlu diikuti untuk setiap tindakan.

Operasi baca transaksional hingga 4 KB mengkonsumsi 2 RCUs sebagai lawan dari default 0,5 RCUs untuk membaca jumlah data yang sama dengan cara yang akhirnya konsisten. Biaya digandakan dalam operasi tulis yang berarti, penulisan transaksional hingga 1 KB sama dengan 2. WCUs

Untuk menentukan apakah semua operasi pada tabel Anda adalah transaksi, CloudWatch metrik untuk tabel dapat disaring ke transaksiAPIs. Jika transaksi APIs adalah satu-satunya grafik yang tersedia di bawah SuccessfulRequestLatency metrik untuk tabel, ini akan mengkonfirmasi bahwa setiap operasi adalah transaksi untuk tabel ini. Atau, jika tren pemanfaatan kapasitas keseluruhan sesuai dengan API tren transaksi, pertimbangkan untuk meninjau kembali desain aplikasi karena tampaknya didominasi oleh transaksional. APIs

Lakukan lebih sedikit pemindaian

Penggunaan operasi Scan yang ekstensif umumnya berasal dari kebutuhan untuk menjalankan kueri analitis pada data DynamoDB. Menjalankan operasi Scan yang sering pada tabel besar bisa menjadi tidak efisien dan mahal.

Alternatif yang lebih baik adalah dengan menggunakan fitur Ekspor ke S3 dan memilih titik waktu untuk mengekspor status tabel ke S3. AWS menawarkan layanan seperti Athena yang kemudian dapat digunakan untuk menjalankan kueri analitis pada data tanpa menghabiskan kapasitas apa pun dari tabel.

Frekuensi operasi Scan dapat ditentukan menggunakan statistik SampleCount di bagian metrik SuccessfulRequestLatency untukScan. Jika operasi Scan memang sangat sering, pola akses dan model data harus dievaluasi ulang.

Gunakan nama atribut yang lebih pendek

Ukuran total item di DynamoDB adalah jumlah dari panjang dan nilai nama atributnya. Memiliki nama atribut yang panjang tidak hanya berkontribusi terhadap biaya penyimpanan, tetapi juga dapat menyebabkan lebih tinggi RCU/WCU consumption. We recommend that you choose shorter attribute names rather than long ones. Having shorter attribute names can help limit the item size within the next 4KB/1KB boundary after which you would consume additional RCU/WCU untuk mengakses data.

Aktifkan Waktu untuk Tayang (TTL)

Time to Live (TTL) dapat mengidentifikasi item yang lebih lama dari waktu kedaluwarsa yang telah Anda tetapkan pada item dan menghapusnya dari tabel. Jika data Anda tumbuh dari waktu ke waktu dan data yang lebih lama menjadi tidak relevan, mengaktifkan TTL di atas meja dapat membantu memangkas data Anda dan menghemat biaya penyimpanan.

Aspek lain yang berguna TTL adalah bahwa item kedaluwarsa terjadi pada aliran DynamoDB Anda, jadi daripada hanya menghapus data dari data Anda, adalah mungkin untuk mengkonsumsi item tersebut dari aliran dan mengarsipkannya ke tingkat penyimpanan biaya yang lebih rendah. Selain itu, menghapus item melalui TTL datang tanpa biaya tambahan — itu tidak menghabiskan kapasitas, dan tidak ada biaya tambahan untuk merancang aplikasi pembersihan.

Ganti tabel global dengan cadangan lintas Wilayah

Tabel global memungkinkan Anda mengelola beberapa tabel replika aktif di Wilayah berbeda — semuanya dapat menerima operasi tulis dan mereplikasi data satu sama lain. Sangat mudah untuk mengatur replika dan sinkronisasi dikelola untuk Anda. Replika menyatu ke keadaan konsisten menggunakan strategi penulis terakhir menang.

Jika Anda menggunakan tabel Global semata-mata sebagai bagian dari strategi failover atau pemulihan bencana (DR), Anda dapat menggantinya dengan salinan cadangan lintas Wilayah untuk sasaran titik pemulihan yang relatif ringan dan persyaratan sasaran waktu pemulihan. Jika Anda tidak memerlukan akses lokal yang cepat dan ketersediaan lima sembilan yang tinggi, mempertahankan replika tabel global mungkin bukan pendekatan terbaik untuk failover.

Sebagai alternatif, pertimbangkan untuk menggunakan AWS Backup untuk mengelola backup DynamoDB. Anda dapat menjadwalkan pencadangan rutin dan menyalinnya di seluruh Wilayah untuk memenuhi persyaratan DR dengan pendekatan yang lebih hemat biaya dibandingkan menggunakan tabel Global.