Issue link: https://resources.awscloud.com/i/1496542
©2020 IDC #US47078920 2 Because relational databases were so easy to query, they were used initially for data analytics, but over time, businesses wanted to base their data in a single system, so relational database management systems (RDBMSs) evolved to include online transactional processing (OLTP) as well as analytic capabilities. By the early 1990s, RDBMS was considered the standard for all manner of data management, and competing forms were largely relegated to the edges of the data management landscape. But then came a series of profound changes. These began with the development of much more powerful processors capable of 64-bit addressability, which meant they could handle far greater amounts of data in memory than had been previously possible. High-speed networks enabled the transmission of much more data much faster than ever before, storage itself became cheaper and faster, and the cost of processors and memory plunged in price relative to their capacity. In addition to these physical improvements, different kinds of applications began to emerge that demanded greater flexibility, scalability, and capacity than relational DBMSs could handle. There was also a need to handle data such as streaming sensor and IoT data, smart mobile device data, log data, and others that had formats that did not fit gracefully into a relational table structure. In many cases, to form a complete set of business data for an operation, it may be necessary to execute a query that joins a number of tables in order to extract the related values, and this creates both complexity in the query and some rigidity in terms of application development. So people began experimenting with different modes of data management, sparking the emergence of the NoSQL movement. These began with document databases, some processing a document standard called XML (Extensible Markup Language), then others supporting another document standard called JSON (JavaScript Object Notation), then Hadoop for data lakes (very large unstructured data collections), and then came key- value stores and wide column stores. All these offered better scalability and flexibility for a variety of jobs that RDBMSs struggled to support. Now, changes in system architectures and levels of virtualization support have enabled public cloud services to emerge, and with them the idea of pay-as-you-go services. Applications developed for these public clouds are designed to take full advantage of the ability to limit resources used by adopting a microservices architecture and running the code in containers, where application actions can execute and go away, ensuring that one is only billed for the processors used as they are used and are not resident in fixed servers. A common aim of microservices is to achieve a "serverless architecture" (one in which applications run in various servers on a dynamic basis rather than sitting resident in specific servers). Microservices make special demands on the database, and it's important to have a DBMS that is designed not only for the type of data being handled but also to satisfy the operational requirements of a serverless application. Today, in addition to the older, mostly mainframe-based navigational and multivalue DBMSs (many of which are being viewed as requiring conversion to newer forms to move to the public cloud), we have RDBMSs, document DBMSs, wide column stores, key-value stores, graph DBMSs, and more. Each of these operational models can be very well attuned to specific workloads and do a better job than any one architecture could do in attempting to support all data management needs.