Pedoman umum tentang indeks sekunder di DynamoDB - Amazon DynamoDB

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

Pedoman umum tentang indeks sekunder di DynamoDB

Amazon DynamoDB mendukung dua jenis indeks sekunder:

  • Indeks sekunder global (GSI)— Indeks dengan kunci partisi dan kunci urutan yang mungkin berbeda dari yang ada di tabel dasar. Indeks sekunder global dianggap "global" karena kueri pada indeks dapat menjangkau semua data di tabel dasar, di semua partisi. Indeks sekunder global tidak memiliki batasan ukuran dan memiliki pengaturan throughput tersendiri untuk aktivitas baca dan tulis yang terpisah dari yang ada di tabel.

  • Indeks sekunder lokal (LSI)—Indeks yang memiliki kunci partisi yang sama dengan tabel dasar, tetapi kunci urutan yang berbeda. Indeks sekunder lokal bersifat "lokal" dalam arti bahwa setiap partisi indeks sekunder lokal dicakup ke partisi tabel dasar yang memiliki nilai kunci partisi yang sama. Dengan demikian, ukuran total item yang diindeks untuk setiap satu nilai kunci partisi tidak dapat melampaui 10 GB. Selain itu, indeks sekunder lokal memiliki pengaturan throughput yang disediakan yang sama untuk aktivitas baca dan tulis dengan tabel yang diindeks.

Setiap tabel di DynamoDB dapat memiliki hingga 20 indeks sekunder global (kuota default) dan 5 indeks sekunder lokal.

Indeks sekunder global sering kali lebih berguna daripada indeks sekunder lokal. Menentukan jenis indeks yang akan digunakan juga akan bergantung pada kebutuhan aplikasi Anda. Untuk perbandingan indeks sekunder global dan indeks sekunder lokal, dan informasi lebih lanjut tentang cara memilih di antara mereka, lihat. Meningkatkan akses data dengan indeks sekunder

Berikut ini adalah beberapa prinsip umum dan pola desain yang perlu diingat saat membuat indeks di DynamoDB:

Gunakan indeks secara efisien

Pertahankan jumlah indeks seminimal mungkin. Jangan membuat indeks sekunder pada atribut yang tidak sering Anda kueri. Indeks yang jarang digunakan berkontribusi pada peningkatan penyimpanan dan biaya I/O tanpa peningkatan performa aplikasi.

Pilih proyeksi dengan hati-hati

Karena indeks sekunder menggunakan penyimpanan dan throughput yang disediakan, Anda harus menjaga ukuran indeks sekecil mungkin. Selain itu, semakin kecil indeks, semakin besar keuntungan performa dibandingkan dengan kueri untuk tabel penuh. Jika kueri Anda biasanya hanya menampilkan sebagian kecil atribut, dan ukuran total atribut tersebut jauh lebih kecil dibandingkan keseluruhan item, hanya proyeksikan atribut yang sering Anda minta.

Jika Anda menginginkan lebih banyak aktivitas tulis pada tabel daripada aktivitas baca, ikuti praktik terbaik berikut:

  • Pertimbangkan untuk memproyeksikan lebih sedikit atribut untuk meminimalkan ukuran item yang ditulis ke indeks. Namun, ini hanya berlaku jika ukuran atribut yang diproyeksikan lebih besar dari satu unit kapasitas tulis (1 KB). Sebagai contoh, jika ukuran entri indeks hanya 200 byte, DynamoDB membulatkannya hingga 1 KB. Dengan kata lain, selama item indeksnya kecil, Anda dapat memproyeksikan lebih banyak atribut tanpa biaya tambahan.

  • Hindari memproyeksikan atribut yang Anda tahu akan jarang diperlukan dalam kueri. Setiap kali memperbarui atribut yang diproyeksikan dalam indeks, Anda juga dikenakan biaya tambahan untuk memperbarui indeks. Anda masih dapat mengambil atribut yang tidak diproyeksikan di Query dengan biaya yang lebih tinggi untuk throughput yang disediakan, tetapi biaya kueri mungkin jauh lebih rendah daripada biaya memperbarui indeks berulang kali.

  • Tentukan ALL hanya jika Anda ingin kueri mengembalikan seluruh item tabel yang diurutkan berdasarkan kunci urutan yang berbeda. Memproyeksikan semua atribut akan menghilangkan kebutuhan untuk mengambil tabel, tetapi dalam banyak kasus, akan menggandakan biaya untuk penyimpanan dan aktivitas tulis.

Seimbangkan kebutuhan untuk menjaga indeks Anda sekecil mungkin terhadap kebutuhan untuk menjaga pengambilan tetap rendah, seperti yang dijelaskan di bagian berikutnya.

Mengoptimalkan kueri yang sering dilakukan untuk menghindari pengambilan

Untuk mendapatkan kueri tercepat dengan latensi serendah mungkin, proyeksikan semua atribut yang Anda harapkan akan dihasilkan oleh kueri tersebut. Khususnya, jika Anda mengkueri indeks sekunder lokal untuk atribut yang tidak diproyeksikan, DynamoDB otomatis mengambil atribut tersebut dari tabel, yang mengharuskan pembacaan seluruh item dari tabel. Hal ini menimbulkan latensi dan operasi I/O tambahan yang dapat Anda hindari.

Ingatlah bahwa kueri "sesekali" sering kali dapat berubah menjadi kueri "penting". Jika ada atribut yang tidak ingin Anda proyeksikan karena Anda hanya ingin mengkuerinya sesekali, pertimbangkan apakah keadaan mungkin berubah dan Anda pada akhirnya mungkin menyesal tidak memproyeksikan atribut tersebut.

Untuk informasi selengkapnya tentang pengambilan tabel, lihat Pertimbangan throughput yang disediakan untuk Indeks Sekunder Lokal.

Memahami batas ukuran kumpulan item ketika membuat indeks sekunder lokal

Koleksi item adalah semua item dalam tabel dan indeks sekunder lokalnya yang memiliki kunci partisi yang sama. koleksi item tidak dapat melampaui 10 GB, sehingga kehabisan ruang dapat terjadi untuk nilai kunci partisi tertentu.

Ketika Anda menambahkan atau memperbarui item tabel, DynamoDB memperbarui semua indeks sekunder lokal yang terpengaruh. Jika atribut yang diindeks ditetapkan dalam tabel, indeks sekunder lokal juga bertambah.

Saat Anda membuat indeks sekunder lokal, perhatikan jumlah data yang akan ditulis ke dalamnya, dan jumlah item data tersebut yang memiliki nilai kunci partisi yang sama. Jika Anda memperkirakan bahwa jumlah item tabel dan indeks untuk nilai kunci partisi tertentu mungkin melebihi 10 GB, pertimbangkan apakah Anda harus menghindari pembuatan indeks.

Jika tidak dapat menghindari pembuatan indeks sekunder lokal, Anda harus mengantisipasi batas ukuran koleksi item dan mengambil tindakan sebelum batas tersebut terlampaui. Sebagai praktik terbaik, Anda harus memanfaatkan ReturnItemCollectionMetricsparameter saat menulis item untuk memantau dan memperingatkan ukuran koleksi item yang mendekati batas ukuran 10GB. Melebihi ukuran koleksi item maksimum akan mengakibatkan upaya penulisan yang gagal. Anda dapat mengurangi masalah ukuran koleksi item dengan memantau dan memberi tahu ukuran koleksi item sebelum berdampak pada aplikasi Anda.

catatan

Setelah dibuat, Anda tidak dapat menghapus indeks sekunder lokal.

Untuk strategi bekerja dalam batas dan pengambilan tindakan korektif, lihat Batas ukuran kumpulan item.