Jon Holman

Solutions Architect, Serverless Enthusiast, Data Architect, DevOps Engineer, FinOps Architect/Engineer, AWS Community Builder

ComputelessBlog > Part 2: Planning the Data Model

Preparing to create our Computeless Blog by preparing our data model
2020-12-13

As the first step to creating our blog, we need to create our DynamoDB table that will store all of our content. To prepare to create our DynamoDB table, we will list out all of our data access patterns, so we can select our partition key(s) and sort key(s), and determine if we need to create any additional indexes.

This is Part 2 of our series on creating a Computeless Blog.  If you did not read the introduction, it can be found here.

To do this, I brainstormed the access patterns I anticipate and came up with this list:

  1. Get all articles sorted by date
  2. Get all articles for a category sorted by date
  3. Get one specific article
  4. Get all comments for an article
  5. Get the number of comments for each article

We will then put these in a table with pk (partition key) and sk (sort key) to identify what keys we will need to query that data.

Access PatternPKSK
Get all articles sorted by datearticledate
Get all articles for a category sorted by datearticlearticle path begins with category name
Get one specific articlearticlearticle path
Get all comments for an articlecommentbegins with article path
Get the number of comments for each articlecomment 

To satisfy these access patterns, we will create a single DynamoDB table with a partition key and sort key.  To avoid locking our partition key and sort key into a specific use case, we will name them generically as pk and sk.  That still leaves us without a way to solve the first access pattern 'Get all articles sorted by date' as the articles will have its PK as article and its SK as the article path.  We will then add a Local Secondary Index (LSI) to satisfy that access pattern.

To learn more about data modeling for DynamoDB I recommend:

  1. Watching Alex DeBrie's talk from AWS re:Invent 2019: Data modeling with Amazon DynamoDB (CMY304)
  2. Reading Alex DeBrie's post The What, Why, and When of Single-Table Design with DynamoDB

Now let's discuss ReadCapacityUnits (RCU) and WriteCapacityUnits (WCU) on the DynamoDB table.  We could set the BillingMode: PAY_PER_REQUEST on our DynamoDB table, to have it scale based on demand, but I do not like not being able to set an upper limit of how high it may go.  Like I said in the introduction, I am a very cost conscious person, so I like to have control of these settings.  I also really like how DynamoDB's burst capacity works, it's like rollover minutes on a cell phone plan, but instead of last month we're looking at the last 5 minutes.  Accumulating the last 5 minutes of unused RCU and WCU we can get some great burst capacity, with a very small RCU and WCU set on the table.  With that said, I am going to set each of these to 1 to start and then I'll keep an eye on it.

Now that we have ironed out the configuration for our DynamoDB table we can move on to defining our DynamoDB table in CloudFormation.  Since this will be the first resource we are defining, we will start by creating a folder for our project with a new file named template.yaml.  This will be the main file in our AWS SAM project, which will be read first every time we run sam deploy. When reviewing this CloudFormation definition of the DynamoDB table, note that partition key is also known as hash key and sort key is also known as range key.

Now that the template.yaml file is created, open a terminal and browse to the folder you created for this project.  Then run sam deploy --guided and the guided deploy wizard will walk you through all of the settings needed for your deployment.  I recommend to answer yes to the prompt 'Save arguments to configuration file', when that configuration file is saved future stack updates can be done by just running sam deploy, the guided wizard will only need to be run again if we add a new parameter or need to change a setting in the saved configuration.

Now let the SAM deployment run and when it's complete, it will return a message like 'Successfully created/updated stack - [Stack Name] in [AWS Region]'.  Our table is now created, to prepare for the next part of this series where we will create an API Gateway endpoint to display a blog post, lets create a sample blog post directly in the DynamoDB table we just created.  Open your web browser and log into the AWS console, then browse to DynamoDB (ensure you have the region selected that you specified in sam deploy), select tables on the left sidebar, and then select your new table that will be named the same as the stack name you provided to sam deploy. Now that the new table is selected, on the right side (main content) area select the items tab, and then click the button to Create Item.  In the modal window that opens up, in the upper left select the drop down that currently has Tree selected and change the selection to Text, then copy and paste in the sample below and click Save.

We now have an AWS SAM project that defines a DynamoDB table, we have deployed one stack of this template and created a sample blog post in that table.  That's all for this post, thank you for taking the time to read it.  Next we will create the article page that will display the sample blog post in to a web browser.  If you have any questions or have any suggestions to make this better please leave a comment or reach out via Twitter or LinkedIn and let me know.

Our project directory at the end of this post is available here.

Continue with the next article in this series.

Comments

You must be signed in to post a comment.