Why Your NoSQL Database Should Be Multimodal

3 min read
Curated from medium.com →

Why Your NoSQL Database Should Be Multimodal

IDC recently published its list of the biggest innovators in multimodal databases. However, what the heck is a multimodal database? First off, I hate the term multimodal, I prefer “general use” or “evolved.” In essence, a multimodal database is what you always assumed a database was.

In a literal sense, multimodal means more than one mode, so a key-value store and a document database together for instance. There are a lot of places where you just need lookups. In the RDBMS these were “primary key lookups.” These are often done in memory (aka a cache). However, most modern applications rely on JSON as a data structure and it is rare that you don’t need to query the underlying fields, so the document database is still king. There are other combinations, but you at least need these modes in most organizations.

For most of computing history, databases were assumed to be multimodal or — to be more precise — general use. When I started my career in the mid-90s, at Ericsson Cellular, we used Oracle (and later a combination of Oracle and SQL Server) as an operational database. We also used Oracle as a data warehouse. Specialty databases like Teradata were out there, but we didn’t need them for the amount of data we were processing at the time.

The growth of the web and so-called digital transformation changed that, we’ve now got more data than we can ever do anything meaningful with and the number of users interacting with that data has massively increased. Additionally, the types of data we’re capturing and holding have expanded.

With the NoSQL revolution, we started paying more attention to other database types such as graph databases, key-value store database, and document databases. These stopped being mere theory and were put into production.

At first, the purveyors of these new databases began on the attack. “You don’t need joins” and “SQL considered harmful.” The promise was scale. And having watched the Slashdot effect and massive e-commerce outages every holiday, it was clear that sticking a webserver and an application server in front of a relational database wasn’t really working on the modern Internet. Moreover, Object-Relational Mapping tools weren’t keeping up with the complexity of data and table structures didn’t easily capture the modern structure of changing data without a lot of painful transformation.

It turns out that NoSQL databases were just immature. MongoDB and Couchbase both added ACID transaction support. Couchbase among others added SQL support. Couchbase even added an MPP (data warehouses like Teradata have MPP support).

Continue Reading

Enjoyed this summary? Read the complete article at the source:

Continue at medium.com →

Yves Mulkers

Yves Mulkers is the founder of 7wData and a widely followed voice in the data and AI community. He curates the 7wData and AI Beat newsletters, reaching hundreds of thousands of data and AI professionals, and writes on data strategy, analytics, AI, and the evolving data ecosystem.