Skip to content

Where are graph databases headed?

Graph databases have matured into mainstream information technology. They are no longer esoteric software that’s just emerging from the lab of a startup no one has ever heard of.

Many CIOs are wondering where the development of graph databases is headed. In general, the direction is to add functionality to the graph database and thereby reduce what application software must address. Shifting functionality to operating systems and databases is an information technology trend that’s been underway for decades.
Here are some ideas about the future direction of graph databases.

Response time

We’re all impatient. We don’t want to wait for answers. We really don’t care how many millions of rows or relationships a query has to traverse to complete. We want an answer now.

Today graph databases can materially outperform relational databases in many applications. In the future, graph databases will increase their response time lead and satisfy our impatience.

Data oceans

We’re being inundated by more and more data. Data warehouses have turned into data lakes. New data sources such as IIoT data, e-commerce data, images, audio, and videos are now turning data lakes into data oceans.

In the future, graph databases will continue to increase their ability to cope with, manage, and deliver value from these skyrocketing data volumes.
Related

A quick primer on graph databases

Graph databases have moved from a topic of academic study into the mainstream of information technology in the last few…August 7th, 2020 Yogi Schulz @itworldca

Flexibility

We all clamour for more flexibility because we live in a competitive environment of rapidly changing business requirements. Flexibility requires applications that can respond quickly with:

  1. Low disruption to daily operations.
  2. An acceptable software development cost.
  3. Smooth, non-disruptive transition to new functionality.
  4. Low risk of triggering an unplanned application outage.

Responding to changing business requirements almost invariably requires:

  1. Database schema changes.
  2. Software changes.
  3. Data transformations.
  4. New data values.

In the future, graph database software will meet these technical requirements with:

  1. The capability to respond to schema changes more easily than relational databases.
  2. A more intelligent integrated development environment.
  3. Enhanced extract, transform, and load (ETL) software.
  4. Increasingly efficient, high-performance data loaders.

These graph database features will enable applications to be more responsive to rapidly changing business requirements with lower risk and cost.

Diverse data integration

Let’s face it. Today’s corporate data is scattered all over the place. For example:

  1. There are major datastores associated with important software packages that underlie critical operational applications.
  2. Several departments have signed up for various Software-as-a-Service (SaaS) applications.
  3. Mountains of Excel workbooks contain critical bits of information on network drives.
  4. Some groups license useful external data and integrate it with internal data to create informal applications.
  5. Various document management systems contain huge stores of unstructured data.
  6. Important vendors manage some of our data for better or for worse.

The information technologies associated with these applications span almost everything known to man. Some of these applications are hosted on-premises. Others are hosted in hybrid or cloud environments.

Graph databases typically come with a rich library of tools to integrate data from diverse sources. In the future, this data integration software will:

  1. Become easier to use.
  2. Point out illogical constructs to software developers.
  3. Alert end-users about data quality issues and data integration disconnects.
  4. Automate high effort, mind-numbing data wrangling work.

This graph database capability will enable organizations to squeeze more value from their data regardless of how or where it is stored.

Systems development velocity

Management thinks that every system development project timeline they’ve ever seen is too long. Management understands and is focused on achieving the business value of the first-mover advantage. Ambitious schedule demands from management turn into incredible pressure on software development teams to develop more functionality faster. Sometimes the result is poor quality software. At other times, the result is high project team staff turnover and burnout.

In the future, graph databases will come packaged with components to boost software development productivity and ensure acceptable software quality. The components include:

  1. An increasingly capable integrated development environment (IDE).
  2. A capable graph query language.
  3. A powerful algorithm library.
  4. Enhanced database operation tools.

Algorithm library

Many experienced software developers are not conversant with the advanced math required to program most algorithms. To fill this gap, today’s graph databases come with algorithm libraries. Example capabilities include:

  1. Rich set of graph algorithms.
  2. Customizability of graph algorithms through parameters.
  3. Extensibility of graph algorithms through code.

In the future, algorithm libraries will continue to expand to include in-database support for:

  1. Analytics.
  2. Machine learning.
  3. Handling data quality issues.
  4. Handling some types of software inadequacies.

These libraries will contribute to the goals of more intelligent applications and significantly reducing the need for custom software development and testing.

Graph query language

Today graph databases from different vendors come with different graph query languages, unlike relational databases that come with largely standardized SQL. These graph query languages, syntactically much like SQL, vary in their capability including the extent of their:

  1. Turing-completeness.
  2. Ability to express graph computations.
  3. Ability to process analytics natively.
  4. Support for ad hoc queries.
  5. Support for complex, parameterized procedures.

In the future, graph database standards will emerge that will make it easier to:

  1. Compare the functionality of graph database products.
  2. Train and redeploy staff.

Database operation

Database operation consumes significant staff effort that is often tedious work. Typical tasks include:

  1. Revising database resources allocation.
  2. Running the batch job schedule.
  3. Starting backups, restores, and read replicas.
  4. Promotion and demotion of database images.
  5. Troubleshooting job crashes and hung sessions.
  6. Performing database and application performance monitoring and analysis.

In the future, graph database operations will become more sophisticated and less tedious with enhanced tools for:

  1. Work automation.
  2. Intuitive database and application performance analysis.
  3. Data access contention alerts.
  4. Workload and model management recommendations.
  5. Data and application anomaly detection powered by machine learning.
  6. Query performance analysis with tuning recommendations.
  7. Real-time database health monitoring with results displayed on dashboards.
  8. Problem analysis of log entries.

More sophisticated graph database operations reduce staff effort and improve overall application availability.

Adaptive architecture

We all want systems that are responsive, resilient, and elastic to deliver high performance and high availability. Graph databases are starting to respond to these goals.
In the future, graph databases will include more features that achieve these demanding goals.

Role-based security

Today, ensuring adequate application security is a headache. Most applications require role-based security that defines what data every end-user attached to a role can create, read, update, and delete (CRUD). This security requirement adds significant amounts of software development complexity to every application.

Graph and relational databases already offer some features to address role-based security. In the future, graph databases will include more features that respond to this requirement to reduce software development effort and operational effort.

First published at IT World Canada

Similar Posts: