One question I am frequently asked is: why do we offer so many different database products? From my point of view, the answer is simple: developers want their applications to have a solid architecture and to be able to scale efficiently. To do this, they need to be able to use multiple databases and data models within the same application.
Few are the cases in which a single database can cover the needs of multiple different use cases. The days of monolithic databases that were valid for everything are over. Today, developers create highly distributed applications using a host of databases structured specifically for them. Developers continue to do what has always been their specialty: breaking complex applications down into smaller components, thus choosing the best tools to solve every problem. The best tool for a task usually varies depending on the use to be made of it.
For decades, with relational databases being the only option available, regardless of the form or function of the data contained in the application, we modeled the data following a relational model. Instead of being the use case that defined the requirements that the database had to fulfill, the reality was the other way around. It was the databases that imposed a data model, which the applications had to use. But are relational databases not specifically designed for non-standard schemas and to ensure referential integrity of the database? Of course, but the key I want to get to is that not all application or use case data models fit within the relational model.
As I have previously discussed, one of the reasons that led us to create DynamoDBAt the time it was that Amazon was reaching the limits of what was possible with what was one of the best databases for businesses of its time. We were unable to meet the availability, scalability, and performance needs to be demanded by the rapid growth of Amazon.com. Investigating, we discovered that approximately 70% of our operations were key-value queries, in which only one primary key was used and the result was a single entry. By not requiring referential integrity or referential transactions, we concluded that it would be better to respond to these access patterns using a database that follows a different model. Also, given the rapid growth and large scale of Amazon.com, Having virtually unlimited horizontal scalability became a key element in the design of our solutions. Scaling up as needed was simply not an option. Ultimately it was this that led to the creation of DynamoDB, a non-relational database service designed to scale beyond what is possible using relational databases.
I do not mean to say that relational databases cannot be of use in current development, nor are they incapable of offering high availability, scalability, or performance. Quite the contrary. In fact, this is something our customers have made clear, as Amazon Aurora continues to be the fastest-growing service in AWS history. What we experienced with Amazon.com was an example of using a database beyond its initial purpose. This type of lesson is one of the keys to this article: databases are created for a purpose and aligning the use case with the nature of the database will help you accelerate your high-performance application development projects and great functionality and availability.
The world is constantly changing and, in a similar way, the types of non-relational databases continue to increase in number. With increasing frequency, we see how our clients seek to create applications for use over the Internet that require various data models. To meet these needs, today’s developers can choose from databases such as relational, key-value, documentary, graph-oriented, in-memory, or search. Each of these types of databases allows solving a specific type or types of problems.
Let’s see in more detail the purpose of each of these types of databases:
Developers continue to create high tiered, unlinked distributions, and AWS gives them the ability to create these cloud-native applications using multiple AWS services. Take Expedia as an example. Although in the eyes of the consumer the Expedia page seems like a single application, its operation involves a large number of components, each with a specific function. By breaking down an app like Expedia.com into multiple components for specific purposes (like AWS Lambda microservices, containers, and functions), developers increase their productivity by increasing their scalability and performance, reduce the number of their operations, increase their agility in implementing and can evolve the various components independently. In addition, when creating applications, developers have the ability to choose the database that best suits each use case.
To see what this translates into real use, let’s see how some of our clients use different databases to create their applications:
In the same way that they have stopped developing monolithic applications, developers are giving up using a single database for all possible uses of their application. Instead, they use several. Although relational databases are still in good health and very valid for many applications, databases created specifically for models such as key-value, documentary, graph-oriented, in-memory, and search can help you optimize your functionality, performance, scale and, most importantly, the experience of your customers. Do not stop creating.
If you have lost or damaged your vehicle's registration certificate, you must be tense and…
Phaneesh Murthy's career is a masterclass in leadership and innovation within the IT services sector.…
Few companies miss out on redesigning the logo: it is an essential step in the…
In today’s fast-paced world it’s easy to miss the treasures hidden in online libraries. These…
AI video generators are presently transforming the way companies and content creators create videos. With…
Strong anti-malware program IObit Malware Fighter 11 Free guards personal computers against a broad range…