DynamoDB - Overview
DynamoDB allows users to create databases capable of storing and retrieving any amount of data, and serving any amount of traffic. It automatically distributes data and traffic over servers to dynamically manage each customer's requests, and also maintains fast performance.
DynamoDB vs. RDBMS
DynamoDB uses a NoSQL model, which means it uses a non-relational system. The following table highlights the differences between DynamoDB and RDBMS −
| Common Tasks |
RDBMS |
DynamoDB |
| Connect to the Source |
It uses a persistent connection and SQL commands. |
It uses HTTP requests and API operations |
| Create a Table |
Its fundamental structures are tables, and must be defined. |
It only uses primary keys, and no schema on creation. It uses various data sources. |
| Get Table Info |
All table info remains accessible |
Only primary keys are revealed. |
| Load Table Data |
It uses rows made of columns. |
In tables, it uses items made of attributes |
| Read Table Data |
It uses SELECT statements and filtering statements. |
It uses GetItem, Query, and Scan. |
| Manage Indexes |
It uses standard indexes created through SQL statements. Modifications to it occur automatically on table changes. |
It uses a secondary index to achieve the same function. It requires specifications (partition key and sort key). |
| Modify Table Data |
It uses an UPDATE statement. |
It uses an UpdateItem operation. |
| Delete Table Data |
It uses a DELETE statement. |
It uses a DeleteItem operation. |
| Delete a Table |
It uses a DROP TABLE statement. |
It uses a DeleteTable operation. |
Advantages
The two main advantages of DynamoDB are scalability and flexibility. It does not force the use of a particular data source and structure, allowing users to work with virtually anything, but in a uniform way.
Its design also supports a wide range of use from lighter tasks and operations to demanding enterprise functionality. It also allows simple use of multiple languages: Ruby, Java, Python, C#, Erlang, PHP, and Perl.
Limitations
DynamoDB does suffer from certain limitations, however, these limitations do not necessarily create huge problems or hinder solid development.
You can review them from the following points −
Capacity Unit Sizes − A read capacity unit is a single consistent read per second for items no larger than 4KB. A write capacity unit is a single write per second for items no bigger than 1KB.
Provisioned Throughput Min/Max − All tables and global secondary indices have a minimum of one read and one write capacity unit. Maximums depend on region. In the US, 40K read and write remains the cap per table (80K per account), and other regions have a cap of 10K per table with a 20K account cap.
Provisioned Throughput Increase and Decrease − You can increase this as often as needed, but decreases remain limited to no more than four times daily per table.
Table Size and Quantity Per Account − Table sizes have no limits, but accounts have a 256 table limit unless you request a higher cap.
Secondary Indexes Per Table − Five local and five global are permitted.
Projected Secondary Index Attributes Per Table − DynamoDB allows 20 attributes.
Partition Key Length and Values − Their minimum length sits at 1 byte, and maximum at 2048 bytes, however, DynamoDB places no limit on values.
Sort Key Length and Values − Its minimum length stands at 1 byte, and maximum at 1024 bytes, with no limit for values unless its table uses a local secondary index.
Table and Secondary Index Names − Names must conform to a minimum of 3 characters in length, and a maximum of 255. They use the following characters: AZ, a-z, 0-9, “_”, “-”, and “.”.
Attribute Names − One character remains the minimum, and 64KB the maximum, with exceptions for keys and certain attributes.
Reserved Words − DynamoDB does not prevent the use of reserved words as names.
Expression Length − Expression strings have a 4KB limit. Attribute expressions have a 255-byte limit. Substitution variables of an expression have a 2MB limit.
