Skip to main content

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 application

  • Attribute names have no relationship to attribute values.
  • Store date-like data as integers, for easy comparison.
  • Automatic UUID generation for ids. When the attribute must have an id (this is not applicable to available_groups since it is a simple string value), it should be an uuid4.
  • According to official documentation the latency of a get_item vs a query limit=1 will be equivalent. So it is better to have always both range and sort key for every table and GSI.
  • 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 items

For findings.

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html

  • NoSQL Design
  • Partition Key Design
  • Sort Key Design
  • Secondary Indexes
  • Many-to-Many Relationships
  • Relational Modeling
Last updated on