DynamoDB caching

To manage write spikes, lower read capacity requirements, and avoid the need to scale a DynamoDB database, use a cache.

Side cache

When using a cache for a backend data store, a side-cache is a common approach. Redis and Memcached are general-purpose caches that are decoupled from the underlying data store and can help with both read and write throughput.

Applications contain the logic needed to manage a side-cache. The cache itself has no intelligence.

For read-heavy workloads, side-caches typically follow this pattern:

1.For a given key-value pair, the application first tries to read the data from the cache. If the cache is populated with the data (cache hit), the value is returned.

2.If the desired key-value pair was not found in the cache, the application fetches the data from the underlying data store.

3.To ensure that the data is present when the application needs to fetch the data again, the key-value pair from step 2 is then written to the cache.

Read-through cache

A read-through cache sits in-line with the database. When there is a cache miss, the cache itself fetches items from the underlying data store. DAX is a read-through cache because it is API compatible with DynamoDB read APIs and caches GetItem, BatchGetItem, Scan, and Query results if they don’t currently reside in DAX.

Read-through caches are effective for read-heavy workloads.

The following steps outline the process DAX uses as a read-through cache:

1.Given a key-value pair, the application first tries to read the data from DAX. If the cache is populated with the data (cache hit), the value is returned.

2.If there was a cache miss, DAX fetches the key-value pair from DynamoDB.

3.To make the data available for subsequent reads, the key-value pair is added to the DAX cache.

4.The key-value pair is returned to the application.

Write-through cache

Similar to read-through caches, a write-through cache is transparent to the application, sits in-line with the database, and updates the cache as data is written to the underlying data store.

DAX is also a write-through cache because it caches (or updates) items with PutItem, UpdateItem, DeleteItem, and BatchWriteItem API calls as the data is written to or updated in DynamoDB. DAX is updated only if DynamoDB is successfully updated first.

The following steps outline the process for a write-through cache:

1.For a given key-value pair, the application writes to the DAX endpoint.

2.DAX intercepts the write and then writes the key-value pair to DynamoDB.

3.Upon a successful write, DAX hydrates the DAX cache with the new value so that any subsequent reads for the same key-value pair result in a cache hit. If the write is unsuccessful, the exception is returned to the application.

4.The acknowledgement of a successful write is then returned to the application.

Cache eviction

DAX handles cache evictions in three different ways. 1.There is a Time-to-Live (TTL) value that denotes the absolute period of time that an item is available in the cache. 2.When the cache is full, a DAX cluster uses a Least Recently Used (LRU) algorithm to decide which items to evict. 3.With the write-through functionality, DAX evicts older values as new values are written through DAX to help keep the DAX item cache consistent with the underlying data store using a single API call.

Vietnamese:

Side Cache – Bộ đệm phụ

Khi sử dụng bộ đệm cho hệ thống lưu trữ back-end, bộ đệm phụ (side-cache) là cách tiếp cận phổ biến. Redis và Memcached là các bộ đệm đa năng được tách rời khỏi kho lưu trữ dữ liệu cơ bản và có thể giúp cả thông lượng đọc và ghi.

Các ứng dụng chứa các toán tử cần thiết để quản lý bộ đệm phụ vì bản thân bộ đệm không có trí thông minh.

Đối với khối lượng công việc đọc lớn, bộ đệm phụ thường theo các bước bên dưới:

1- Đối với cặp key-value đã cho, ứng dụng sẽ cố đọc dữ liệu từ bộ đệm đầu tiên. Nếu bộ đệm có dữ liệu (cache-hit), giá trị được trả về.
2- Nếu không tìm thấy cặp khóa-giá trị mong muốn trong bộ đệm, ứng dụng sẽ tìm nạp dữ liệu trự tiếp từ database
3 – Để đảm bảo rằng dữ liệu tồn tại khi ứng dụng cần nạp lại dữ liệu, cặp khóa-giá trị từ bước 2 sau đó được ghi vào bộ đệm.

Read-through Cache (Bộ đệm -đọc qua)

Bộ đệm Read-through nằm giữa database và ứng dụng. Khi không tìm thấy dữ liệu trong bộ đệm (cache-miss), bộ đệm sẽ tự tìm nạp dữ liệu từ database. DAX là bộ đệm Read-through vì nó có API tương thích với các API của DynamoDB gồm Read, GetItem, BatchGetItem, Scan và Query nếu dữ liệu không có trong DAX.

Bộ đệm Read-through có hiệu quả đối với khối lượng công việc lớn.

Các bước sau phác thảo quá trình DAX sử dụng làm bộ đệm read-through:

1- Đưa ra một cặp khóa-giá trị, trước tiên ứng dụng sẽ cố đọc dữ liệu từ DAX. Nếu bộ đệm được có dữ liệu (cache-hit), giá trị được trả về.
2- Nếu không tìm thấy dữ liệu trong bộ nhớ cache, DAX sẽ tìm nạp cặp khóa-giá trị từ DynamoDB.
3- Để cung cấp dữ liệu cho các lần đọc tiếp theo, cặp khóa-giá trị được thêm vào bộ đệm DAX.
4 -Cặp khóa-giá trị được trả về ứng dụng.

Write-through cache (Bộ đệm – ghi)

Tương tự như bộ đệm đọc, bộ đệm ghi là vô hình với ứng dụng, nằm giữa cơ sở dữ liệu và ứng dụng, và cập nhật bộ đệm khi dữ liệu được ghi vào kho lưu trữ dữ liệu bên dưới.

DAX cũng là một bộ đệm ghi vì nó lưu trữ (hoặc cập nhật) các mục với các lệnh gọi API gồm PutItem, UpdateItem, DeleteItem và BatchWriteItem khi dữ liệu được ghi hoặc cập nhật trong DynamoDB. DAX chỉ được cập nhật nếu DynamoDB được cập nhật thành công trước.

Các bước sau phác thảo quá trình cho bộ đệm ghi:

1- Đối với cặp khóa-giá trị đã cho, ứng dụng ghi vào điểm cuối DAX.
2- DAX chặn việc ghi và sau đó ghi cặp khóa-giá trị vào DynamoDB.
3- Sau khi ghi thành công, DAX sẽ đồng bộ hóa bộ đệm với giá trị mới để mọi lần đọc tiếp theo cho cùng một cặp khóa-giá trị sẽ dùng đến dữ liệu trong bộ đệm. Nếu việc ghi không thành công, ngoại lệ được trả về ứng dụng.
4- Xác nhận việc ghi thành công với ứng dụng.

Loại bỏ Cache
DAX xử lý các vụ loại bỏ bộ đệm theo ba cách khác nhau.

1- Có một giá trị “thời gian tồn tại” (Time-To-Live), TTL biểu thị khoảng thời gian tuyệt đối mà một mục sẽ tồn tại trong bộ đệm.
2- Khi bộ đệm đầy, một cụm DAX sử dụng thuật toán Least Recent used (LRU) để quyết định những mục nào cần loại bỏ.
3- Với chức năng write-through, DAX loại bỏ các giá trị cũ hơn khi các giá trị mới được ghi thông qua DAX để giúp giữ các mục trong bộ đệm DAX đồng bộ dữ liệu bằng một lệnh gọi API.