DynamoDB Basic - Part 1: Introduction DynamoDB

1. Core Components of Amazon DynamoDB

• Table: Like other database systems, DynamoDB stores data in tables. A table is a collection of items.
• Item: Each table contains zero or more items. Items in DynamoDB are similar to the concept of rows in relational databases, records, or tuples in other database systems. In DynamoDB, there is no limit to the number of items that can be stored in a table.
• Attribute: Each item includes one or more attributes. An attribute is a basic data element that does not need to be broken down further. Attributes in DynamoDB are similar to columns in other database systems in many ways.

2. Primary Key

When creating a table, you must specify the primary key of the table in addition to the table name. The primary key uniquely identifies each item in the table, ensuring that no two items can have the same key. DynamoDB supports two different types of primary keys: the partition key and the composite primary key.

The partition key is a simple primary key consisting of an attribute called the partition key. DynamoDB uses the value of the partition key as input to the internal hash, and the output from the hash defines the partition (physical memory inside DynamoDB) in which the item will be stored. In a table with only a partition key, no two items can have the same partition key value.

The composite primary key, on the other hand, consists of the partition key and a sort key. DynamoDB uses the partition key value as input to the internal hash, and the output from the hash defines the partition (physical memory inside DynamoDB) in which the item will be stored. All items with the same partition key value are stored together, in sorted order by the sort key value. In a table with a partition key and a sort key, multiple items can have the same partition key value, but those items must have different sort key values. The composite primary key gives you more flexibility when querying data.

3. Secondary Indexes

You can create one or more Secondary Indexes on a table.
Secondary Indexes allow querying data in the table with different keys from the original partition key and sorting of the table. With DynamoDB, data query operations are much faster and more cost-effective than scanning.
Here is an example DynamoDB table:

If we perform a data query operation, we can find data by the value of the Partition Key and Sort Key.

If we perform a data scan operation, we will scan the entire table and then filter by any attribute. (When implementing the filter, we still have to spend the cost of scanning the entire table.)

DynamoDB doesn't force you to use indexes, but they do give your applications more flexibility when it comes to data queries. After creating a Secondary Index on the table, you can read data from the index in the same way as reading data from the table.
DynamoDB supports two types of indexes:

Global secondary indexes, which have partition keys and sort keys that may be different from indexes on the table.

Local secondary indexes, which have the same partition key as the table but have a different sort key.

Each table in DynamoDB has a maximum of 20 Global secondary indexes (the default limit) and 5 Local secondary indexes.

4. Naming Rules and Data Types

Tables, properties, and other objects in DynamoDB must have names. The following are the naming rules for DynamoDB:

All names must be encoded with UTF-8 and be case sensitive.
Table names and index names must be between 3 to 255 characters and can only contain the following characters:

• a to z
• A to Z
• 0 to 9
• _(underscore)
• (hyphen)
• . (dot)

Attribute names must be at least one character long, but no longer than 64 KB.

The following are exceptions. These property names cannot be longer than 255 characters:

• The key name of the Secondary Index partition.
• Secondary Index sorts the key names.
• The name of any user-specified expected properties (applies only to local SecondaryIndexes).

DynamoDB supports many different data types for attributes in the table, which can be classified as follows:

• Scalar types: A scalar type can represent only one value. Scalar types are numeric, string, binary, Boolean, and null.
• Document types: A document type can represent a complex structure with nested properties, such as a JSON document. The document types are list and map.
• Set types: A set type can represent many scalar values. Set types are string set, numeric set, and binary set.

5. Read Consistency

Eventually Consistent Reads

• When you read data from a DynamoDB table, the response may not reflect the result of a recently completed write operation.
• Responses may include some stale data.
• If you repeat your read request after a short time, the response will return the latest data.

Strongly Consistent Reads

When you request Strongly Consistent Reads, DynamoDB returns a response with the most up-to-date data, reflecting updates from all previous writes that were successful. However, this consistency comes with some downsides:

• Strongly Consistent Reads may not be available if there are network problems or outages. In this scenario, DynamoDB may return server error (HTTP 500).
• Strongly Consistent Reads may have higher latency than eventually consistent reads.
• Global secondary indexes are not supported Strongly Consistent Reads.
• Strongly Consistent Reads uses double throughput capacity than eventually consistent reads.

6. Read/Write Capacity Mode

On-Demand Mode

• Amazon DynamoDB on-demand is a flexible payment option capable of serving thousands of requests per second without capacity planning. DynamoDB on-demand offers pay-on-demand for read and write requests so you only pay for what you use.
• When you select on-demand mode, DynamoDB instantly responds to your workloads as they increase or decrease to whatever traffic level was previously reached. If the workload's throughput reaches a new peak, DynamoDB adapts quickly to accommodate the workload. Tables using on-demand mode offer the same single-digit millisecond latency, service level agreement (SLA) commitment, and security that DynamoDB already provides. You can choose on demand for both new and existing tables, and you can continue to use existing DynamoDB APIs without code changes.
• On-Demand mode is a good choice if any of the following are true:
  • You create a new board with an unknown workload.
  • You have unpredictable application traffic.
  • You just love the ease of paying for what you use.

Provisioned Mode

• If you select provisioned mode, you specify the number of reads and writes per second that you require for your application. You can use auto-scaling to automatically adjust your table's provisioned capacity in response to changes in traffic. This helps you manage your DynamoDB usage to stay at or below the specified request rate for cost predictability.
• The mode provided is a good option if any of the following are true:
  • You have predictable application traffic.
  • You run applications with consistent or incremental traffic.
  • You can forecast capacity requirements to control costs.