Need advice about which tool to choose?Ask the StackShare community!
Amazon Athena vs Amazon DynamoDB: What are the differences?
Athena is an interactive query service that allows you to analyze data stored in Amazon S3 using standard SQL, while DynamoDB is a fully managed NoSQL database service designed for high-performance, scalable, and low-latency applications with flexible data models. Let's explore the key differences between them:
Fully Managed vs. Self-Managed: Amazon Athena is a fully managed service, which means that Amazon takes care of the underlying infrastructure for you. It scales automatically, and you only pay for the queries you run. On the other hand, Amazon DynamoDB is a self-managed NoSQL database service, where you have to provision and manage the required infrastructure yourself.
Query vs. Key-Value Store: Amazon Athena is designed for ad-hoc querying of data stored in Amazon S3 using standard SQL queries. It provides the ability to analyze large datasets without the need to set up and manage a database. In contrast, Amazon DynamoDB is a key-value store that is optimized for fast and predictable performance with low-latency access to small, frequently accessed data items.
Schema-on-Read vs. Schema-on-Write: With Amazon Athena, data is stored in Amazon S3 in any format (e.g., JSON, CSV), and you can define the schema on read. This means that you can run queries on the data without explicitly defining the schema beforehand. In contrast, Amazon DynamoDB requires you to define the schema upfront, as it follows a schema-on-write approach. Each item in DynamoDB needs to have the same set of attributes, although the values can vary.
SQL Support vs. NoSQL API: Amazon Athena provides support for standard SQL queries, making it easy for users who are familiar with SQL to interact with their data. On the other hand, Amazon DynamoDB offers a NoSQL API, which allows users to perform CRUD operations (create, read, update, and delete) using the API methods provided by DynamoDB.
Storage Cost vs. Provisioned Capacity: For Amazon Athena, you only pay for the amount of data scanned by your queries, which makes it a cost-effective option for analyzing large datasets. In contrast, Amazon DynamoDB requires you to provision read and write capacity units, even if your workload is unpredictable or sporadic. This means that you have to pay for the provisioned capacity, regardless of how much you actually use.
Workload Types vs. Data Access Patterns: Amazon Athena is well suited for ad-hoc and interactive querying of data, making it ideal for exploratory analysis and data discovery. On the other hand, Amazon DynamoDB is designed for applications that require low-latency access to small data items with simple data access patterns, such as key-value lookups or item scans.
In summary, Amazon Athena is a fully managed service for ad-hoc querying of data stored in Amazon S3 using standard SQL, while Amazon DynamoDB is a self-managed NoSQL database optimized for fast and predictable performance with low-latency access to small data items using key-value lookups or item scans.
We are building a social media app, where users will post images, like their post, and make friends based on their interest. We are currently using Cloud Firestore and Firebase Realtime Database. We are looking for another database like Amazon DynamoDB; how much this decision can be efficient in terms of pricing and overhead?
Hi, Akash,
I wouldn't make this decision without lots more information. Cloud Firestore has a much richer metamodel (document-oriented) than Dynamo (key-value), and Dynamo seems to be particularly restrictive. That is why it is so fast. There are many needs in most applications to get lightning access to the members of a set, one set at a time. Dynamo DB is a great choice. But, social media applications generally need to be able to make long traverses across a graph. While you can make almost any metamodel act like another one, with your own custom layers on top of it, or just by writing a lot more code, it's a long way around to do that with simple key-value sets. It's hard enough to traverse across networks of collections in a document-oriented database. So, if you are moving, I think a graph-oriented database like Amazon Neptune, or, if you might want built-in reasoning, Allegro or Ontotext, would take the least programming, which is where the most cost and bugs can be avoided. Also, managed systems are also less costly in terms of people's time and system errors. It's easier to measure the costs of managed systems, so they are often seen as more costly.
Hi all,
Currently, we need to ingest the data from Amazon S3 to DB either Amazon Athena or Amazon Redshift. But the problem with the data is, it is in .PSV (pipe separated values) format and the size is also above 200 GB. The query performance of the timeout in Athena/Redshift is not up to the mark, too slow while compared to Google BigQuery. How would I optimize the performance and query result time? Can anyone please help me out?
you can use aws glue service to convert you pipe format data to parquet format , and thus you can achieve data compression . Now you should choose Redshift to copy your data as it is very huge. To manage your data, you should partition your data in S3 bucket and also divide your data across the redshift cluster
First of all you should make your choice upon Redshift or Athena based on your use case since they are two very diferent services - Redshift is an enterprise-grade MPP Data Warehouse while Athena is a SQL layer on top of S3 with limited performance. If performance is a key factor, users are going to execute unpredictable queries and direct and managing costs are not a problem I'd definitely go for Redshift. If performance is not so critical and queries will be predictable somewhat I'd go for Athena.
Once you select the technology you'll need to optimize your data in order to get the queries executed as fast as possible. In both cases you may need to adapt the data model to fit your queries better. In the case you go for Athena you'd also proabably need to change your file format to Parquet or Avro and review your partition strategy depending on your most frequent type of query. If you choose Redshift you'll need to ingest the data from your files into it and maybe carry out some tuning tasks for performance gain.
I'll recommend Redshift for now since it can address a wider range of use cases, but we could give you better advice if you described your use case in depth.
It depend of the nature of your data (structured or not?) and of course your queries (ad-hoc or predictible?). For example you can look at partitioning and columnar format to maximize MPP capabilities for both Athena and Redshift
you can change your PSV fomat data to parquet file format with AWS GLUE and then your query performance will be improved
Pros of Amazon Athena
- Use SQL to analyze CSV files16
- Glue crawlers gives easy Data catalogue8
- Cheap7
- Query all my data without running servers 24x76
- No data base servers yay4
- Easy integration with QuickSight3
- Query and analyse CSV,parquet,json files in sql2
- Also glue and athena use same data catalog2
- No configuration required1
- Ad hoc checks on data made easy0
Pros of Amazon DynamoDB
- Predictable performance and cost62
- Scalable56
- Native JSON Support35
- AWS Free Tier21
- Fast7
- No sql3
- To store data3
- Serverless2
- No Stored procedures is GOOD2
- ORM with DynamoDBMapper1
- Elastic Scalability using on-demand mode1
- Elastic Scalability using autoscaling1
- DynamoDB Stream1
Sign up to add or upvote prosMake informed product decisions
Cons of Amazon Athena
Cons of Amazon DynamoDB
- Only sequential access for paginate data4
- Scaling1
- Document Limit Size1
Sign up to add or upvote consMake informed product decisions
What is Amazon Athena?
What is Amazon DynamoDB?
Need advice about which tool to choose?Ask the StackShare community!
What companies use Amazon DynamoDB?
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with Amazon DynamoDB?
Sign up to get full access to all the tool integrationsMake informed product decisions
Blog Posts
+17
+16
+25
+47+46
+30
+23+37