-
Notifications
You must be signed in to change notification settings - Fork 114
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
LSQL: relational migration merge - guide (#121)
* relational migration instructions initial * LMIG -> LDMS, + LSQL naming * LSQL content additions * Changes for LSQL to add MySQL EC2 instance * pulling in Rob's changes to template * Fixed syntax error in UserData * Changes alongside my review * Rob's changes * instruction updates for clarity * image and instruction improvements * updated images * Final revision before merge --------- Co-authored-by: Sean Shriver <[email protected]>
- Loading branch information
Showing
71 changed files
with
1,005 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4 changes: 2 additions & 2 deletions
4
...hands-on-labs/rdbms-migration/index.en.md → content/rdbms-migration/index.en.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
30 changes: 30 additions & 0 deletions
30
content/relational-migration/application refactoring/index.en.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,30 @@ | ||
--- | ||
title : "Application Refactoring" | ||
weight : 40 | ||
--- | ||
|
||
## Updating the Client Application for DynamoDB | ||
After you have chosen your DynamoDB table schema, and migrated any historical data over, | ||
you can consider what code changes are required so a new version of your app can call the DynamoDB | ||
read and write APIs. | ||
|
||
The web app we have been using includes forms and buttons to perform standard CRUD (Create, Read, Update, Delete) operations. | ||
|
||
The web app makes HTTP calls to the published API using standard GET and POST methods against certain API paths. | ||
|
||
1. In Cloud9, open the left nav and locate the file **app.py** | ||
2. Double click to open and review this file | ||
|
||
In the bottom half of the file you will see several small handler functions that | ||
pass core read and write requests on to the **db** object's functions. | ||
|
||
|
||
Notice the file contains a conditional import for the **db** object. | ||
|
||
```python | ||
if migration_stage == 'relational': | ||
from chalicelib import mysql_calls as db | ||
else: | ||
from chalicelib import dynamodb_calls as db | ||
``` | ||
|
32 changes: 32 additions & 0 deletions
32
content/relational-migration/application refactoring/index2.en.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
--- | ||
title : "DynamoDB-ready middle tier" | ||
weight : 41 | ||
--- | ||
|
||
## Deploy a new DynamoDB-ready API | ||
|
||
If you recall, we had run the command ```chalice deploy --stage relational``` previously | ||
to create the MySQL-ready middle tier. | ||
|
||
We can repeat this to create a new API Gateway and Lambda stack, this time using the DynamoDB stage. | ||
|
||
1. Within the Cloud9 terminal window, run: | ||
```bash | ||
chalice deploy --stage dynamodb | ||
``` | ||
2. When this completes, find the new Rest API URL and copy it. | ||
3. You can paste this into a new browser tab to test it. You should see a status message indicating | ||
the DynamoDB version of the API is working. | ||
|
||
We now need a separate browser to test out the full web app experience, since | ||
the original browser has a cookie set to the relational Rest API. | ||
|
||
4. If you have multiple browsers on your laptop, such as Edge, Firefox, or Safari, | ||
open a different browser and navigate to the web app: | ||
|
||
[https://amazon-dynamodb-labs.com/static/relational-migration/web/index.html](https://amazon-dynamodb-labs.com/static/relational-migration/web/index.html). | ||
|
||
(You can also open the same browser in Incognito Mode for this step.) | ||
|
||
5. Click the Target API button and paste in the new Rest API URL. | ||
6. Notice the title of the page has updated to **DynamoDB App** in a blue color. If it isn't blue, you can refresh the page and see the color change. |
36 changes: 36 additions & 0 deletions
36
content/relational-migration/application refactoring/index3.en.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
--- | ||
title : "Testing and reviewing DynamoDB code" | ||
weight : 42 | ||
--- | ||
|
||
## Test drive your DynamoDB application | ||
|
||
1. Click Tables to see a list of available tables in the account. You should see the | ||
Customers table, vCustOrders table, and a few other tables used by separate workshops. | ||
|
||
3. Click on the Customers table, click the SCAN button to see the table's data. | ||
4. Test the CRUD operations such as get-item, and the update and delete buttons in the data grid, | ||
to make sure they work against the DynamoDB table. | ||
4. Click on the Querying tab to display the form with GSI indexes listed. | ||
5. On the idx_region GSI, enter 'North' and press GO. | ||
|
||
![DynamoDB GSI Form](/static/images/relational-migration/ddb_gsi.png) | ||
|
||
## Updating DynamoDB functions | ||
|
||
Let's make a small code change to demonstrate the process to customize the DynamoDB functions. | ||
|
||
6. In Cloud9, left nav, locate the chalicelib folder and open it. | ||
7. Locate and open the file dynamodb_calls.py | ||
8. Search for the text ```get_request['ConsistentRead'] = False``` | ||
9. Update this from False to True and click File/Save to save your work. | ||
10. In the terminal prompt, redeploy: | ||
|
||
```bash | ||
chalice deploy --stage dynamodb | ||
``` | ||
|
||
11. Return to the web app, click on the Customers table, and enter cust_id value "0001" and click the GET ITEM button. | ||
12. Verify a record was retrieved for you. This record was found using a strongly consistent read. | ||
13. Feel free to extend the DynamoDB code to add new functions or modify existing ones. | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
--- | ||
title : "Data Migration" | ||
weight : 30 | ||
--- | ||
|
||
## Transform, Extract, Convert, Stage Import | ||
|
||
Recall our strategy for migrating table data into DynamoDB via S3 was | ||
summarized in the :link[Workshop Introduction]{href="../introduction/index5" target=_blank}. | ||
|
||
For each table or view that we want to migrate, we need a routine that will ```SELECT *``` from it, | ||
and convert the result dataset into DynamoDB JSON before writing it to an S3 bucket. | ||
|
||
![Migration Flow](/static/images/relational-migration/migrate_flow.png) | ||
|
||
For migrations of very large tables we may choose to use purpose-built data tools like | ||
AWS Glue, Amazon EMR, or Amazon DMS. These tools can help you define and coordinate multiple | ||
parallel jobs that perform the work to extract, transform, and stage data into S3. | ||
|
||
In this workshop we can use a Python script to demonstrate this ETL process. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
--- | ||
title : "ETL Scripts" | ||
weight : 31 | ||
--- | ||
|
||
|
||
## mysql_s3.py | ||
|
||
A script called mysql_s3.py is provided that performs all the work to convert and load a query result | ||
set into S3. We can run this script in preview mode by using the "stdout" parameter. | ||
|
||
1. Run: | ||
```bash | ||
python3 mysql_s3.py Customers stdout | ||
``` | ||
You should see results in DynamoDB JSON format: | ||
|
||
![mysql_s3.py output](/static/images/relational-migration/mysql_s3_output.png) | ||
|
||
2. Next, run it for our view: | ||
```bash | ||
python3 mysql_s3.py vCustOrders stdout | ||
``` | ||
You should see similar output from the view results. | ||
|
||
The script can write these to S3 for us. We just need to omit the "stdout" command line parameter. | ||
|
||
3. Now, run the script without preview mode: | ||
```bash | ||
python3 mysql_s3.py Customers | ||
``` | ||
You should see confirmation that objects have been written to S3: | ||
|
||
![mysql_s3.py output](/static/images/relational-migration/mysql_s3_write_output.png) | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,54 @@ | ||
--- | ||
title : "Full Migration" | ||
weight : 32 | ||
--- | ||
|
||
## DynamoDB Import from S3 | ||
|
||
The Import from S3 feature is a convenient way to have data loaded into a new DynamoDB table. | ||
Learn more about this feature [here](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/S3DataImport.HowItWorks.html). | ||
|
||
Import creates a brand new table, and is not able to load data into an existing table. | ||
Therefore, it is most useful during the one-time initial load of data during a migration. | ||
|
||
## migrate.sh | ||
|
||
A script is provided that performs multiple steps to coordinate a migration: | ||
* Runs **mysql_desc_ddb.py** and stores the result in a table definition JSON file | ||
* Runs **mysql_s3.py** to extract, transform, and load data into an S3 bucket | ||
* Uses the **aws dynamodb import-table** CLI command to request a new table, by providing the bucket name and table definition JSON file | ||
|
||
1. Run: | ||
```bash | ||
./migrate.sh Customers | ||
``` | ||
The script should produce output as shown here: | ||
|
||
![Migrate Output](/static/images/relational-migration/migrate_output.png) | ||
|
||
Notice the ARN returned. This is the ARN of the Import job, not the new DynamoDB table. | ||
|
||
The import will take a few minutes to complete. | ||
|
||
2. Optional: You can check the status of an import job using this command, by setting the Import ARN on line two. | ||
|
||
```bash | ||
aws dynamodb describe-import \ | ||
--import-arn '<paste ARN here>' \ | ||
--output json --query '{"Status ":ImportTableDescription.ImportStatus, "FailureCode ":ImportTableDescription.FailureCode, "FailureMessage ":ImportTableDescription.FailureMessage }' | ||
``` | ||
|
||
We can also check the import status within the AWS Console. | ||
|
||
3. Click into the separate browser tab titled "AWS Cloud9" to open the AWS Console. | ||
4. In the search box, type DynamoDB to visit the DyanmoDB console. | ||
5. From the left nav, click Imports from S3. | ||
6. Notice your import is listed along with the current status. | ||
![Import from S3](/static/images/relational-migration/import-from-s3.png) | ||
7. Once the import has completed, you can click it to see a summary including item count and the size of the import. | ||
8. On the left nav, click to Tables. | ||
9. In the list of tables, click on the Customers table. | ||
10. On the top right, click on Explore Table Items. | ||
11. Scroll down until you see a grid with your imported data. | ||
|
||
Congratulations! You have completed a relational-to-DynamoDB migration. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
--- | ||
title : "VIEW migration" | ||
weight : 33 | ||
--- | ||
|
||
## Migrating from a VIEW | ||
|
||
In the previous step, you simply ran ```./migrate.sh Customers``` to perform a migration of this table | ||
and data to DynamoDB. | ||
|
||
You can repeat this process to migrate the custom view vCustOrders. | ||
|
||
1. Run: | ||
```bash | ||
./migrate.sh vCustOrders | ||
``` | ||
|
||
The script assumes you want a two-part primary key of Partition Key and Sort Key, found in the two leading columns. | ||
|
||
In case you want a Partition Key only table, you could specify this like so. | ||
|
||
```bash | ||
./migrate.sh vCustOrders 1 | ||
``` | ||
|
||
But don't run this command, because if you do, the S3 Import will fail as you already have a table called vCustOrders. | ||
You could create another view with a different name and import that, or just delete the DynamoDB table | ||
from the DynamoDB console before attempting another migration of vCustOrders. | ||
|
||
However, this is not advisable since this particular dataset is not unique by just the first column. | ||
|
||
![View output](/static/images/relational-migration/view_result.png) | ||
|
||
::alert[Import will write all the records it finds in the bucket to the table. If a duplicate record is encountered, it will simply overwrite it. Please be sure that your S3 data does not contain any duplicates based on the Key(s) of the new table you define.]{header="Note:"} | ||
|
||
The second import is also not advisable since if you created a new vCustOrders table in step 1, the second Import attempt would not be able to replace the existing table, and would fail. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,30 @@ | ||
--- | ||
title : "SQL Transformation Patterns for DynamoDB" | ||
weight : 34 | ||
--- | ||
|
||
## Shaping Data with SQL | ||
|
||
Let's return to the web app and explore some techniques you can use to shape and enrich your relational | ||
data before importing it to DynamoDB. | ||
|
||
1. Within the web app, refresh the browser page. | ||
2. Click on the Querying tab. | ||
3. Notice the set of SQL Sample buttons below the SQL editor. | ||
4. Click button one. | ||
The OrderLines table has a two-part primary key, as is common with DynamoDB. We can think of the returned dataset as an Item Collection. | ||
5. Repeat by clicking each other sample buttons. Check the comment at the top of each query, which summarizes the technique being shown. | ||
|
||
![SQL Samples](/static/images/relational-migration/sparse.png) | ||
|
||
Notice the final two sample buttons. These demonstrate alternate ways to combine data from multiple tables. | ||
We already saw how to combine tables with a JOIN operator, resulting in a denormalized data set. | ||
|
||
The final button shows a different approach to combining tables, without using JOIN. | ||
You can use a UNION ALL between multiple SQL queries to stack datasets together as one. | ||
When we arrange table data like this, we describe each source table as an entity and so the single DynamoDB | ||
table will be overloaded with multiple entities. Because of this, we can set the partition key and sort key | ||
names to generic values of PK and SK, and add some decoration to the key values so that it's clear what type | ||
of entity a given record represents. | ||
|
||
![Stacked entities](/static/images/relational-migration/stacked.png) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
--- | ||
title : "Custom VIEWs" | ||
weight : 35 | ||
--- | ||
|
||
## Challenge: Create New Views | ||
|
||
The SQL editor window is provided so that you have an easy way to run queries and | ||
experiment with data transformation techniques. | ||
|
||
Using the sample queries as a guide, see how many techniques you can combine in a single query. | ||
Look for opportunities to align attributes across the table so that they can be queried by a GSI. | ||
Consider using date fields in column two, so that they become Sort Key values, and be queryable with | ||
DynamoDB range queries. | ||
|
||
1. When you have a SQL statement you like, click the CREATE VIEW button. | ||
2. In the prompt, enter a name for your new view. This will add a CREATE VIEW statement to the top of you query. | ||
3. Click RUN SQL to create the new view. | ||
4. Refresh the page, and your view should appear as a button next to the vCustOrders button. | ||
|
Oops, something went wrong.