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

# DAX: Cara kerjanya
<a name="DAX.concepts"></a>

Amazon DynamoDB Accelerator (DAX) dirancang untuk berjalan di lingkungan Amazon Virtual Private Cloud (Amazon VPC). Layanan Amazon VPC menentukan jaringan virtual yang mirip dengan pusat data tradisional. Dengan VPC, Anda dapat mengontrol rentang alamat IP, subnet, tabel rute, gateway jaringan, dan pengaturan keamanan. Anda dapat meluncurkan klaster DAX di jaringan virtual dan mengontrol akses ke klaster menggunakan grup keamanan Amazon VPC.

**catatan**  
Jika Anda membuat AWS akun setelah 4 Desember 2013, Anda sudah memiliki VPC default di setiap AWS Wilayah. VPC siap untuk langsung digunakan tanpa harus melakukan langkah konfigurasi tambahan.  
Untuk informasi selengkapnya, lihat [VPC default dan subnet default](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) di *Panduan Pengguna Amazon VPC*.

Diagram berikut menunjukkan gambaran umum tingkat tinggi DAX.

![\[Diagram alur kerja yang menunjukkan interaksi aplikasi, klien DAX, dan klaster DAX di VPC.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/dax_high_level.png)


Untuk membuat klaster DAX, Anda menggunakan Konsol Manajemen AWS. Kecuali Anda menentukan lain, klaster DAX berjalan dalam VPC default Anda. Untuk menjalankan aplikasi, Anda meluncurkan instans Amazon EC2 ke Amazon VPC Anda. Kemudian Anda men-deploy aplikasi (dengan klien DAX) pada instans EC2.

Saat runtime, klien DAX mengarahkan semua permintaan API DynamoDB aplikasi Anda ke klaster DAX. Jika DAX dapat memproses salah satu permintaan API ini secara langsung, tindakan tersebut akan dilakukan. Jika tidak, DAX akan meneruskan permintaan ke DynamoDB. 

Terakhir, klaster DAX mengembalikan hasil ke aplikasi Anda.

**Topics**
+ [Cara DAX memproses permintaan](#DAX.concepts.request-processing)
+ [Cache item](#DAX.concepts.item-cache)
+ [Cache kueri](#DAX.concepts.query-cache)

## Cara DAX memproses permintaan
<a name="DAX.concepts.request-processing"></a>

Klaster DAX terdiri atas satu atau beberapa simpul. Setiap simpul menjalankan instans perangkat lunak caching DAX sendiri. Salah satu simpul berfungsi sebagai simpul primer untuk klaster. Simpul tambahan (jika ada) berfungsi sebagai replika baca. Untuk informasi selengkapnya, lihat [Simpul](DAX.concepts.cluster.md#DAX.concepts.nodes).

Aplikasi Anda dapat mengakses DAX dengan menentukan titik akhir untuk klaster DAX. Perangkat lunak klien DAX bekerja dengan titik akhir klaster untuk melakukan penyeimbangan beban dan perutean cerdas.

### Operasi baca
<a name="DAX.concepts.request-processing-read"></a>

DAX dapat merespons panggilan API berikut:
+ `GetItem`
+ `BatchGetItem`
+ `Query`
+ `Scan`

Jika permintaan menentukan *bacaan akhir konsisten* (perilaku default), permintaan akan mencoba membaca item dari DAX:
+ Jika DAX memiliki item yang tersedia (*hit cache*), DAX mengembalikan item ke aplikasi tanpa mengakses DynamoDB.
+ Jika DAX tidak memiliki item yang tersedia (*cache miss*), DAX meneruskan permintaan ke DynamoDB. Ketika menerima respons dari DynamoDB, DAX mengembalikan hasil ke aplikasi. Namun, DAX juga menulis hasil ke cache pada simpul primer.

**catatan**  
Jika ada replika baca di klaster, DAX otomatis menyinkronkan replika dengan simpul primer. Untuk informasi selengkapnya, lihat [Klaster](DAX.concepts.cluster.md#DAX.concepts.clusters).

Jika permintaan menentukan *bacaan sangat konsisten*, DAX meneruskan permintaan ke DynamoDB. Hasil dari DynamoDB tidak di-cache di DAX. Sebaliknya, hasil akan kembali ke aplikasi.

### Operasi tulis
<a name="DAX.concepts.request-processing-write"></a>

Operasi API DAX berikut dianggap "write-through":
+ `BatchWriteItem`
+ `UpdateItem`
+ `DeleteItem`
+ `PutItem`

Dengan operasi tersebut, data terlebih dahulu ditulis ke tabel DynamoDB, lalu ke klaster DAX. Operasi ini hanya akan berhasil jika data berhasil ditulis di tabel *dan* DAX.

### Operasi lainnya
<a name="DAX.concepts.request-processing-other"></a>

DAX tidak mengenali operasi DynamoDB apa pun untuk mengelola tabel (seperti `CreateTable`, `UpdateTable`, dan sebagainya). Jika perlu melakukan operasi tersebut, aplikasi Anda harus mengakses DynamoDB langsung, bukan menggunakan DAX.

Untuk informasi detail tentang konsistensi DAX dan DynamoDB, lihat [Model konsistensi DAX dan DynamoDB](DAX.consistency.md).

Untuk informasi tentang cara kerja transaksi di DAX, lihat [Menggunakan transaksional di APIs DynamoDB Accelerator (DAX)](transaction-apis.md#transaction-apis-dax).

### Pembatasan laju permintaan
<a name="DAX.concepts.request-processing-throttling"></a>

Jika jumlah permintaan yang dikirim ke DAX melebihi kapasitas node, DAX membatasi tingkat penerimaan permintaan tambahan dengan mengembalikan file. [ThrottlingException](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/CommonErrors.html#CommonErrors-ThrottlingException) DAX terus mengevaluasi pemanfaatan CPU Anda untuk menentukan volume permintaan yang dapat diproses sekaligus mempertahankan keadaan klaster yang sehat.

Anda dapat memantau [ThrottledRequestCount metrik](dax-metrics-dimensions-dax.md) yang diterbitkan DAX ke Amazon. CloudWatch Jika melihat pengecualian ini secara rutin, Anda harus mempertimbangkan untuk [menaikkan skala klaster](DAX.cluster-management.md#DAX.cluster-management.scaling).

## Cache item
<a name="DAX.concepts.item-cache"></a>

DAX mengelola *cache item* untuk menyimpan hasil dari operasi `GetItem` dan `BatchGetItem`. Item dalam cache mewakili data akhir konsisten dari DynamoDB dan disimpan berdasarkan nilai kunci primer.

Ketika aplikasi mengirimkan permintaan `GetItem` atau `BatchGetItem`, DAX mencoba membaca item langsung dari cache item menggunakan nilai kunci yang ditentukan. Jika item ditemukan (hit cache), DAX segera mengembalikannya ke aplikasi. Jika item tidak ditemukan (cache miss), DAX mengirimkan permintaan ke DynamoDB. DynamoDB memproses permintaan menggunakan bacaan akhir konsisten dan mengembalikan item ke DAX. DAX menyimpannya dalam cache item dan kemudian mengembalikannya ke aplikasi.

Cache item memiliki pengaturan Time to Live (TTL) default, yaitu 5 menit. DAX memberikan timestamp untuk setiap item yang ditulis ke cache item. Item akan kedaluwarsa jika berada dalam cache lebih lama dari pengaturan TTL. Jika Anda mengeluarkan permintaan `GetItem` pada item kedaluwarsa, hal ini dianggap sebagai cache miss dan DAX mengirimkan permintaan `GetItem` ke DynamoDB.

**catatan**  
Anda dapat menentukan pengaturan TTL untuk cache item ketika membuat klaster DAX baru. Untuk informasi selengkapnya, lihat [Mengelola klaster DAX](DAX.cluster-management.md).

DAX juga menyimpan daftar cache item yang paling lama tidak digunakan (LRU). Daftar LRU melacak saat item pertama kali ditulis ke cache dan saat item terakhir dibaca dari cache. Jika cache item penuh, DAX menghapus item lama (meskipun belum kedaluwarsa) untuk menyediakan ruang bagi item baru. Algoritma LRU selalu diaktifkan untuk cache item dan tidak dapat dikonfigurasi pengguna.

Jika Anda menentukan nol sebagai pengaturan TTL *cache item*, item di dalam cache item hanya akan diperbarui karena pengosongan LRU atau operasi ["write-through"](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.concepts.html#DAX.concepts.request-processing-write).

Untuk informasi selengkapnya tentang konsistensi cache item di DAX, lihat [Perilaku cache item DAX](DAX.consistency.md#DAX.consistency.item-cache).

## Cache kueri
<a name="DAX.concepts.query-cache"></a>

DAX juga mengelola *cache kueri* untuk menyimpan hasil dari operasi `Query` dan `Scan`. Item dalam cache ini mewakili set hasil dari kueri dan pemindaian pada tabel DynamoDB. Set hasil ini disimpan berdasarkan nilai parameter.

Ketika aplikasi mengirimkan permintaan `Query` atau `Scan`, DAX mencoba untuk membaca set hasil pencocokan dari cache kueri menggunakan nilai parameter tertentu. Jika set hasil ditemukan (hit cache), DAX segera mengembalikannya ke aplikasi. Jika set hasil tidak ditemukan (cache miss), DAX mengirimkan permintaan ke DynamoDB. DynamoDB memproses permintaan menggunakan bacaan akhir konsisten dan mengembalikan set hasil ke DAX. DAX menyimpannya dalam cache kueri dan kemudian mengembalikannya ke aplikasi.

**catatan**  
Anda dapat menentukan pengaturan TTL untuk cache kueri ketika membuat klaster DAX baru. Untuk informasi selengkapnya, lihat [Mengelola klaster DAX](DAX.cluster-management.md).

DAX juga mengelola daftar LRU untuk cache kueri. Daftar tersebut melacak saat set hasil pertama kali ditulis ke cache dan saat hasil terakhir dibaca dari cache. Jika cache kueri penuh, DAX menghapus set hasil lama (meskipun belum kedaluwarsa) untuk menyediakan ruang bagi set hasil baru. Algoritma LRU selalu diaktifkan untuk cache kueri dan tidak dapat dikonfigurasi pengguna.

Jika Anda menentukan nol sebagai pengaturan TTL *cache kueri*, respons kueri tidak akan di-cache.

Untuk informasi selengkapnya tentang konsistensi cache kueri di DAX, lihat [Perilaku cache kueri DAX](DAX.consistency.md#DAX.consistency.query-cache).