A Journey to DynamoDB

Transcription

1 A Journey to DynamoDB and maybe away from DynamoDB Adam Dockter VP of Engineering ServiceTarget

2 Who are we? Small Company 4 Developers AWS Infrastructure NO QA!!

3 About our product Self service web application powered by a knowledge base

4 Journey Phase 1 - Create a new application Phase 1 One Developer Get to market fast Plan to evolve the product Plan to grow product and team

5 Journey Phase 1 - Create a new application Phase 1 Define our data model Building a knowledge base application Need document storage Minimal configuration storage No strong relational needs

6 Journey Phase 1 - Create a new application Phase 1 Define our data model NO SQL NoSQL was all the rage Schemaless seemed to support ideas for evolving the product JSON is fast flexible and ubiquitous across languages

7 { { What is No SQL? Attributes Table Items Partition Key Sort Key

8 What is No SQL? Key/Value Storage { CONTENT TABLE { CONTENT TABLE KEY SORT id: `6aZtc79`, type: `article`, title: `Dynamo DB Overview`, body: `Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability`, modfied: ` ` KEY SORT } id: `8xE220rt`, type: `contact`, name: `Adam Dockter`, `adam.dockter@st.com`, phone: ` `, dob: ` `, modfied: ` ` }

9 What is No SQL? SQL Normalized/relational Ad hoc queries Scale vertically Good for OLAP NoSQL Denormalized/hierarchical Instantiated views Scale horizontally Built for OLTP at scale

10 Journey Phase 1 - Create a new application Phase 1 Define our data model NO SQL We did it!

11 Journey Phase 1 - Create a new application Phase 1 Define our data model NO SQL MongoDB

12 Journey Phase 2 - Scale and Grow Phase 2 Dev Ops Challenges

13 Journey Phase 2 - Scale and Grow Phase 2 Dev Ops Challenges Running your own DB Running DynamoDB Replication in primary region Replication to failover region Replication across AWS AZs Security of DB Upgrades and patches of DB Backups of DB Security of host machine Upgrades and patches of host machine Health checks and alarms Enough capacity / Performance Stuff I can t even think of... Replication in primary region Replication to failover region Replication across AWS AZs Security of DB Upgrades and patches of DB Backups of DB Security of host machine Upgrades and patches of host machine Health checks and alarms Enough capacity / Performance Stuff I can t even think of...

14 Journey Phase 2 - Scale and Grow Phase 2 Dev Ops Challenges DynamoDB

15 Dynamo Development Environment Downloadable / Offline Devtools / Discovery / Troubleshooting

16 Dynamo Development Programming API Mapper Document Low Level Available in Java and.net - Super easy but limitations Available in Java,.NET and Javascript Basically working directly against REST API

17 Dynamo Development Application Java API Create a mapper var client = AmazonDynamoDBClientBuilder.standard().build(); var mapper = new DynamoDBMapper(client); Create and item var item = new Catalog( 102, "Book Title" ); mapper.save(item); Get item by id var item = mapper.load(catalog.class, 102); Javascript Migration tool Create a client import {DynamoDB} from 'aws-sdk'; let client = new DynamoDB.DocumentClient(config); Query item let params: DynamoDB.DocumentClient.QueryInput = { TableName: 'catalog', KeyConditionExpression: 'id = :id', ExpressionAttributeValues: { ':id': itemid } }; let queryresult = await client.document.query(params).promise();

18 Journey Phase 3 - Expand features Phase 3 Dynamo Challenges

19 Journey Phase 3 - Expand features Phase 3 Dynamo Challenges Capacity / Cost Backups Replication to failover Indexing data Query capabilities

20 Dynamo Challenges Capacity and Cost When we started Tables are provisioned with and billed by read and write capacity units RCU - 4Kb / sec WCU - 1Kb / sec Forecasting is incredibly hard when your customer data, volumes, growth, etc are not exact or known When limits are hit your app is down - get ready for 5xx responses Auto scale with lambda and CLI calls What s new since then DynamoDB team introduces auto-scaling It s not great, especially for spikes DynamoDB team introduces cache accelerators (DAX) Solve issue with burst reads on a table Can only cache data in the storage schema We don t use this we use our own caching strategy with Elasticache which allows us to cache higher level processed data schemas Single digit response times are counter intuitive

21 Dynamo Challenges Backups When we started Dynamo backups were not available and they were a nightmare Solution 1 Lambda function that ran nightly to read dynamo data and write to S3 Solution 2 Lambda function that ran nightly Scale up RCU, Read data, Retry with exponential back off when capacity limit hit, Write to S3, Scale down RCU What s new since then DynamoDB team introduced built in backups Instant API Restore deleted tables Infinite backups Don t pay for it Simple solution now is a lambda function that uses backup API <2 hours for new backup solution vs. 4-6 person days Point in time backups provided by Dynamo Solution 3 Step functions, lambda functions and retries.oh my!

22 Dynamo Challenges Replication to Failover When we started Incredibly difficult for us to move data our primary region to our failover region Admittedly we may be somewhat at fault here How we replicated Describe all tables and recreate Read data from primary and copy to failover Constantly battling RCU/WCU limits Constantly battling Lambda timeouts Similar solution to backups Step functions, lambda functions and retries.oh my! What s new since then Data streams Data streams and continuous data replication with write triggers Was likely there when we started we just didn t consider it Seemed expensive, but probably cheaper than entire data replication nightly. 3TB month data transfer cost and growing DynamoDB team introduced built in global tables Replicate tables across regions and keep data in sync for you Simple solution now will be global table + lambda function for backups

23 Journey Phase 3 - Expand features Phase 2 Dynamo Challenges now Uptake Capabilities complete complete no need consider consider Autoscaling Built in backups Dynamo Accelerator DAX Data streams Global Tables

24 Journey Phase 3 - Expand features Phase 2 Dynamo Challenges Uptake Capabilities Better Patterns next Capacity / Cost Backups Replication to failover Indexing data Query capabilities

25 Misconceptions Flexibility is commonly touted as the reason to use NoSQL databases. Reality is NoSQL schema is tightly coupled to application specific access patterns which is an inherently inflexible design choice as it restricts what can be done in the future without restructuring the data. RDBMS leverages normalized schema coupled with an ad hoc query engine to provide arguably more flexibility and less developer overhead in design and build phases of a project.... Rick Houlihan

26 What is No SQL? SQL Normalized/relational Ad hoc queries Scale vertically Good for OLAP NoSQL Denormalized/hierarchical Instantiated views Scale horizontally Built for OLTP at scale

27 Dynamo Challenges Indexing Querying is limited Only by partition key Data is sorted by a single sort key Scanning is expensive Scanning selected all data then filters Secondary Indexes Local Secondary Index Same partition key, different sort key. Limit of 5 Has to be created when the table is created Global Secondary Index Different partition key and sort key Limit of 5 Can be created at any time Pay for RCU/WCU on these indexes

28 Dynamo Challenges Querying capabilities Paging - limited support Paging is done through a LastEvaluatedKey Limited to a single sort key Jump to page X not possible Go back to page Y not easy Aggregations - no support Joins - no support Transactions - limited support An operation on a table are atomic Operations across tables are not

29 Pattern Improvements Building blocks Dynamodb Streams Change log of data All write operation show up on a stream Can be hooked up to lambda Lambda Stored procedure engine Complete isolated process space Cannot crush performance of db Patterns ** Storage is cheap, computation is more expensive Generated Attributes Concatenate two or more attributes together Better use of index as instiated views Generate attributes for scenarios Filtered data sets Transactions Versioning pattern Metadata records Conditional Updates - optimistic locking Adjacency list and materialized graphs!

30 Stay or go? Continue to learn better practices Leverage more integrated capabilities of AWS Keep uptaking new enhancements as they come out Microservices - each service can decide

31 Questions?

32 References Rick Houlihan: Pattern Presentation