DynamoDB Operations Overview

Will discuss the basic DynamoDB operations such as create table, and CRUD operations such as insert, read, update and delete.

Creating Table

Can create table using Management Console or CreateTable API.

Insert Data

Can use the PutItem or BatchWriteItem APIs.

PutItem API is idempotent.

Read Data

Can use the GetItem, BatchGetItem, or, if composite primary keys are enabled and in use, the Query API to retrieve the item(s) you added to the table.

You may also use the Scan API to scan entire table without using any keys.

Delete Data

Can use DeleteItem API.

DeleteItem API is idempotent.

Query API

Gets one or more items using the table primary key (and optionally sort key), or from a secondary index using the index key. You can narrow the scope of the query on a table by using comparison operators or expressions. You can also filter the query results using filters on non-key attributes.

By default all attributes are returned. You can use a ProjectionExpression parameter to specify what attributes need to be returned.

Supports both strong and eventual consistency reads. Default is eventual consistent.

A single response has a size limit of 1 MB.

Query results are always sorted by the sort key. Default order is ascending, but this can be reversed by setting ScanIndexForward parameter to false.  

Scan API

Gets all items and attributes by performing a full scan across the table or a secondary index. You can limit the return set by specifying filters against one or more attributes, but still ALL DATA is read (and charged).

Scans can be done in parallel after splitting them into segments, for improving performance.

By default all attributes are returned. You can use a ProjectionExpression parameter to specify what attributes need to be returned.

Query is always preferred over scan if possible (based on efficiency as scan dumps the whole table always).

BatchGetItem API

A BatchGetItem request can

1. retrieve upto 16 MB of data.

2. contain upto 100 items

3. retrieve items from multiple tables.

Consistency model of Amazon DynamoDB Reads

When reading data from Amazon DynamoDB, users can specify whether they want the read to be eventually consistent or strongly consistent.

1. Eventually Consistent Reads (Default)

   1. maximizes your read throughput.

   2. However, a read might not reflect the results of a recently completed write.

   3. Consistency across all copies of data is usually reached within a second.

2. Strongly Consistent Reads

   1. returns a result that reflects all writes that received a successful response prior to the read.

Note: Pricing (throughput provisioning) is different for eventually consistent or strongly consistent reads. See pricing (throughput provisioning) page for details.

Important Notes (Exam Tips)

1. Use Query, Get or BatchGetItems API instead of Scan when possible.

2. BETWEEN and NOT BETWEEN operators has higher precedence over AND/OR. Read more here.   

3. For critical applications such as banking, it might be better to use conditional update than atomic counter, as conditional update is idempotent and atomic counter is not.

4. DynamoDB does not support complex relational queries (e.g. joins) or complex transactions.