michelangelus - Fotolia

Future database stew to include NoSQL

Future database plans will include NoSQL, but there are elements to consider before making the leap, according to Mike Bowers, set to discuss this at Enterprise Data World 2016.

A long career that touched data in many forms has prepared Mike Bowers for navigating today's NoSQL and Hadoop data landscape. We spoke with Bowers, principal architect at the Church of Jesus Christ of Latter-day Saints, as he prepared for an upcoming session at Enterprise Data World 2016, April 17 to April 22 in San Diego, where he will talk about future database design issues.

Where did all the interest in NoSQL come from? We know major Web companies are into it, but can other types of enterprises succeed as well? It seems the software needs to mature.

Mike Bowers: We have been using NoSQL for eight years as an XML document database, and we've had great success with it. I feel we are in a revolution to move toward more of it.

The old style vertical databases were built back in the day when you had one CPU. Now they can handle multiple CPUs, but their core architecture isn't really built for the future. Yes they can be made to scale if you want to stay traditional, but it gets pretty expensive. The question really is: How can you get scale for less money?

Mike Bowers, Church of Jesus Christ of Latter-day SaintsMike Bowers

So, NoSQL is completely reinventing the database from the inside out -- to create a high-volume, high-velocity and high-variety architecture.  The variety part is where the NoSQL vendors are failing, however. Hadoop, of course, does variety better than anything else, but it's not a database, it’s a repository, like a data lake.

NoSQL database vendors talk about variety. But, generally, they can't handle variety very well. One may handle JSON very well. But it doesn't do text well. Or it doesn't do XML, graph data or CSVs and other kinds of formats as well.

It seems there is a place for SQL databases, along with a variety of NoSQL databases, as part of the future database mix -- I know you have thoughts about the need for Atomicity, Consistency, Isolation and Durability, or ACID traits, and the limits of approaches based on eventual consistency.  

Bowers: In my opinion ACID compliance is what everybody wants, what they need. Most applications require it -- though there are use cases where they don't.

The question really is: How can you get scale for less money?
Mike Bowersprincipal architect, Church of Jesus Christ of Latter-day Saints

But, when people talk about things like "eventual consistency," to me that means "inconsistent." No one wants inconsistent data. I feel firmly that your database needs to be ACID compliant -- and there are only a few NoSQLs that are.

People don't always realize that means you have to do a lot of programming workarounds to gain durability. So, the result is we now use different databases for different purposes. People call that polyglot persistence, but it does have challenges.

I know you have led sessions on future NoSQL and SQL data design before. How are the questions changing as we move further into this 'polyglot' era?

Bowers:  Yes, I've done this several times. I see a trend. When it started around 2011, the audience was all Internet startups -- what they wanted was to get open source software for free. They wanted that, and high velocity. And they were dreaming big, of course. They asked questions like: "How can my app serve the whole world?'' So they wanted to get on platforms that could scale, and they'd read about Facebook and Netflix scaling with NoSQL, and they were excited to try what the big boys were doing.

But now I am encountering a lot of database engineers and data architects.  These are people working in enterprises. They are the people that say "this is interesting to us," but they are much more cautious. And they are a little bit skeptical about the NoSQL world. I get questions now like: "Are you sure you can get away with not normalizing your data?" It's a very different question than we got at the beginning.

Next Steps

Read about ways to future-proof your database plans

Check out our guide to NoSQL databases

Find out how one SQL database is responding to need for change

Dig Deeper on Database management system (DBMS) architecture, design and strategy