Continuing with the post on DynamoDB Basics, Part 1, we are going to see the operations you can execute over the DynamoDB table and the features you can use the improve the performance and availability, let's start.
Read operations
There are two operations, Query and Scan to perform over the main table or secondary Indexes, the detail of each operation are:
Query: You need the partition key to choose the partition and execute the operation over it. You can use the sort key and add filters to get specific data. It reads multiple items that have the same partition key and satisfies the sort key constraint when it is present. The filters are constraints over the attributes and these are validated after the query operation.
A single Query operation will read up 1 MB of data, you can set the maximum number of items also. When the query result size is more than 1 MB the Query results are divided into pages of data that are 1 MB in size or less.
Scan: You don’t need the partition key to perform it, you can add filters to define constraints over the attributes including the primary key (PK + SK) but these are validated after the scan operations which means it is an expensive operation because read all items in each partition and then apply the filters. When the total number of scanned items exceeds the maximum dataset size limit of 1 MB, the scan stops and the results are returned to the user as a LastEvaluatedKey value to continue the scan in a subsequent operation.
Write operations
Create, Update, and Delete are operations you can execute ONLY over the DynamoDB main table. If the table has a secondary index, then DynamoDB performs the write operation over the index. When you create an item with an existing primary key DynamoDB updates the item in the table, you can add a conditional to execute it only if there is not already an item with the same primary key. You cannot update the primary key of one item, you need first delete it and create with the new primary key, DynamoDB does not support updating the primary key in one shot.
Provisioned Capacity
You can set up on-demand provisioned capacity to pay just for the write and query operations you perform or provisioned to specify the number of data reads and writes per second that you require for your application. On-demand is more expensive than provisioned, select provisioned to save on throughput costs if you can reliably estimate your application's throughput requirements. Both are using the Write Capacity Units (WCU) and Read Capacity Unit (RCU) to execute operations over DynamoDB main table and index.
Read Capacity Unit (RCU)
All the read operations over the DynamoDB main table and secondary indexes spend read capacity units, this a read per second. The RCU is shared between the main table and local secondary index, for the global secondary index you can set up RCU. One RCU represents one strongly consistent read request per second, or two eventually consistent read requests per second, for an item up to 4 KB in size. Two RCU represent one transactional read for items up to 4 KB. If you need to read an item that is larger than 4 KB, DynamoDB needs additional read request units.
The results returned by the Query operation could be item collection or single item depending on the query expression used, in both case the number of RCU depends on the size of the result not the number of items, for example, query operation using the partition key return 4 items (all with the same partition key), each item size is 1 KB, total size is 4 KB for strong consistent read you need 1 RCU or half for eventually consistent read requests
Write Capacity Unit (WCU)
All the write operations are over the DynamoDB main table only, DynamoDB executes write operations over secondary indexes automatically. One WCU represents one write per second for an item up to 1 KB in size. If you need to write an item that is larger than 1 KB, DynamoDB must consume additional write capacity units. The total number of write capacity units required depends on the item size not the number of items impacted. For example, if your item size is 2 KB, you require 2 write capacity units to sustain one write request per second. DynamoDB spends more WCU when need to project the item attributes from the main table to the secondary index, you will need more WCU.
Eventually Consistent Reads
When you read data from a DynamoDB table, the response might not reflect the results of a recently completed write operation. The response might include some stale data. If you repeat your read request after a short time, the response should return the latest data. By default, the read operations use eventually consistent read. The read operation with eventually consistently spends less RCU, you can perform two reads per second for items up to 4KB.
Strongly Consistent Reads
When you request a strongly consistent read, DynamoDB returns a response with the most up-to-date data, reflecting the updates from all prior write successful operations. Strongly consistent reads use more throughput capacity than eventually consistent reads, you can perform 1 request per second for items up to 4KB, and may have higher latency than eventually consistent reads.
Transactional
You can group multiple actions together and submit them as a single all-or-nothing TransactWriteItems or TransactGetItems operation.
TransactWriteItems is a synchronous and idempotent write operation that groups up to 25 write actions in a single all-or-nothing operation. These actions can target up to 25 distinct items in one or more DynamoDB tables within the same AWS account and in the same Region. The aggregate size of the items in the transaction cannot exceed 4 MB.
TransactGetItems is a synchronous read operation that groups up to 25 Get actions together. These actions can target up to 25 distinct items in one or more DynamoDB tables within the same AWS account and Region. The aggregate size of the items in the transaction can't exceed 4 MB.
Global Table
DynamoDB replicates the data between the availability zone of the aws region, to replicate the data between the aws region you need Global Table. DynamoDB replicates write operations from the main table and secondary index from one region to another region to improve the availability of your data. Replicate data between regions and also spend Write Capacity Unit.
Stream
All the write operations over DynamoDB table generate a stream with detail of the old and new items, or only old or new items, you can choose. Behind AWS DynamoDB table there is a Kinesis Data Stream managed by AWS where all the stream is going on, so you can integrate the lambda function with the source event stream to read the stream.
The above elements are the most important, and most of them are tools used to DynamoDB design data models and build client applications to perform read and write operations, hope this post can help you to understand DynamoDB.
References
DynamoDB Developer Guide https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html
DynamoDB Actions https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations_Amazon_DynamoDB.html
Alex DeBrie Post The What, Why, and When of Single-Table Design with DynamoDB https://www.alexdebrie.com/posts/dynamodb-single-table/
Top comments (0)