Migrating Like Mercury, or NoSQL Is Plenty
June 16, 2015
More than a decade ago, database advocate Wirt Atmar said that "killing the HP 3000 was a little bit like hitting a drop of mercury with a hammer; it caused the drops to squirt out in every direction, with people migrating every which way to a whole host of new systems and new databases." The newest databases of that decade were modernized iterations of SQL, like MySQL and Postgres. In our current era, however, the schemas of Structured Query Language data management have begun to turn into a liability. What were once touted as an advantage over IMAGE (at least until IMAGE acquired SQL queries to become IMAGE/SQL) are now being viewed as not fluid enough.
The reason lies in how much we track today. Billion-record databases are not uncommon anymore. Establishing a query structure that remains in place for every search is slower than devising the best one on every search. That's the promise that NoSQL and its cousin file system Hadoop offer. When data leaps into the realm of the Internet of Things and tracks instances as small as light bulb blowouts, then database technology like SQL devised in the 1980s, no matter how much it's updated, won't be able to keep up.
SQL will be replaced with NoSQL, once the messiness of data becomes the norm. Oracle and PostgreSQL and MS SQL rule today. Even Microsoft Access has a ready enterprise base, as simple its structure is. But data is growing fast enough to become BigData. And the HP 3000 community which has migrated, or soon will, is going to look for newer data structures and tools to send its SQL data into NoSQL's schemas.
MB Foster is working to be this kind of tool provider. Tomorrow on June 17 the company will demonstrate how its UDACentral product moves the data today. The aim for versions in the years to come is support for BigData's tools of NoSQL and Hadoop.
That's a situation that will feel a lot like the push toward Open Systems in the early '90s. Less technical leaders will start asking for a tool that promises the most. It will be up to the technical managers to deliver, starting with the data they've got on hand today in SQL databases.
Looking ahead, even while increasing today's feature set, is an attribute of a vendor dedicated to the future of data. The HP 3000 was built around the intrinsic combination of file system and database management. The managers of these systems understand the exponential value that such a combination provides. For its time, the HP 3000 never had a rival that blended files and data so efficiently.
More than a decade ago Atmar's company AICS Research looked ahead to supporting "PostgreSQL on Linux, SQLServer on NT, Oracle on IBM, based on whatever migration patterns we see in the user community. Ultimately, it is our intention to support every common combination of host operating systems and databases."
A data extraction and loading tool makes that kind of support more than just a future requirement. Any tool like that — with a track record of embracing one database structure after another — can support the growth of data into BigData. The concept of BigData seems like a buzzword. So did cloud computing, too. And all it takes is one corporate acquisition for a BigData IT shop to develop a need to ingest data from something as relatively modest as an IMAGE/SQL database.
NoSQL and Hadoop offer another benefit, one that will resonate with HP 3000 managers. They're open source solutions, even if the technology is packaged by vendors like Cloudera or MongoDB. After a forced migration from the HP 3000 and IMAGE/SQL, migrators won't have to remain lashed to a proprietary data schema like Oracle's or Microsoft's. The BigData solutions will, as Atmar put it years ago, "be providing users with significantly more protection against vendor abandonment than they've had in the past."