DynamoDB: How simple and complex is write operation
Introduced by AWS in 2012 with basic APIs exposed to work, it has been adding amazing features with every release. Check out impressive history of this amazing DB.
DynamoDB is being used for varied number of use cases and it also exposes different APIs to cater to different needs. I am not aware of any other database who has exposed these many APIs to work with itself.
Before going to understand all the APIs, its important to understand few items:
PartiQL
Primarily designed to use for the use of Sql syntax with dynamoDb. While PartiQL provides flexibility to query semi-structures data , it is not always that performant as native dynamoDB operations. It also does not supports certain dynamoDb native such as conditional writes and transactional operations.
Support for transactions
When using the Transact APIs, you will be charged twice the capacity that would be consumed if you performed the operations without a transaction.
Any single failure would cause entire transaction to fail.
Here is one of the best blog to understand transaction: https://www.alexdebrie.com/posts/dynamodb-transactions/
DynamoDB architecture advocates single table design, so be very careful of the use case of transactions if performance and latency is the primary reason to use dynamoDB.
Token Bucket algorithm
If you have followed other blogs in series, you might have come across 2 unique terms in DynamoDB:
RCU(Read capacity unit) : Capacity consumed for read operations per second.
- A strongly consistent read request of an item up to 4 KB requires one read request unit.
- An eventually consistent read request of an item up to 4 KB requires one-half read request unit.
- A transactional read request of an item up to 4 KB requires two read request units.
WCU(Write capacity unit): Capacity consumed for write operations per second.
- One write request unit represents one write for an item up to 1 KB in size
- Transactional write requests require 2 write request units to perform one write for items up to 1 KB.
In case of provisioned cluster RCUs and WCUs needs to be defined. You can understand more about it in other blog of Provisioned vs On-demand.
RCUs and WCUs are not hard limit per second but average over a period of time. For example, AWS will let you use 50 RCUs in one second if you used 0 RCUs in the previous second. The details of how exactly this averaging happens and what its period is isn’t public.
Token bucket algorithm is secret sauce how DynamoDB maintains this count.
In case of write consider a bucket full of WCU tokens available to be used and will get accumulated for a certain period of time. As write operations are performed token is removed based on capacity used for the operation.
As bucket will keep accumulating unused token for certain period of time, token will also start spilling over if unused for longer period of time because bucket capacity is fixed.
In case of provisioned cluster when load increases, bucket size is increased to accomodate adaptive capacity<Link for adaptive capacity>.
Below table summarises the APIs available for write operations with DynamoDB.
Hope this blog helps to decide on correct write API to use for your use case.
We have created a series of dynamoDB blogs and do check them out to understand more concepts on DynamoDB:
data-partitioning-is-the-secret-sauce
provisioned-vs-on-demand-capacity
