Oracle sponsored this post.
In modern applications, databases play a central role that goes far beyond capturing simple transactions and generating monthly reports. Now, customers and users are their own transaction agents. They do business from mobile phones, laptops and other devices — any time of day or night. This creates a compounding of data that needs to be stored and shared constantly. If it’s not, the application will miss the real-time cues that are so valuable to today’s customer relationships.
Many developers are making their way through this complex landscape by working with piecemeal solutions — database technologies and architectures reached for as needed, over time. Some of them are proprietary, some homegrown and others open source.
On one level, that makes sense: As IT has advanced, data types such as key-value, spatial, graph, blockchain, document, time series, and IoT have emerged. Each of these datasets must co-exist with relational data. When seen in its totality, every modern, data-driven application has inherent data-type complexity. As a result, workloads like transactional, analytics, machine learning and IoT require different database algorithms to solve for unique demands.
But while single-purpose databases might appear to be best-of-breed in isolation, they quickly become worst-of-weakness when cobbled and patched together — data fragments and security become inconsistent and administration ad hoc. The systems become more brittle as data compounds, hampering a company’s agility and ability to innovate.
A different approach is to use a unified database engine that can handle all of these data types and use cases. A single, multimodel database can encompass relational, JSON, XML, graph, spatial and OLAP; and facilitate different kinds of workloads, such as transactions, analytics, in-memory, IoT, steaming and blockchain.
In a recent blog post, Arvind Bhope takes readers through a day in the life of a fictitious retail company, eShop.biz, and shows how the two different approaches play out.
In one scenario, eShop.biz’s developers use a converged database (in this case, an Oracle database) to provide one database for all development. In his example, the single database architecture means that DevOps can provision dev and test environments more quickly, while APIs and queries can be written across data types.
He also shows how the single converged database gives system admins and DBAs more control over the things they care about, like consistent high availability and disaster recovery across all data types and data processes. It helps them simplify the process of how data is governed, secured, redacted, and masked for testing and support.
In Arvind’s post, the converged database simplified IT operations and allowed the business to be more responsive to business challenges and opportunities. Check out the converged database workshop, to get hands-on experience working with a multimodel database.
Lead image via Pixabay.