Learn how to use a NoSQL database like DynamoDB by implementing data models using single table design patterns. This approach allows users to manage multiple data structures efficiently within a single table. I'd rate the solution eight out of ten.
It's easy to maintain the solution. We had some issues with the backups because DynamoDB has internal backups or restore points. We're trying to have backups with AWS, which is more expensive than having the backups in DynamoDB. We're also trying to make a configuration with Lambda functions to save the backups into S3, but that is more expensive than an AWS backup. I don't know if there is another way that we can have that backup. When we have to put in progress a disaster recovery plan, we can have those backups. Overall, I rate the solution an eight out of ten.
Senior Engineering Consultant at ASSURANCE IQ, INC.
Real User
Top 5
2024-06-24T07:44:59Z
Jun 24, 2024
I recommend you use the tool. I don't think there is an issue using Amazon DynamoDB. We only have to consider the value size limitations of 400 KB. If you want to install more than 400 KB of data in a value, obviously, we'll have less value in the key. But suppose there are a lot of big values in the key value storage type. We need to consider whether the value is predictable and whether it exceeds 400 KB. It is very easy for beginners to start using the product. The feature of the product associated with global tables is something that is used only for the replicas. Most of the time, we only have the replicas being available on EC2, so we do not need to make it available through the different availability zones or regions. We made some replicas to make the tool stabilized. We don't need to have replicas for different reasons because all our customers who use those are from the US, and some specific regions. For monitoring and security features, my company normally uses CloudOps and other different tools like Datadog. My company has not directly used anything from Amazon DynamoDB for monitoring. For performance, I rate the tool a nine and a half out of ten. Considering the value storage limitation, I rate the tool an eight out of ten.
DynamoDB doesn't directly support AI-driven applications, but it can certainly be used as a backend database for such applications. I would rate Amazon DynamoDB an eight out of ten, primarily for its reliability, scalability, and security features.
I'd suggest starting with a static approach. Once everything is stable, then you can gradually enhance the features by transitioning from static to using DynamoDB. It's best to avoid starting with DynamoDB from the beginning. It is not easy for a beginner to learn how to use it. It will take some time. Overall, I would rate the solution an eight out of ten.
If you're using DynamoDB, you also need to understand Lambda coding. In programming, we handle everything, including creating a DynamoDB table, which only takes a few minutes. Once the data management panel is created, we primarily use Lambda for operations. Lambda requires us to write the code for tasks like storing and managing data. DynamoDB is generally straightforward to work with. For example, I navigate to DynamoDB to create a table and make it. However, you'll need to understand various programming concepts and optimize your code for more complex tasks like working with large datasets. To create the table and input data manually, we need to be proactive. However, updating and handling such tasks programmatically can be challenging. It becomes necessary when developers need to manipulate data through coding, particularly Node.js, Python, or Java. Managing the structure comprehensively while using DynamoDB can pose difficulties. You can proceed with that option if you want to store data manually. However, from an application perspective, you would need to hire a developer to perform the necessary actions to expose the data through a gateway for other users. It's essential to consider CAPA for applications and presentations. The relevant teams need to develop these CAPA aspects. DynamoDB comes into play to manage the data. We can seamlessly switch data between the backend and the APM. The frontend OS fetches this data from the APM to display in the UI, allowing users to access all the necessary information from the database. All the data will be synchronized if you store data in one region and access a global table in another. Any data in one table will also be present in the other. Security is paramount with Amazon DynamoDB. Everything is handled, so we're not exposing anything. It offers controlled access, ensuring users have their data. If you have the necessary access rights, you can check the data. Otherwise, secret access is not granted. The cloud takes care of everything seamlessly. Overall, I rate the solution a nine out of ten.
DynamoDB is one of the services that 90% of people use on AWS. Let's say we are developing an application using AWS. For the backend data storage, DynamoDB is the best solution AWS offers for NoSQL databases. If SQL is needed, then RDS is the way to go. You must understand the basic CRUD operations of databases, along with the APIs. Knowing how to create a schema, determining primary and foreign keys is essential. The AWS documentation provides detailed guidance on these. DynamoDB supports multiple areas and has good monitoring and security features. AWS CloudWatch can be used for monitoring, and third-party tools like Datadog or additional integration are available for functionality. Overall, I rate the solution a nine out of ten.
We are very much satisfied with Amazon DynamoDB's global tables feature. It was very easy for me to learn to use Amazon DynamoDB. After one week of upskilling, I was able to query and use the solution. The solution has a very user-friendly interface. If you don't know about queries, you can filter out data with the interface without writing complex queries. Our company decided to use Amazon DynamoDB because it is a serverless, NoSQL database. Amazon DynamoDB has a very complex configuration if you go very advanced. So, start with the basics and use PK and SK only. After that, you can jump to search indexes. If you have some advanced use cases, the configuration might have some complexities. Amazon DynamoDB has good scalability, and it is very fast for querying. Overall, I rate the solution ten out of ten.
Amazon DynamoDB automatically publishes AWS CloudWatch metrics that provide information on health and performance, read-write capacity, system errors, and conditional check fail requests. It is easy for somebody to learn to use Amazon DynamoDB. I would recommend the solution to other users. Overall, I rate the solution ten out of ten.
It helps us store user advertising data, enabling efficient analysis and data management. The platform's advantage is related to fast access to real-time information for scalability. We can access the data storage from different zones and versions. We can configure it in a way that can improve writing and reading as well. It is a good product. It supports a lot of functionalities, scalability, and multiple versions. I rate it an eight out of ten.
It is a good investment. We were able to use it in automation. It was easy to use. Even the new joiners were able to use it effectively. All our automation was effectively stored, and we could build the dashboard out of it to present to the higher management. Anyone who wants to explore a NoSQL database in the cloud must use DynamoDB. Overall, I rate the product a ten out of ten.
If you've done your data architecture and analyzed what you'll be using your data for, where you'll be using it, and you have your data flows and conceptual model, and you see that it's a sequential storage of keys with values attached to it, DynamoDB is a valuable and valid option. However, don't use it just because it's easy. You should use it when you don't need some of the other aspects of a relational database, like joining, multiple endpoints, and comparing or having a key on multiple datasets. If that's your use case, if you want it for your entire application, don't use DynamoDB. But if it's for something simple, like a record of sales or events happening on a particular day or moment, please do use DynamoDB. It all comes down to the quality of your data architect. I would give it a ten in some cases and a zero in others. For example, if you want to have a research database where you need multiple perspectives on the same set of data, and you try to do that within DynamoDB, you're going to have trouble. But if you have a log and you want to do some statistical research on, for example, the sales in a supermarket, which are a simple timeline with the cash register data, timestamp, value, and then the goods, that's all very simple, key-value, and you can use DynamoDB for that. So, it depends on the use case. For the use cases that you're using it for, you would give it a ten. So, the solution is excellent for the purpose you're using it for. For my use cases, I would rate it an eight out of ten. We chose DynamoDB. We could have done the same thing with a relational database, but then again, you wouldn't choose a Bentley Continental GTR just to go to the grocery store. You can go to the grocery store on a scooter. We decided against the relational database because of the overhead and cost, and we went with DynamoDB instead. Because the dataset is just a key timestamp and some values, a key and a value, we can restore them sequentially, which is exactly what DynamoDB can do without any problems.
If we go through the main DynamoDB, it will be a scan operation. It will scan through each record. If we set up a secondary index for a particular query type, we can get it fast. It is the fastest way to get it. In a normal database, if we launch something into production and want to add one more feature, but the feature needs an additional query, and the existing table cannot perform the query fast, we will have to remodel the entire table. It will interrupt the process. In DynamoDB, we can just add one more secondary index and route that query to the secondary index. If someone wants to use the solution, they should go ahead. It is as good as anything else. Overall, I rate the product a nine out of ten.
Have database experience not just in relational databases, but also in non-relational databases, as well as AWS or configuration experience. I would rate Amazon DynamoDB a nine out of ten.
My advice to those implementing DynamoDB would be to forget everything you know about database normalization. That's what I would recommend because if you are a real expert with relational databases, it's going to be a bit of a mind warp to use DynamoDB. It would be the same mind warp as if you were using Mongo or any other document or non-relational database. You just have to try not to force it to act like SQL. Treat it like it should be treated. It's definitely a 10 out of 10.
I rate this solution a seven out of ten. Amazon DyanamoDB has its triggers, and we would like them to simplify the process of adding a trigger without taking care of the API code. Once something has changed inside of it, it triggers a function. You can bind Lambda Function, but it's tricky because their containers are working. So, you need to know every detail about Amazon containers. So, Amazon DynamoDB creates a default and runs the function for us. So the only thing that I would be responsible for is adding our code.
If it is a real-time system, very specific to the domain, it is a great solution. If it is embedded, has huge data, the frequency is quite high to store that data, and the device is in a remote area or there is no connectivity, then this solution is perfect. However, if the device is connected through the internet, then it's definitely not a good solution. That is, if it is connected to the internet and proper connections are there, then this solution will not be not feasible. If I were to rate this solution, I would rate it at six on a scale from one to ten.
Principal at a computer software company with 11-50 employees
Real User
2021-08-24T20:32:37Z
Aug 24, 2021
I would recommend anyone looking to implement any software to understand the needs of their business and do a purpose analysis to determine if the software fits their use case. No matter how good a solution can be if it does not fit the purpose of the business it will not be helpful. I rate Amazon DynamoDB an eight out of ten.
Engineering Intern at a tech services company with 51-200 employees
Real User
2021-04-01T10:12:33Z
Apr 1, 2021
I would recommend this solution based on the use case. It is pretty straightforward, and we haven't had any major issues. It is just plug-and-play. There is nothing else that you need to do. I would rate Amazon DynamoDB an eight out of ten.
Expert Solution Principal at a tech services company with 10,001+ employees
Real User
2019-09-15T16:44:00Z
Sep 15, 2019
We are using the public cloud deployment model. I would rate the solution eight out of ten. I'm quite satisfied with the solution. Querying could always be better, but it's a typical complaint.
Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. You can use Amazon DynamoDB to create a database table that can store and retrieve any amount of data, and serve any level of request traffic. Amazon DynamoDB automatically spreads the data and traffic for the table over a sufficient number of servers to handle the request capacity specified by the customer and the amount of data stored, while maintaining...
Learn how to use a NoSQL database like DynamoDB by implementing data models using single table design patterns. This approach allows users to manage multiple data structures efficiently within a single table. I'd rate the solution eight out of ten.
It's easy to maintain the solution. We had some issues with the backups because DynamoDB has internal backups or restore points. We're trying to have backups with AWS, which is more expensive than having the backups in DynamoDB. We're also trying to make a configuration with Lambda functions to save the backups into S3, but that is more expensive than an AWS backup. I don't know if there is another way that we can have that backup. When we have to put in progress a disaster recovery plan, we can have those backups. Overall, I rate the solution an eight out of ten.
I recommend you use the tool. I don't think there is an issue using Amazon DynamoDB. We only have to consider the value size limitations of 400 KB. If you want to install more than 400 KB of data in a value, obviously, we'll have less value in the key. But suppose there are a lot of big values in the key value storage type. We need to consider whether the value is predictable and whether it exceeds 400 KB. It is very easy for beginners to start using the product. The feature of the product associated with global tables is something that is used only for the replicas. Most of the time, we only have the replicas being available on EC2, so we do not need to make it available through the different availability zones or regions. We made some replicas to make the tool stabilized. We don't need to have replicas for different reasons because all our customers who use those are from the US, and some specific regions. For monitoring and security features, my company normally uses CloudOps and other different tools like Datadog. My company has not directly used anything from Amazon DynamoDB for monitoring. For performance, I rate the tool a nine and a half out of ten. Considering the value storage limitation, I rate the tool an eight out of ten.
DynamoDB doesn't directly support AI-driven applications, but it can certainly be used as a backend database for such applications. I would rate Amazon DynamoDB an eight out of ten, primarily for its reliability, scalability, and security features.
I recommend that others use Amazon DynamoDB, but the expenditure must be calculated beforehand. I would rate the product an eight out of ten.
Overall, I rate the product a seven out of ten.
I'd suggest starting with a static approach. Once everything is stable, then you can gradually enhance the features by transitioning from static to using DynamoDB. It's best to avoid starting with DynamoDB from the beginning. It is not easy for a beginner to learn how to use it. It will take some time. Overall, I would rate the solution an eight out of ten.
If you're using DynamoDB, you also need to understand Lambda coding. In programming, we handle everything, including creating a DynamoDB table, which only takes a few minutes. Once the data management panel is created, we primarily use Lambda for operations. Lambda requires us to write the code for tasks like storing and managing data. DynamoDB is generally straightforward to work with. For example, I navigate to DynamoDB to create a table and make it. However, you'll need to understand various programming concepts and optimize your code for more complex tasks like working with large datasets. To create the table and input data manually, we need to be proactive. However, updating and handling such tasks programmatically can be challenging. It becomes necessary when developers need to manipulate data through coding, particularly Node.js, Python, or Java. Managing the structure comprehensively while using DynamoDB can pose difficulties. You can proceed with that option if you want to store data manually. However, from an application perspective, you would need to hire a developer to perform the necessary actions to expose the data through a gateway for other users. It's essential to consider CAPA for applications and presentations. The relevant teams need to develop these CAPA aspects. DynamoDB comes into play to manage the data. We can seamlessly switch data between the backend and the APM. The frontend OS fetches this data from the APM to display in the UI, allowing users to access all the necessary information from the database. All the data will be synchronized if you store data in one region and access a global table in another. Any data in one table will also be present in the other. Security is paramount with Amazon DynamoDB. Everything is handled, so we're not exposing anything. It offers controlled access, ensuring users have their data. If you have the necessary access rights, you can check the data. Otherwise, secret access is not granted. The cloud takes care of everything seamlessly. Overall, I rate the solution a nine out of ten.
DynamoDB is one of the services that 90% of people use on AWS. Let's say we are developing an application using AWS. For the backend data storage, DynamoDB is the best solution AWS offers for NoSQL databases. If SQL is needed, then RDS is the way to go. You must understand the basic CRUD operations of databases, along with the APIs. Knowing how to create a schema, determining primary and foreign keys is essential. The AWS documentation provides detailed guidance on these. DynamoDB supports multiple areas and has good monitoring and security features. AWS CloudWatch can be used for monitoring, and third-party tools like Datadog or additional integration are available for functionality. Overall, I rate the solution a nine out of ten.
We can use Amazon DynamoDB for both on-premises and in the cloud. Overall, I rate the solution a seven out of ten.
We are very much satisfied with Amazon DynamoDB's global tables feature. It was very easy for me to learn to use Amazon DynamoDB. After one week of upskilling, I was able to query and use the solution. The solution has a very user-friendly interface. If you don't know about queries, you can filter out data with the interface without writing complex queries. Our company decided to use Amazon DynamoDB because it is a serverless, NoSQL database. Amazon DynamoDB has a very complex configuration if you go very advanced. So, start with the basics and use PK and SK only. After that, you can jump to search indexes. If you have some advanced use cases, the configuration might have some complexities. Amazon DynamoDB has good scalability, and it is very fast for querying. Overall, I rate the solution ten out of ten.
Amazon DynamoDB automatically publishes AWS CloudWatch metrics that provide information on health and performance, read-write capacity, system errors, and conditional check fail requests. It is easy for somebody to learn to use Amazon DynamoDB. I would recommend the solution to other users. Overall, I rate the solution ten out of ten.
It helps us store user advertising data, enabling efficient analysis and data management. The platform's advantage is related to fast access to real-time information for scalability. We can access the data storage from different zones and versions. We can configure it in a way that can improve writing and reading as well. It is a good product. It supports a lot of functionalities, scalability, and multiple versions. I rate it an eight out of ten.
It is a good investment. We were able to use it in automation. It was easy to use. Even the new joiners were able to use it effectively. All our automation was effectively stored, and we could build the dashboard out of it to present to the higher management. Anyone who wants to explore a NoSQL database in the cloud must use DynamoDB. Overall, I rate the product a ten out of ten.
If you've done your data architecture and analyzed what you'll be using your data for, where you'll be using it, and you have your data flows and conceptual model, and you see that it's a sequential storage of keys with values attached to it, DynamoDB is a valuable and valid option. However, don't use it just because it's easy. You should use it when you don't need some of the other aspects of a relational database, like joining, multiple endpoints, and comparing or having a key on multiple datasets. If that's your use case, if you want it for your entire application, don't use DynamoDB. But if it's for something simple, like a record of sales or events happening on a particular day or moment, please do use DynamoDB. It all comes down to the quality of your data architect. I would give it a ten in some cases and a zero in others. For example, if you want to have a research database where you need multiple perspectives on the same set of data, and you try to do that within DynamoDB, you're going to have trouble. But if you have a log and you want to do some statistical research on, for example, the sales in a supermarket, which are a simple timeline with the cash register data, timestamp, value, and then the goods, that's all very simple, key-value, and you can use DynamoDB for that. So, it depends on the use case. For the use cases that you're using it for, you would give it a ten. So, the solution is excellent for the purpose you're using it for. For my use cases, I would rate it an eight out of ten. We chose DynamoDB. We could have done the same thing with a relational database, but then again, you wouldn't choose a Bentley Continental GTR just to go to the grocery store. You can go to the grocery store on a scooter. We decided against the relational database because of the overhead and cost, and we went with DynamoDB instead. Because the dataset is just a key timestamp and some values, a key and a value, we can restore them sequentially, which is exactly what DynamoDB can do without any problems.
I would rate the solution a seven out of ten.
If we go through the main DynamoDB, it will be a scan operation. It will scan through each record. If we set up a secondary index for a particular query type, we can get it fast. It is the fastest way to get it. In a normal database, if we launch something into production and want to add one more feature, but the feature needs an additional query, and the existing table cannot perform the query fast, we will have to remodel the entire table. It will interrupt the process. In DynamoDB, we can just add one more secondary index and route that query to the secondary index. If someone wants to use the solution, they should go ahead. It is as good as anything else. Overall, I rate the product a nine out of ten.
Overall, I rate the solution an eight out of ten.
Have database experience not just in relational databases, but also in non-relational databases, as well as AWS or configuration experience. I would rate Amazon DynamoDB a nine out of ten.
I would rate this solution an eight out of ten.
My advice to those implementing DynamoDB would be to forget everything you know about database normalization. That's what I would recommend because if you are a real expert with relational databases, it's going to be a bit of a mind warp to use DynamoDB. It would be the same mind warp as if you were using Mongo or any other document or non-relational database. You just have to try not to force it to act like SQL. Treat it like it should be treated. It's definitely a 10 out of 10.
I rate this solution a seven out of ten. Amazon DyanamoDB has its triggers, and we would like them to simplify the process of adding a trigger without taking care of the API code. Once something has changed inside of it, it triggers a function. You can bind Lambda Function, but it's tricky because their containers are working. So, you need to know every detail about Amazon containers. So, Amazon DynamoDB creates a default and runs the function for us. So the only thing that I would be responsible for is adding our code.
If it is a real-time system, very specific to the domain, it is a great solution. If it is embedded, has huge data, the frequency is quite high to store that data, and the device is in a remote area or there is no connectivity, then this solution is perfect. However, if the device is connected through the internet, then it's definitely not a good solution. That is, if it is connected to the internet and proper connections are there, then this solution will not be not feasible. If I were to rate this solution, I would rate it at six on a scale from one to ten.
I would recommend anyone looking to implement any software to understand the needs of their business and do a purpose analysis to determine if the software fits their use case. No matter how good a solution can be if it does not fit the purpose of the business it will not be helpful. I rate Amazon DynamoDB an eight out of ten.
I would recommend this solution based on the use case. It is pretty straightforward, and we haven't had any major issues. It is just plug-and-play. There is nothing else that you need to do. I would rate Amazon DynamoDB an eight out of ten.
We are using the public cloud deployment model. I would rate the solution eight out of ten. I'm quite satisfied with the solution. Querying could always be better, but it's a typical complaint.