The relative immaturity of databases such as multi-model also needs to be considered. “There still remains a long journey toward a mature and robust multi-model DBMS comparable with verified solutions from the world of relational databases,” according to Helsinki University’s Lu.
IT leaders “need to be brave when faced with graphs, because the model is different from what they’ve done for their whole career,” said Webber. “An open mind and a little reading will get them in the right mindset.” From there, picking a reasonably well-understood graph problem—such as product recommendations or customer relationships—and solving it with a graph implementation is the gateway to a bigger universe of graph technology, including sophisticated analysis and machine learning, Webber explained.
In addition, smaller organizations simply may not have the time or expertise to implement a variety of database types. “Smaller businesses, with fewer resources, may have far less understanding of these complex tools and the opportunities for its use,” said Disruptive Diva’s Robin.
DECISION TIME
It comes down to assessing these factors when determining the best fit for business applications and data. “There are many datasets which cannot be stored in a traditional RDBMS,” said LaPorte. “The question we must ask is whether that’s the best choice.” LaPorte puts this another way: Is there a different technology, or group of technologies, which suit the use case more cleanly?”
Traditional relational databases “were primarily engineered for transactions,” said Exasol’s Rathee. “Some of the jobs that traditional relational databases do not handle well include high-performance or real-time analytics, IoT use cases that require very high ingest rates and cheap archived storage of mostly non-useful event data, time series data, and relationship and network analysis as done by graph databases, and AI.”
The need for business flexibility also is a major factor that may lead away from more traditional databases. “I encourage people to not limit themselves to one solution when a combination of technologies may often provide a better overall solution,” said LaPorte. “For example, one high-throughput solution uses Cassandra for permanent storage and analytics, along with a Solr front end for interactive uses.”
In this way, “stringing together a search engine like Apache Solr with Cassandra and Apache Spark provides an incredibly flexible approach to replacing large-scale interactive applications with dynamic automated data,” LaPorte continued. “Something like this would have historically been shoehorned into a traditional RDBMS deployment with multiple compromises, resulting in fragile applications running on top. Plus, due to its size and complexity, it may also have required frequent care and feeding from a DBA to ensure its reliable performance and stability.”
A forward-looking approach is key. “As with most decisions, it’s best not to limit your scope to the problem in front of you but to think about what the landscape will look like 5 to 10 years from now,” said LaPorte. “How will your data grow? How will access patterns change? How liquid is your data? The more liquid and flexible your data is, the easier it will be to pivot as your use cases evolve.”