DATA ON AWS
Usage Notes on DynamoDB
This article was last updated on 5 September 2021.
DynamoDB is Amazon’s contribution to the world of NoSQL. It was released about eight years ago. It is a fully managed NoSQL database — essentially a key-value store with some document database features.
A quick note on “fully managed.”
Keep in mind that with Amazon’s shared responsibility model, the consumer doesn’t need to worry about the hypervisor, fault tolerance, hardware failure, networking in the data centre but is required to take care of the security, encryption-at-rest, disaster recovery (by doing multi-AZ or multi-region deployments) and backups.
Read more about the Shared Responsibility model.
Some say that DynamoDB isn’t a database at all. Rather, it is a highly durable, partitioned B-tree data structure in the cloud. This definition somehow reminds of Shashi Tharoor’s tweet defining a journalist on TV
Exasperating farrago of distortions, misrepresentations and outright lies being broadcast by an unprincipled showman masquerading as a journalist
DynamoDB might be masquerading as a database, according to some. Unwelcome digression. Anyway, tables are central to DynamoDB. Good Data Modelling is essential. DynamoDB flourishes when the loads are predictable. Doesn’t work well with bursts of load. Let’s look at some underlying basics of DynamoDB.
Basics of DynamoDB
- Data is stored in a table — which is made up of items. Each item contains attributes. Each item can have different attributes. Hence, schemaless.
- The table is the top-level structure within DynamoDB — the performance is managed at the table level.
- The scope of a table is within a region. Creating two tables with the same name in two different regions under the same account is possible.
- Data Types supported — scalar, set, and document. Read more in AWS documentation.
- Predefinition of throughput is required while creating a table. Throughput is defined by two resource controls — WCUs and RCUs.