DynamoDb with AWS SDK Go v2 — Part 1
Recently, I wrote some Go projects and performed many Dynamodb operations on these projects. In many of these operations, I learned new things and had difficulties in some parts. Since I found the AWS SDK document about Go version 2 missing, I wanted to write something about this subject. For this reason, in this article, I wanted to share the experiences I had in the operations in Dynamodb, the points I had difficulty with, and the practical solutions I found myself with AWS SDK Go v2.
What is DynamoDb?
DynamoDb is a NoSQL database service with its scalable speed and performance. With DynamoDb, it provides the necessary capacity management with auto-scale without having to think about hardware, installation, configuration, etc.
For the continuation, you can review AWS’ document at this link.
DynamoDb Keys and Indexes
Partition Key(PK) is used as the primary key in DynamoDb. It works in the same logic as the primary key, familiar from relational databases. Besides, there is another use as a key in DynamoDb, which is Sort Key(SK) and it determines how the data will be sorted.
Using GSI(Global Secondary Index) like another partition key creates an exact copy of our main table and AWS keeps these two tables in sync. The important thing about this is that when writing to the main table, this data is written to the GSI table as well and it doubled the cost. But this has a limit and a maximum of 20 GSI’s is allowed. Also, the tables are eventually consistent, so there is a possibility that the data we will get from the GSI table is old data.
LSI (Local Secondary Index) is used when the same partition key is used but narrows the query result over different fields. The main difference between GSI and LSI is whether want to combine our query with a partition key or not? LSI can only create when first creating a table, and can define up to 5 LSIs. One of the biggest features that distinguish LSI from GSI is that AWS does not charge an additional fee for LSI.
DynamoDB Schema Design
Before using DynamoDB, it is recommended that we determine which data and how we will access it and then design the schema. First, we look at what type of queries we can make with these indexes.
- Just using Partition Key,
- Partition Key+ Sort Key together,
- Partition Key+ LSI together,
- Only with GSI,
- The query can be made by using it together with GSI+ Sory Key
Choosing a bad partition key means uneven CPU usage, as it will cause the data to be unevenly distributed. However, the reason why NoSQL solutions are used is to avoid excessive CPU consumption. In other words, if the NoSQL solution is used and your design is not good, there will be an unbalanced CPU usage.
What’s Change With Go-SDK-v2
Two big changes are enough to save a life. These are the attributevalue and expression packages, also performance improvements are made.
- AttributeValue
By using the AttributeValue package, it enables the application to be used in DynamoDb queries very easily by converting Go types to Amazon DynamoDB AttributeValue types.
- Expression
Expression package, which is my favorite, allows adding attribute updates and conditions very easily. I believe that this package, which is my favorite, increases the readability of the code as well as eliminates the hassle of writing queries as in v1.
- Performance
AWS SDK for Go v2 produces type-specific serializers and deserializers, dispensing with the requirement for runtime-based reflection. Disposing of reflection comes about in a checked change in CPU and memory utilization when utilizing the API clients.
According to AWS benchmark program using AWS DynamoDb client, 50% reduction in CPU time, 32% reduction in the number of bytes allocation, and 58% reduction in total allocation.
Thank you for reading. The examples will be in the next part. I hope you enjoyed while reading.
