2 Antworten
- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
1
Expanding the answer a little bit more:
It could be also depending on what is the data and how it could be used / retrieved. For example:
- AuroraDB: Using relational Databases, could be a great option if your access pattern involve more than 1 table, also can be serverless
- DynamoDB: accessing data by Key-Value, not enforcing schema, and using DAX (DynamoDB Accelerator) could be a very fast solution for microsecond latency, also in a serverless fashion for scalable needs.
- DocumentDB: Its MongoDB compatible and could have a lot of functionality from that, also schemaless but needs to be provisioned, Single digit millisecond latency.
Both Purpose Built Databases, in a fully managed perspective, has their own advantages, managing a variety of use cases normally from system of interactions (User profiles, Sessions, Sensors etc. etc.) to system of records
Being a Stock Broker application and knowing more on the data that is inside maybe we can choose from other few options:
- Timestream: Collect data with in a time series for example for stock prices comparison over the time, when more Analytics could be needed, this could be also more easy to create reports on AWS Quicksight
Maybe knowing more about the use case and the type of data could help to choose the right tool for the right job.
Best regards!
beantwortet vor einem Jahr
0
- Aurora is serverless database which supports relational db schemas. It is 3 times faster than Postgrel sql and 5 times faster than Mysql.
- RDS also supports relational db schemas but here we need to scales our db in our own way.
- Dynamodb will be good for a large dataset which supports no sql data structure. But in dynamodb we have to keep in mind that, if we have any feature that need more searchable thing then it is not easy in dynamodb. And also in case of sorting data in a particular way, we have to make our access pattern.
beantwortet vor einem Jahr
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
Wise decision to use SQS to alleviate write pressure regardless of the data store. However, we need to determine how the data store, you're writing to, is being read or used. That might better factor into your decision on what data store to use.