Indeks Sekunder Lokal di DynamoDB

Beberapa aplikasi hanya perlu mengkueri data menggunakan kunci primer tabel dasar. Namun, mungkin ada situasi ketika kunci urutan alternatif akan berguna. Untuk memberi aplikasi Anda pilihan kunci urutan, Anda dapat membuat satu atau beberapa indeks sekunder lokal pada tabel Amazon DynamoDB dan mengeluarkan permintaan Query atau Scan terhadap indeks ini.

Skenario: Menggunakan Indeks Sekunder Lokal

Sebagai contoh, perhatikan Thread tabel. Tabel ini berguna untuk aplikasi seperti forum diskusi AWS. Diagram berikut menunjukkan bagaimana item dalam tabel akan diatur. (Tidak semua atribut ditampilkan.)

DynamoDB menyimpan semua item dengan nilai kunci partisi yang sama secara berkelanjutan. Dalam contoh ini, dengan ForumName tertentu, operasi Query dapat segera menemukan semua utas untuk forum itu. Dalam grup item dengan nilai kunci partisi yang sama, item diurutkan berdasarkan nilai kunci urutan. Jika kunci urutan (Subject) juga disediakan dalam kueri, DynamoDB dapat mempersempit hasil yang dikembalikan—misalnya, mengembalikan semua utas di forum "S3" yang memiliki Subject yang diawali dengan huruf "a".

Beberapa permintaan mungkin memerlukan pola akses data yang lebih kompleks. Misalnya:

Untuk menjawab pertanyaan-pertanyaan ini, tindakan Query tidak akan cukup. Sebaliknya, Anda harus Scan seluruh tabel. Untuk tabel dengan jutaan item, ini akan menghabiskan banyak throughput baca yang disediakan dan membutuhkan waktu lama untuk selesai.

Namun, Anda dapat menentukan satu atau beberapa indeks sekunder lokal pada atribut non-kunci, seperti Replies atau LastPostDateTime.

Indeks sekunder lokal mempertahankan kunci urutan alternatif untuk nilai kunci partisi yang diberikan. Indeks sekunder lokal juga berisi salinan beberapa atau semua atribut dari tabel dasarnya. Anda akan menentukan atribut yang diproyeksikan ke indeks sekunder lokal saat membuat tabel. Data dalam indeks sekunder lokal diatur oleh kunci partisi yang sama dengan tabel dasar, tetapi dengan kunci urutan yang berbeda. Ini memungkinkan Anda mengakses item data secara efisien di seluruh dimensi yang berbeda ini. Untuk fleksibilitas kueri atau pemindaian yang lebih baik, Anda dapat membuat hingga lima indeks sekunder lokal per tabel.

Misalkan sebuah aplikasi perlu menemukan semua utas yang telah diposting dalam tiga bulan terakhir di forum tertentu. Tanpa indeks sekunder lokal, aplikasi harus Scan seluruh tabel Thread dan membuang postingan apa pun yang tidak berada dalam periode waktu yang ditentukan. Dengan indeks sekunder lokal, operasi Query dapat menggunakan LastPostDateTime sebagai kunci urutan dan menemukan data dengan cepat.

Diagram berikut menunjukkan indeks sekunder lokal bernama LastPostIndex. Perhatikan bahwa kunci partisi sama dengan tabel Thread, tetapi kunci urutannya adalah LastPostDateTime.

Setiap indeks sekunder lokal harus memenuhi syarat berikut:

Dalam contoh ini, kunci partisi adalah ForumName dan kunci urutan indeks sekunder lokal adalah LastPostDateTime. Selain itu, nilai kunci urutan dari tabel dasar (dalam contoh ini, Subject) diproyeksikan ke dalam indeks, tetapi bukan merupakan bagian dari kunci indeks. Jika aplikasi membutuhkan daftar yang didasarkan pada ForumName dan LastPostDateTime, aplikasi dapat mengeluarkan permintaan Query terhadap LastPostIndex. Hasil kueri diurutkan menurut LastPostDateTime, dan dapat dikembalikan dalam urutan menaik atau menurun. Kueri juga dapat menerapkan syarat kunci, seperti hanya mengembalikan item yang memiliki LastPostDateTime dalam rentang waktu tertentu.

Setiap indeks sekunder lokal otomatis berisi kunci partisi dan kunci urutan dari tabel dasarnya; Anda secara opsional dapat memproyeksikan atribut non-kunci ke dalam indeks. Saat Anda mengkueri indeks, DynamoDB dapat mengambil atribut yang diproyeksikan ini secara efisien. Saat Anda mengkueri indeks sekunder lokal, kueri juga dapat mengambil atribut yang tidak diproyeksikan ke dalam indeks. DynamoDB otomatis mengambil atribut ini dari tabel dasar, tetapi dengan latensi lebih besar dan dengan biaya throughput yang disediakan lebih tinggi.

Untuk indeks sekunder lokal apa pun, Anda dapat menyimpan hingga 10 GB data per nilai kunci partisi yang berbeda. Angka ini mencakup semua item dalam tabel dasar, ditambah semua item dalam indeks, yang memiliki nilai kunci partisi yang sama. Untuk informasi selengkapnya, lihat Kumpulan item dalam Indeks Sekunder Lokal.

Proyeksi atribut

Dengan LastPostIndex, sebuah aplikasi dapat menggunakan ForumName dan LastPostDateTime sebagai kriteria kueri. Namun, untuk mengambil atribut tambahan apa pun, DynamoDB harus melakukan operasi baca tambahan terhadap tabel Thread. Pembacaan tambahan ini dikenal sebagai pengambilan, dan pembacaan tersebut dapat meningkatkan jumlah total throughput yang disediakan yang diperlukan untuk kueri.

Misalkan Anda ingin mengisi halaman web dengan daftar semua utas di "S3" dan jumlah balasan untuk setiap utas, diurutkan berdasarkan tanggal/waktu balasan terakhir yang dimulai dengan balasan terbaru. Untuk mengisi daftar ini, Anda memerlukan atribut berikut:

Cara paling efisien untuk mengkueri data ini dan untuk menghindari operasi pengambilan adalah dengan memproyeksikan atribut Replies dari tabel ke dalam indeks sekunder lokal, seperti yang ditunjukkan dalam diagram ini.

Proyeksi adalah kumpulan atribut yang disalin dari tabel ke indeks sekunder. Kunci partisi dan kunci urutan tabel selalu diproyeksikan ke dalam indeks; Anda dapat memproyeksikan atribut lain untuk mendukung persyaratan kueri aplikasi Anda. Saat Anda mengkueri indeks, Amazon DynamoDB dapat mengakses atribut apa pun dalam proyeksi seolah-olah atribut tersebut berada dalam tabelnya sendiri.

Saat membuat indeks sekunder, Anda perlu menentukan atribut yang akan diproyeksikan ke dalam indeks. DynamoDB menyediakan tiga opsi berbeda untuk ini:

Pada diagram sebelumnya, atribut non-kunci Replies diproyeksikan ke dalam LastPostIndex. Aplikasi dapat meminta LastPostIndex sebagai ganti dari tabel Thread lengkap untuk mengisi halaman web dengan Subject, Replies, dan LastPostDateTime. Jika ada atribut non-kunci lain yang diminta, DynamoDB perlu mengambil atribut tersebut dari tabel Thread.

Dari sudut pandang aplikasi, pengambilan atribut tambahan dari tabel dasar dilakukan secara otomatis dan transparan, jadi tidak perlu menulis ulang logika aplikasi apa pun. Namun, pengambilan tersebut dapat sangat mengurangi keuntungan performa menggunakan indeks sekunder lokal.

Saat memilih atribut untuk diproyeksikan ke dalam indeks sekunder lokal, Anda harus mempertimbangkan tradeoff antara biaya throughput yang disediakan dan biaya penyimpanan:

Membuat Indeks Sekunder Lokal

Untuk membuat satu atau beberapa indeks sekunder lokal pada tabel, gunakan parameter LocalSecondaryIndexes operasi CreateTable. Indeks sekunder lokal pada tabel dibuat saat tabel dibuat. Saat Anda menghapus tabel, indeks sekunder lokal apa pun di tabel itu juga akan dihapus.

Anda harus menentukan satu atribut non-kunci untuk berfungsi sebagai kunci urutan indeks sekunder lokal. Atribut yang Anda pilih harus berupa skalar String, Number, atau Binary. Jenis skalar, jenis dokumen, dan jenis kumpulan lain tidak diperbolehkan. Untuk daftar lengkap jenis data, lihat Jenis Data.

Anda dapat memproyeksikan atribut jenis data apa pun ke dalam indeks sekunder lokal. Ini termasuk skalar, dokumen, dan kumpulan. Untuk daftar lengkap jenis data, lihat Jenis Data.

Membaca data dari Indeks Sekunder Lokal

Anda dapat mengambil item dari indeks sekunder lokal menggunakan operasi Query dan Scan. Operasi GetItem dan BatchGetItem tidak dapat digunakan pada indeks sekunder lokal.

Mengkueri Indeks Sekunder Lokal

Dalam tabel DynamoDB, nilai kunci partisi gabungan dan nilai kunci urutan untuk setiap item harus unik. Namun, dalam indeks sekunder lokal, nilai kunci urutan tidak perlu unik untuk nilai kunci partisi yang diberikan. Jika ada beberapa item dalam indeks sekunder lokal yang memiliki nilai kunci urutan yang sama, operasi Query mengembalikan semua item yang memiliki nilai kunci partisi yang sama. Sebagai respons, item yang cocok tidak dikembalikan dalam urutan tertentu.

Anda dapat mengkueri indeks sekunder lokal menggunakan bacaan akhir konsisten atau bacaan sangat konsisten. Untuk menentukan jenis konsistensi yang Anda inginkan, gunakan parameter ConsistentRead operasi Query. Bacaan sangat konsisten dari indeks sekunder lokal selalu mengembalikan nilai terbaru yang diperbarui. Jika kueri perlu mengambil atribut tambahan dari tabel dasar, atribut tersebut akan konsisten dengan indeks.

{
    "TableName": "Thread",
    "IndexName": "LastPostIndex",
    "ConsistentRead": false,
    "ProjectionExpression": "Subject, LastPostDateTime, Replies, Tags",
    "KeyConditionExpression": 
        "ForumName = :v_forum and LastPostDateTime between :v_start and :v_end",
    "ExpressionAttributeValues": {
        ":v_start": {"S": "2015-08-31T00:00:00.000Z"},
        ":v_end": {"S": "2015-11-31T00:00:00.000Z"},
        ":v_forum": {"S": "EC2"}
    }
}

Memindai Indeks Sekunder Lokal

Anda dapat menggunakan Scan untuk mengambil semua data dari indeks sekunder lokal. Anda harus memberikan nama tabel dasar dan nama indeks dalam permintaan. Dengan Scan, DynamoDB membaca semua data dalam indeks dan mengembalikannya ke aplikasi. Anda juga dapat meminta agar hanya sebagian data yang dikembalikan, dan data yang tersisa harus dibuang. Untuk melakukan ini, gunakan FilterExpression parameter dari ScanAPI. Untuk informasi selengkapnya, lihat Ekspresi filter untuk pemindaian.

Penulisan item dan Indeks Sekunder Lokal

DynamoDB otomatis membuat semua indeks sekunder lokal tersinkronisasi dengan tabel dasar masing-masing. Aplikasi tidak pernah menulis langsung ke indeks. Namun, Anda harus memahami implikasi dari cara DynamoDB mempertahankan indeks ini.

Saat membuat indeks sekunder lokal, Anda menentukan atribut untuk dijadikan sebagai kunci urutan untuk indeks. Anda juga menentukan jenis data untuk atribut tersebut. Artinya, setiap kali Anda menulis item ke tabel dasar, jika item tersebut mendefinisikan atribut kunci indeks, jenisnya harus cocok dengan jenis data skema kunci indeks. Dalam kasus LastPostIndex, kunci urutan LastPostDateTime dalam indeks didefinisikan sebagai jenis data String. Jika Anda mencoba menambahkan item ke tabel Thread dan menentukan jenis data yang berbeda untuk LastPostDateTime (seperti Number), DynamoDB mengembalikan ValidationException karena jenis data tidak cocok.

Tidak ada persyaratan untuk one-to-one hubungan antara item dalam tabel dasar dan item dalam indeks sekunder lokal. Bahkan, perilaku ini dapat menguntungkan untuk banyak aplikasi.

Tabel dengan banyak indeks sekunder lokal menimbulkan biaya lebih tinggi untuk aktivitas tulis dibandingkan tabel dengan lebih sedikit indeks. Untuk informasi selengkapnya, lihat Pertimbangan throughput yang disediakan untuk Indeks Sekunder Lokal.

Pertimbangan throughput yang disediakan untuk Indeks Sekunder Lokal

Saat membuat tabel di DynamoDB, Anda menyediakan unit kapasitas baca dan tulis untuk beban kerja tabel yang diharapkan. Beban kerja tersebut mencakup aktivitas baca dan tulis pada indeks sekunder lokal tabel.

Untuk melihat tarif saat ini untuk kapasitas throughput yang disediakan, lihat Harga Amazon DynamoDB.

Unit kapasitas baca

Saat Anda mengkueri indeks sekunder lokal, jumlah unit kapasitas baca yang digunakan bergantung pada cara data diakses.

Seperti kueri tabel, kueri indeks dapat menggunakan bacaan akhir konsisten atau bacaan sangat konsisten, tergantung pada nilai ConsistentRead. Satu bacaan sangat konsisten menghabiskan satu unit kapasitas baca; bacaan akhir konsisten hanya menghabiskan setengahnya. Jadi, dengan memilih bacaan akhir konsisten, Anda dapat mengurangi biaya unit kapasitas baca Anda.

Untuk kueri indeks yang hanya meminta kunci indeks dan atribut yang diproyeksikan, DynamoDB menghitung aktivitas baca yang disediakan dengan cara yang sama seperti kueri terhadap tabel. Satu-satunya hal yang membedakan adalah penghitungan didasarkan pada ukuran entri indeks, bukan ukuran item dalam tabel dasar. Jumlah unit kapasitas baca adalah jumlah dari semua ukuran atribut yang diproyeksikan di semua item yang dikembalikan; hasilnya kemudian dibulatkan ke batas 4 KB berikutnya. Untuk informasi selengkapnya tentang cara DynamoDB menghitung penggunaan throughput yang disediakan, lihat DynamoDB menyediakan mode kapasitas.

Untuk kueri indeks yang membaca atribut yang tidak diproyeksikan ke indeks sekunder lokal, DynamoDB perlu mengambil atribut tersebut dari tabel dasar, selain membaca atribut yang diproyeksikan dari indeks. Pengambilan ini terjadi saat Anda menyertakan atribut yang tidak diproyeksikan dalam parameter Select atau ProjectionExpression operasi Query. Pengambilan menyebabkan latensi tambahan dalam respons kueri, dan juga menimbulkan biaya throughput yang disediakan lebih tinggi: Selain pembacaan dari indeks sekunder lokal yang dijelaskan sebelumnya, Anda dikenakan biaya untuk unit kapasitas baca untuk setiap item tabel dasar yang diambil. Biaya ini untuk pembacaan setiap item dari tabel, bukan hanya atribut yang diminta.

Ukuran maksimum hasil yang dikembalikan oleh operasi Query adalah 1 MB. Ini termasuk ukuran semua nama dan nilai atribut di semua item yang dikembalikan. Namun, jika Kueri terhadap indeks sekunder lokal menyebabkan DynamoDB mengambil atribut item dari tabel dasar, ukuran maksimum data dalam hasil mungkin lebih rendah. Dalam hal ini, ukuran hasil adalah jumlah dari:

Menggunakan rumus ini, ukuran maksimum hasil yang dikembalikan oleh operasi Kueri masih 1 MB.

Misalnya, pertimbangkan tabel tempat ukuran setiap item adalah 300 byte. Ada indeks sekunder lokal di tabel itu, tetapi hanya 200 byte dari setiap item yang diproyeksikan ke dalam indeks. Sekarang anggaplah Anda Query indeks ini, bahwa kueri memerlukan pengambilan tabel untuk setiap item, dan kueri mengembalikan 4 item. DynamoDB merangkum berikut ini:

Oleh karena itu, ukuran total data dalam hasil adalah 20 KB.

Unit kapasitas tulis

Saat item dalam tabel ditambahkan, diperbarui, atau dihapus, memperbarui indeks sekunder lokal akan menggunakan unit kapasitas tulis yang disediakan untuk tabel tersebut. Total biaya throughput yang disediakan untuk penulisan adalah jumlah unit kapasitas tulis yang digunakan dengan menulis ke tabel dan yang digunakan dengan memperbarui indeks sekunder lokal.

Biaya tulis item ke indeks sekunder lokal tergantung pada beberapa faktor:

Semua faktor ini mengasumsikan bahwa ukuran setiap item dalam indeks kurang dari atau sama dengan ukuran item 1 KB untuk menghitung unit kapasitas tulis. Entri indeks yang lebih besar memerlukan unit kapasitas tulis tambahan. Anda dapat meminimalkan biaya penulisan dengan mempertimbangkan atribut yang perlu dikembalikan oleh kueri dan hanya memproyeksikan atribut tersebut ke dalam indeks.

Pertimbangan penyimpanan untuk Indeks Sekunder Lokal

Saat aplikasi menulis item ke tabel, DynamoDB otomatis menyalin subset atribut yang benar ke indeks sekunder lokal tempat atribut tersebut akan muncul. AWS Akun Anda dikenakan biaya untuk penyimpanan item di tabel dasar dan juga untuk penyimpanan atribut dalam indeks sekunder lokal apa pun di tabel itu.

Jumlah ruang yang digunakan oleh item indeks adalah jumlah dari berikut ini:

Untuk memperkirakan kebutuhan penyimpanan indeks sekunder lokal, Anda dapat memperkirakan ukuran rata-rata item dalam indeks lalu mengalikannya dengan jumlah item di index.

Jika tabel berisi item dengan atribut tertentu tidak ditentukan, tetapi atribut tersebut didefinisikan sebagai kunci urutan indeks, maka DynamoDB tidak menulis data apa pun untuk item tersebut ke indeks.

Kumpulan item dalam Indeks Sekunder Lokal

Di DynamoDB, kumpulan item adalah grup item yang memiliki nilai kunci partisi yang sama dalam tabel dan semua indeks sekunder lokalnya. Dalam contoh yang digunakan di seluruh bagian ini, kunci partisi untuk tabel Thread adalah ForumName, dan kunci partisi untuk LastPostIndex juga ForumName. Semua item tabel dan indeks dengan ForumName yang sama adalah bagian dari kumpulan item yang sama. Misalnya, di tabel Thread dan indeks sekunder lokal LastPostIndex, terdapat kumpulan item untuk forum EC2 dan kumpulan item yang berbeda untuk forum RDS.

Diagram berikut menunjukkan kumpulan item untuk forum S3.

Dalam diagram ini, kumpulan item terdiri dari semua item di Thread dan LastPostIndex dengan nilai kunci partisi ForumName-nya adalah "S3". Jika terdapat indeks sekunder lokal lainnya di tabel, item apa pun dalam indeks tersebut dengan ForumName yang sama dengan "S3" juga akan menjadi bagian dari kumpulan item.

Anda dapat menggunakan salah satu operasi berikut di DynamoDB untuk menampilkan informasi tentang kumpulan item:

Masing-masing operasi ini mendukung parameter ReturnItemCollectionMetrics. Jika mengatur parameter ini ke SIZE, Anda dapat melihat informasi tentang ukuran setiap kumpulan item dalam indeks.

{
    ItemCollectionMetrics: {
        ItemCollectionKey: {
            ForumName: "EC2"
        },
        SizeEstimateRangeGB: [0.0, 1.0]
    }
}

Batas ukuran kumpulan item

Ukuran maksimum kumpulan item apa pun untuk tabel yang memiliki satu atau beberapa indeks sekunder lokal adalah 10 GB. Ini tidak berlaku untuk kumpulan item dalam tabel tanpa indeks sekunder lokal, dan juga tidak berlaku untuk kumpulan item dalam indeks sekunder global. Hanya tabel yang memiliki satu atau beberapa indeks sekunder lokal yang terpengaruh.

Jika kumpulan item melebihi batas 10 GB, DynamoDB mengembalikan ItemCollectionSizeLimitExceededException, dan Anda tidak akan bisa menambahkan lebih banyak item ke kumpulan item atau menambah ukuran item yang ada di kumpulan item. (Operasi baca dan tulis yang mengecilkan ukuran kumpulan item masih diperbolehkan.) Anda masih dapat menambahkan item ke kumpulan item lain.

Untuk mengurangi ukuran kumpulan item, Anda dapat melakukan salah satu berikut ini:

Ketika ukuran total kumpulan item turun di bawah 10 GB, Anda dapat menambahkan item dengan nilai kunci partisi yang sama sekali lagi.

Sebagai praktik terbaik, sebaiknya Anda melengkapi aplikasi Anda untuk memantau ukuran kumpulan item Anda. Salah satu cara untuk melakukannya adalah dengan mengatur parameter ReturnItemCollectionMetrics ke SIZE setiap kali Anda menggunakan BatchWriteItem, DeleteItem, PutItem, atau UpdateItem. Aplikasi Anda akan memeriksa objek ReturnItemCollectionMetrics di output dan mencatat pesan kesalahan setiap kali kumpulan item melebihi batas yang ditentukan pengguna (8 GB, misalnya). Menetapkan batas kurang dari 10 GB akan memberi sistem peringatan dini sehingga Anda mengetahui bahwa kumpulan item mendekati batas, dan Anda dapat melakukan tindakan terhadap hal tersebut.

Kumpulan dan partisi item

Di tabel dengan satu atau beberapa indeks sekunder lokal, masing-masing kumpulan item disimpan dalam satu partisi. Ukuran total kumpulan item tersebut terbatas pada kemampuan partisi itu: 10 GB. Untuk aplikasi yang model datanya menyertakan kumpulan item yang ukurannya tidak dibatasi, atau jika Anda memperkirakan beberapa kumpulan item akan bertambah melebihi 10 GB di masa mendatang, Anda sebaiknya mempertimbangkan untuk menggunakan indeks sekunder global.

Anda harus merancang aplikasi Anda sehingga data tabel didistribusikan secara merata ke seluruh nilai kunci partisi yang berbeda. Untuk tabel dengan indeks sekunder lokal, aplikasi Anda tidak boleh membuat "hot spot" aktivitas baca dan tulis dalam satu kumpulan item pada satu partisi.