1개 답변
- 최신
- 최다 투표
- 가장 많은 댓글
1
The missing part of the question is: What do you want to do with the data once it it stored? How are you going to query it? And how often?
If you need to query the data regularly and with low latency, DynamoDB could be a good option. That said, a relational database or a time series database might be more suitable depending on the query patterns.
However, if you are storing the data for archival purposes and you don't need millisecond responses to queries then I would send it to Kinesis Firehose; store the data in a "queryable" format in S3 and then query it using Athena. This is likely to be more cost effective.
관련 콘텐츠
AWS 공식업데이트됨 일 년 전
We will need to query the data once in a while, and we don't need milliseconds response times, as queries will be performed by our internal teammates just to know what a user did (whenever there's an issue). For example, a basic scenario would be 100 users using our control panel everyday where we log all their actions. Maybe, in a couple of months, we need to check what a user did the day X because an issue appeared with some resource belonging to that user. DynamoDB seems to be fine, but would it be better to send data directly to dynamoDB or using eventbridge/SQS would be more efficient?
If your application that is sending the data can communicate with DynamoDB directly - send the data there without using any other services. That's more cost effective. EventBridge/SQS are great where you need to queue data (SQS) or have multiple consumers (EventBridge) - in either case where the back-end database doesn't scale. DynamoDB will scale so there's no need to add complexity.
Ok, will do that. Thank you for your help!