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...
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.