GSI vs LSI di DynamoDB
Baik Global Secondary Index (GSI) maupun Local Secondary Index (LSI)
memungkinkan Anda mem-Query berdasarkan atribut yang bukan key tabel Anda.
Keduanya tidak dapat dipertukarkan — perbedaannya menentukan mana yang dibutuhkan
oleh sebuah pola.
Perbedaan yang penting
| GSI | LSI | |
|---|---|---|
| Partition key | Atribut apa pun | Sama dengan tabel |
| Sort key | Atribut apa pun | Atribut apa pun |
| Kapan dibuat | Kapan saja | Hanya saat pembuatan tabel |
| Konsistensi | Hanya eventual | Strong tersedia |
| Kapasitas | Milik sendiri | Berbagi dengan tabel |
| Propagasi penulisan | Async (eventual) | Sinkron (atomik) |
| Maks per tabel | 20 (default, bisa dinaikkan) | 5 (keras) |
| Batas partisi 10 GB | Tidak | Ya (per PK) |
Aturan praktis
- Butuh partition key berbeda (mis. mencari pesanan berdasarkan
statusalih-alihcustomer)? Anda butuh GSI — sebuah LSI tidak dapat mem-repartisi. - Butuh urutan sort kedua dalam partisi yang sama — sebuah LSI menjaga partition key tabel persis sama dan hanya menukar sort key yang berbeda — diputuskan di awal, dengan pembacaan strongly-consistent? Sebuah LSI cocok.
Pilihannya menyusut menjadi satu pertanyaan — key mana yang Anda ubah:
Partition key yang berbeda memaksa sebuah GSI; sort key yang berbeda pada partisi yang sama adalah satu-satunya kasus di mana sebuah LSI cocok.
Dalam praktiknya sebagian besar tim hampir selalu menggunakan GSI: GSI dapat ditambahkan kemudian, diskalakan secara independen, dan tidak tunduk pada batas 10 GB per partisi. Tumpangi (overload) key satu GSI untuk melayani beberapa pola — lihat single-table design.
Jika Anda menambahkan GSI untuk membunuh sebuah Scan, ingat bahwa ia memiliki kapasitas read/write sendiri. Ukur biaya tambahan itu dengan kalkulator harga, dan coba DynoTable untuk memeriksa atribut terproyeksi sebuah index sebelum Anda berkomitmen padanya.