- Le plus récent
- Le plus de votes
- La plupart des commentaires
You're right that the minimum cost for writes is 1WCU (1KB), however, if you update an item which is 10KB in size with a couple of additional bytes, you are charged 11WCU. You pay for the entire item to be updated.
In terms of DynamoDB being good a heavy write throughput, the answer is absolutely yes. For costs, you can use provisioned capacity mode, which can scale up and down as your demands change. You can also take 1-3 year reservations, offering 50-70% discount on costs respectively.
With DynamoDB free tier you can also have up to 200M requests per month for free.
Hello Indie,
You're correct that DynamoDB's pricing is based on the number of write capacity units (WCU), and as you've noted, one WCU can handle a write of up to 1KB in size. If your updates are smaller than 1KB, you are still charged for the full WCU, which may seem inefficient for small frequent writes like updating points.
Try the below strategies which I think could help reduce costs or make DynamoDB more suitable for your use case:
1. Use Provisioned Capacity Instead of On-Demand
- On-demand pricing is more expensive per request compared to provisioned capacity, especially when traffic becomes predictable. If you can estimate your write throughput needs, switching to provisioned capacity can significantly reduce costs. You can also enable Auto Scaling to adjust capacity based on demand spikes, reducing the risk of under- or over-provisioning.
2. Batch Writes
- You can reduce the number of write requests by batching updates using the
BatchWriteItem
API. This allows you to group multiple small write requests into a single request, which reduces the overall number of WCUs consumed.
3. Optimize Data Structure
- Evaluate your data structure. If each write involves updating multiple attributes, consider restructuring the data model to minimize unnecessary writes. For example, keep point updates in a denormalized format or store fewer attributes per item.
4. Use DynamoDB Streams for Asynchronous Processing
- Consider decoupling the immediate need for point updates to be reflected in real time. You could implement DynamoDB Streams to process and apply points asynchronously. This would allow you to batch multiple updates into one write operation, reducing the WCU consumption.
5. Use Global Secondary Indexes (GSIs) Wisely
- Avoid overusing GSIs unless necessary, as every write to a table with a GSI will also consume additional WCUs for the GSI's write operations.
6. Leverage Conditional Updates
- If you're updating only when certain conditions are met (e.g., when a user's points change exceeds a certain threshold), you can reduce the number of unnecessary writes by using DynamoDB's
ConditionExpression
.
7. Consider DynamoDB TTL for Archival Data
- If you're maintaining a large volume of historical data, consider setting up Time-to-Live (TTL) on items that can be deleted after a certain period to save space and write capacity for essential data.
8. Explore Alternatives
If cost continues to be a concern, you could explore alternative databases:
- Amazon Aurora (Serverless): It allows you to scale based on demand and provides efficient scaling with SQL capabilities.
- Amazon RDS: If you are fine with using a relational database, RDS offers predictable pricing.
- Redis + DynamoDB (Hybrid): You could cache frequently changing point data in Redis and then periodically sync it to DynamoDB. This reduces the frequency of writes and keeps the costs down.
For large-scale applications, big players usually optimize by using a combination of provisioned capacity, efficient data modeling, batch operations, and caching layers to reduce the frequency and size of writes. Balancing real-time updates with background synchronization is key to managing costs in write-heavy applications like yours.
Please let me know if any of these suggestions work for your application
Contenus pertinents
- demandé il y a 2 ans
- demandé il y a 2 ans
- AWS OFFICIELA mis à jour il y a 10 mois
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an
Many of the things in this answer is incorrect, such as batching items using BatchWriteItems and conditional writes to decrease cost.