DynamoDB Cost Optimization Masterclass: ScyllaDB as a DynamoDB Alternative
0 likes33 views
The document discusses ScyllaDB as an alternative to DynamoDB, highlighting its advantages such as faster storage and better workload management. It outlines scenarios when moving from DynamoDB may be beneficial, including cost concerns and performance throttling. Additionally, it addresses considerations for migrating and managing data between the two systems.
DynamoDB Cost Optimization Masterclass: ScyllaDB as a DynamoDB Alternative
- 1. ScyllaDB as a DynamoDB Alternative Felipe Cardeneti Mendes
- 2. Felipe Cardeneti Mendes ● Technical Director at ScyllaDB ● Linux and Open Source enthusiast ● ScyllaDB Passionate
- 4. When is ScyllaDB an overkill? ■ ScyllaDB is a distributed leaderless database ○ 3 nodes at least ○ NVMe flash storage: ■ Faster ■ Less Expensive than EBS ■ Primary dimensions to watch out: ○ Low Throughput – Infrastructure underutilization; ○ Storage Growth – High density tables → Infrastructure overhead ■ Did you know DynamoDB charges you for RAW uncompressed data? :-) ■ Secondary dimensions: ○ Dependency on AWS ecosystem – Requires considerable refactoring effort ○ Feature set – Expiration Events, Accounting/Capping, Multi-item transactions
- 6. ScyllaDB Specific Considerations (and Features) ■ Workload Prioritization ○ Helps with workload consolidation ○ Adaptability to Changing Conditions ○ Addresses the "too many tables" problem ■ Excess capacity is shared ■ Enhanced infrastructure utilization
- 7. ScyllaDB Specific Considerations (and Features) ■ Specialized Cache ○ Read-through – No consistency concerns ○ Built-in ○ Simplified operations
- 8. ScyllaDB Specific Considerations (and Features) ■ Elasticity ○ Tablets are here! :-) ○ Still no "autoscaling" – but easily achievable ○ Instant request serving
- 9. DynamoDB: When to Move Out?
- 10. Reason 1: You Keep Throwing Money at it You know how much you pay, very little about why? ■ Writes are considerably more expensive than Reads ■ Single table design → More indexes → Higher price/ops ■ Global Tables, Dynamo Streams, S3, DAX, Streams… Woot!
- 11. Reason 2: Throttling Also known as ProvisionedThroughputExceededException: ■ Force you to back-off, introducing a latency penalty ■ Far easy to hit ■ Non-tunable load shedding mechanics
- 12. Reason 3: You know what DAX stands for … and now you have two different animals to manage! :-) ■ Doesn't sustain single-digit millisecond latencies at scale ■ Cache helps, but comes with its own nuances: ○ Write to DDB → Read from cache → Stale read! ○ Writes are still synchronous ○ No tightly coupling: Strongly consistent reads still require Dynamo ■ Adds latency!
- 13. Reason 4: Limits, Troubleshooting & Observability Common blockers: ■ 400KB Item size limit ■ Local Secondary Indexes require… Re-creating the table? ■ Developer Flexibility: DynamoDB Local? ■ Little integration off AWS ecosystem ■ Single-table organization & Querying inflexibility
- 14. Reason 5: Auto-scaling No silver bullet, and still requires thorough planning: ■ Avoids provisioning for peak capacity, BUT; ■ Works best for gradual increases or decreases in traffic ■ Burst capacity handles occasional spikes AWS DynamoDB Auto Scaling is not a magic bullet
- 15. DynamoDB: How to Move Out?
- 16. Query Language Supported protocols: ■ CQL – Binary protocol ○ Native load balancing ○ Parallel Request Multiplexing ○ Prepared statements, token/shard awareness… ■ DynamoDB API – JSON over HTTP(S) ○ Requires a load balancer ○ Drivers tend to need to open more connections ○ No notion of prepared statements nor consistent hashing
- 17. Migration Nutshell Client Writes / Reads Enable DynamoDB Streams Reads Writes Consume Changes Sync Changes Writes / Reads ScyllaDB Migrator
- 18. What Else?
- 19. Keep in touch! Felipe Mendes Technical Director ScyllaDB [email protected] LinkedIn