DynamoDB Summary

DynamoDB Exam Tips

  • Amazon DynamoDB is a low-latency NoSQL database
  • Consists of Tables, Items, and Attributes
  • Supports both document and key-value data models
  • Supported document formats are JSON, HTML, XML
  • 2 types of Priamry Keys:
    • Partition Key
    • Partition Key + Sort Key (Composite Key)

--

  • 2 Consistency Models
    • Strongly Consistent
      • most up to date data
      • Reflects all writes
    • Eventually Consistent
      • Default
      • Read data from the table may not reflect the status of a recently completed write operation
  • Access is controlled using IAM Policies
    • used IAM service role to allow EC2 to interact with Dynamodb
  • Fine grained access control using IAM condition parameter: dynamodb:LeadingKeys to allow users to access only the items where the partition key value matches their user ID

Indexes Exam Tips

  • Indexes enable fast queries on specific data columns
  • Gives you a different view of your data based on alternative Partition/Sort Keys
  • Differences between local secondary and global secondary index
Local Secondary Global Secondary
Must be created when you create your table can create at any time - at table creation or after
Same Partition key as your table Different Partition Key
Different Sort Key Different Sort Key

Scan vs Query Exam Tips

  • A Query Operation finds items in a table using only the Primary Key Attribute
  • You provide the Primary Key name and a distinct value to search for
  • A Scan operation examines every item in the table
    • By Default, returns all data attributes
    • Use the ProjectionExpression parameter to refine the results
  • Query results are always sorted by the sort key (if there is one)
  • Sorted in ascending order
  • Set ScanIndexForward parameter to false to reverse the order - queries only
  • Query operation is generally more efficient than a SCan
  • Reduce the impact of a query or scan by setting a smaller page size which uses fewer read operations
  • Isolate scan operations to specific tables and segregate them from your mission-critical traffic
  • Try Parallel scans rather than the default sequential scan
  • Avoid using scan operations if you can: design tables in a way that you can use the Query, Get, or BatchGetItem APIs

DynamoDB Provisioned Throughput Exam Tips

  • Provisioned Throughput is measured in Capacity Units
  • 1 x Write Capacity Unit = 1 x 1 KB Write per second
  • 1 x Read Capacity Unit = 1 x 4 KB Strongly Consistent OR 2 x 4 KB Eventually Consistent Reads per Second tghnb Calculate Write capacity requirements (100 x 512 byte items per second):
  • First, calculate how many Capacity Units for each write
    • Size of each item / 1 KB (for write capacity units)
    • 512 bytes / 1 KB = .5
    • Rounded up to the nearest whole number, each write will need 1 Write capacity unit per write operation
  • Multiplied by the number of writes per second = 1 x 100 = 100 write capacity units required

Calculate Read Capacity Requirements (80 x 3 KB items per second)

  • First calculate how many Capacity Units for each read:
    • Size of each item / 4 KB (for read capacity units)
    • 3KB / 4KB = .75
    • Round up to nearest whole number = 1 read capacity unit
  • Multiplied by the number of reads per second = 1 x 80 = 80 read capacity units for strongly consistent
  • Divide by 2 for eventual consistency = 40 read capacity units

DAX Exam Tips

  • Provides in-memory caching for DynamoDB tables
  • Improves response times for Eventually Consistent reads only
  • You point your API calls to the DAX cluster instead of your table
  • If the item you are querying is in the cache, DAX will return it
    • Otherwise, it will perform an eventually consistent GetItem operation to your DynamoDB table
  • Not suitable for write-intensive applications or applications that require Strongly Consistent Reads

Elasticache Exam Tips

  • In-memory cache sits between your application and database
  • 2 different caching strategies
    • Lazy Loading
      • Lazy Loading only caches the data when it is requested
      • Elasticache Node failures not fatal, just lots of cache misses
      • Cache miss penalty: initial request, query database, writing to cache
      • Avoid stale data by implementing a TTL
    • Write Through
      • Writes data into the cache whenever there is a change to the database
      • Data is never stale
      • Write penalty: Each write involves a write to the cache
      • Elasticache node failure means that data is missing until added or updated in the database
      • Wasted resources if most of the data is never used

Optimistic Locking

Optimistic locking is a strategy to ensure that the client-side item that you are updating (or deleting) is the same as the item in DynamoDB. If you use this strategy, then your database writes are protected from being overwritten by the writes of others - and vice-versa. Take note that:

  • DynamoDB global tables use a "last writer wins" reconciliation between concurrent updates. If you use Global Tables, last writer policy wins. So in this case, the locking strategy does not work as expected.
  • DynamoDBMapper transactional operations do not support optimistic locking.

With optimistic locking, each item has an attribute that acts as a version number. If you retrieve an item from a table, the application records the version number of that item. You can update the item, but only if the version number on the server side has not changed. If there is a version mismatch, it means that someone else has modified the item before you did; the update attempt fails, because you have a stale version of the item. If this happens, you simply try again by retrieving the item and then attempting to update. Optimistic locking prevents you from accidentally overwriting changes that were made by others; it also prevents others from accidentally overwriting your changes.

Extras

  • DynamoDB uses conditional writes for consistency
    • DynamoDB allows conditional writes to tables. Conditional writes are only performed if the current attributes of the item meet the specified conditions.
  • DynamoDB uses optimistic concurrency control
  • In DynamoDB, a primary key can either be a single-attribute partition key or a composite partition/sort key.
  • Eventual consistency applies to reads of a DynamoDB table, unless you specify otherwise
  • the LimitExceededException with table state of "creating" occurs when you attempt to create more than one table with a secondary index at the same time.
    • You can only create one secondary index at a time.
    • Create the second table and it's accompanying index after the first table has a status of 'active'
  • A has key and a partition key are the same thing.
  • Range and sort keys are the same.
  • If a given partition is consuming more than its share of throughput, a ProvisionedThroughputExceededException error can occur
  • DynamoDB does not support cross-table joins
    • DynamoDB does not support complex relational queries (e.g. joins) or complex transactions. If your workload requires this functionality, or you are looking for compatibility with an existing relational engine, you may wish to run a relational engine on Amazon RDS or Amazon EC2.
  • A DynamoDB table can contain 5 local secondary indexes and five global secondary indexes
  • A global secondary index is characterized by an index key value that differs from that of the table's primary key
    • a global secondary index contains a selection of attributes from the table, but they are organized by a primary key that is different from that of the table
  • You can give access to specific tables using IAM