Database Patterns | DynamoDB Best Practices | Fluid Attacks Help

Patterns

The following patterns were chosen following the best DynamoDB practices and with the business needs in mind. Some are for standardization among all the applications:
  1. Attribute names have no relationship to attribute values.
  2. Store date-like data as integers, for easy comparison.
  3. Automatic UUID generation for IDs. When the attribute must have an ID (this does not apply to available_groups since it is a simple string value), it should be a UUID4.
  4. According to official documentation, the latency of a get_item vs a query limit=1 will be equivalent. So it is better to always have both range and sort key for every table and GSI.
  5. Use hierarchical relationships: group attributes will have an attribute, which is a sort key, with the following structure: ORG_ID#TYPE#STATUS. With this, it is easy to search for groups within a company, with a certain type in a given status, and everything in between, since a sort key can be searched partially.
Calculations for write sharding:

ItemsPerRCU = 4KB / AvgItemSize

PartitionMaxReadRate = 3K * ItemsPerRCU

N = MaxRequiredIO / PartitionMaxReadRate

For groups. Get active and suspended groups. This query is important for Forces executions:

10000 projected groups
(more than fi\_projects + fi\_project\_names)
in the following 5 years
Currently, there are 594 projects,
with a total size of 1.55MB (1'550.000 bytes)
At least 30% will be active-suspended, so:
MaxRequiredIO = 0.3 \* 10000 = 3000
2609 bytes per item
ItemsPerRCU = 4KB / 2.6KB = 1,54
PartitionMaxReadRate = 3000 \* 1,54 = 4.6K
N = 3000 / 4.6K = 0,65

Given the latter, there is no need to write sharding in groups for findings.
  1. NoSQL Design
  2. Partition Key Design
  3. Sort Key Design
  4. Secondary Indexes
  5. Many-to-Many Relationships
  6. Relational Modeling
Idea
Tip
Have an idea to simplify our architecture or noticed docs that could use some love? Don't hesitate to open an issue or submit improvements.