DynamoDB

• https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/

• No need to provision DB, only create RCU and WCU

• Partition key: Unique identifier, A simple primary key,

• Composite primary key = Partition key and sort key

• Recommendations for partition keys

• Use high-cardinality attributes. These are attributes that have distinct values for each item,

  • e-mailid, employee_no, customerid, sessionid, orderid, and so on.

• Use composite attributes. Try to combine more than one attribute to form a unique key, if that meets your access pattern

• Can save session state of the users (but it has higher latency then Elasticache)

• Session state with low latency then go for Elasticache and not DynamoDB

• RCU WCU – how to calculate ?

• Read Capacity Unit – RCU

  • 4KB item , 1RCU can perform 1 strongly consistent read/sec

  • 4KB item, 1RCU can perform 2 eventually consistent read/sec

  • Transactional reads: 4KB item , 2RCU can perform 1 read/sec

  • Ex: 4KB item and 10RCU , can perform 10*1=10 strong consistent and 10*2=20 eventual consistent reads and 5 Transactional reads

• Write Capacity Unit – WCU

  • 1KB item , 1WCU can perform 1 standard consistent write/sec

  • Transactional write: 1KB item , 2WCU can perform 1 write/sec

  • Ex: 1KB item and 10WCU , Can perform 10 standard consistent writes/sec

• DynamoDB Streams:

  • To keep records of changes to items in a DynamoDB table

  • All data in DynamoDB Streams is subject to a 24 hour lifetime, any data beyond 24hrs gets deleted from streams

  • decrease the interval of running your lambda function to 24 hours, in case if some data is missing on your consumer (S3)

  • DynamoDB Streams can also be used as trigger which can automatically trigger notification to lambda to send mails, notifications when data change occurs in table (no need of CloudWatch integration)

  • StreamViewType are:

    • KEYS_ONLY - Only the key attributes of the modified item are written to the stream.

    • NEW_IMAGE - The entire item, as it appears after it was modified, is written to the stream.

    • OLD_IMAGE - The entire item, as it appeared before it was modified, is written to the stream.

    • NEW_AND_OLD_IMAGES - Both the new and the old item images of the item are written to the stream.

• Scan and Query

  • Scan queries entire table, use query instead of scans

  • For Better performance of (or reduce impact on) provisioned throughput, or reduce impact on

    • Use query

    • Reduce page size

    • Isolate scan operations

  • Faster scan results, but will place more burden on the table’s provisioned throughput ( to reduce the burden apply rate limiting)

    • parallel Scan (better used in below scenarios)

      • The table size is 20 GB or larger

      • The table's provisioned read throughput is not being fully used.

      • Sequential Scan operations are too slow.

  • Sparse index : Queries over a small subsection of a table

• DynamoDB Batch Operation

  • Helpful when there are too many transaction (read/write) happening on your DynamoDB causing network overhead or application performance degradation

  • Use BatchGetItem and BatchWriteItem operations to reduce number of network trips

  • Batch Operations API GET, PUT, and DELETE operations

• DynamoDB transactional read

  • atomicity, consistency, isolation, and durability (ACID) in DynamoDB,

  • Maintain data correctness in your applications easily

  • require coordinated inserts, deletes, or updates to multiple items

• Projection expression : returns attributes ( Ref. table headers)

• Filter expressions : return items (actual values ) for your query

  • Attributes

• Cache-Control: max-age=0

  • Invalidate cache and pull the data from DynamoDB directly

• Time To Live (TTL)

  • Enable TTL to automatically clear session data or stale data in DynamoDB

  • To clear Ex: session data, event logs, usage patterns, userlogins

• Global secondary index

  • Perform fast queries on specific columns in a table

  • An index with a partition key and a sort key that can be different from those on the base table

  • Supports ONLY eventual consistency

  • To query over the entire table, across all partitions.

  • You can add a GSI to an already existing table

  • Has its own RCU and WCU

  • Speed up queries on non-key attributes use a GSI

  • Improve query performance and reduce costs

  • WCU of GSI => WCU of base table

• Local secondary index

  • Perform fast queries on specific columns in a table

  • An index that has the same partition key as the base table, but a different sort key

  • Support both eventually consistent and strongly consistent reads

  • To query over a single partition of the table

  • LSI are created at the same time you create a table. You cannot add/delete a LSI to an existing table

  • Uses parent RCU and WCU