Amazon DynamoDB Flashcards
DynamoDB
No config, only how many writes / reads your app will perform per sec.
No learing curve but best practices are crucial!.
NoSQL ( high volume, high variety, high velocity)
serverless (zero admin),
cloud(awailable as a service, no installation),
fast (latency mili-micro sec)
flexible (stores unstructured data)
cost efficient (pay for capacity you provision for a table),
scalable (on demand up/down)
fault tolerant ( cross region replication)
secure ( fine grained access controll)
sql vs noSQL
You can scan tablenwitoit using p s but it costs a lot more!
tables
rows items
columns attributes
PK optional? PK = partition (m) + sort (o) keys
Indexes Local Secondary Indexes
Views Global Secondary Indexes
DynamoDB data types
DataType foe each of the index keys.
Key can be only of scalar type ( string ne, number, boolean, binary ne, null)
scalar - exactly one (sting etc., null)
set ne sets or values, no duplicates - scalarS
document ne values, empty map lists, up to 32lvl - complex with nested attrs, e.g. map
Storing: list - json array, map - json document
DynamoDB alows to interact ising JSON, but it doesn’t store as JSON.
DynamoDB consistency model
Region - separate geographic area
(Isolated) locations: availibility zone
Facility ( data center)
3 copies of data within a region
Act as independant failure domains
Near real time replication - only one copy with guarantee ( eventual consistency by default)
Strong Consistency - req explicitly
Eventual Consistency - default for all operations, 50% cheaper
DynamoDB Capacity Units
Tables top lvl FK not advocated ( can be?) mandatory PK use i ln all queries controll performance : throughput apacity RCU and WCU
Capacity Units
1 capacity unit = 1 request / sec ( r or w)
1 RCU = 1 strong, 2 eventually consistent in blocks of 4KB
1 WCU = 1 table write a sec in blocks of 1KB
Burst Capacity
Scalling up - as needed, down - 4 times a day; affects partition behavior, 1 partition supports up to 1000 WCS, 3000 RCU
DynamoDB partitions
a block of memory allocated by dybanoDB
a tale can have multiple partitions, depends on it’s size and provisioned capacity (initial ada automatically added values)
managed internally by dynamoBD
1 partition = 10GB of data, 1000WCUs or 3000RCUs, when exceeded automatically
DynamoDB index
primary (table) and secondary (local, global)
index key (simple = only partition [hash key]) (composite = partition + sort)
When creating a table we decide which type of key a table should have.
Partition (hash) decide the target partition. We shouldn’t query item without using the partition key. (scan should be avoided)
Local Secondary Index
Eventually / strongly consistent
up to 5
must be created while creating table
Global Secondary Index
up to 5, created anytime (stored separately in there own partitions), only eventually, can have duplicate items