OO Storage Aligns With the Cost of Data

Object storage systems remove the complexity and management costs associated with keeping an enterprise storage system in production-ready status. Object storage is based on a single, flat address space that enables the automatic routing of data to the proper storage systems, the right storage tier and protection levels within those systems according to its value and stage in the data life cycle.

Historically, the databases were used to store highly structured business data, which fit well into spreadsheet form and was good at answering relatively simple questions. In combination, this solved some moderately interesting use cases. Today, data is found in numerous forms, from machine-generated processes to spreadsheets, PDFs, Web logs, photos, video and so on. All that data conforms to domain-specific information models that often involve complex structures. Object systems dismiss all of this.

The cloud is founded on the utility of computing and the “self-healing of infrastructure.”??í These tenets lend themselves well to secondary problems confronting data management on the Big Data frontier. Big Data problems are solved through distributed software architecture and parallel processing. Cloud computing inherently delivers a distributed infrastructure suitable for distributed software architectures. The ability to spread data across multiple machines and to move processes to various machines to provide efficiency is how data is best processed.??í

Predictive modeling, used in analytics, requires real-time processing. It is dynamic, so it requires a database that can quickly adjust to variable process states as they change under the weight of a workload. The ODB is especially suited to handling the real-time requirements of predictive modeling environments.

The old generation of business intelligence was reactive and centered on simple questions like, “Who are my top 10 sales reps for the quarter?”??íAnswers to these were arrived at by querying the database for a specific, simple value using the standard key:value query format. The new generation is proactive and looking for answers to queries such as: “Notice if a user has clicked on a weighted pattern of article tags over 3 disparate blogs in the last 36 hours.” This kind of complexity is inherently handled algorithmically by rich domain modeling, which is seamlessly handled by ODB technology.

MySQL was never designed for the complexity needed today. Even though MySQL isn’t that old, data demands since its launch have completely changed the game. Like most relational database technologies, MySQL was never a highly scalable or performance-oriented RDB and was criticized in many public forums in that regard. The biggest innovation for MySQL was its price, which gave it a good value point for relatively simple applications, but it was never designed for Big Data processing.??í??í

Generation 1 NoSQL was an innovation created to solve specific point problems in a highly competitive market. It is used by Google, Yahoo-Hadoop,??íeBay, Amazon-Dynamo, MySpace, Facebook-Cassandra,??í Plaxo and LinkedIn-Voldemort.??íIt was an urgent attempt to get to a new level of scalability before the businesses collapsed under the weight of their user growth. It is a reinvention of the wheel, a lesson that the ODB industry learned in the last decade as it sought to deal with soft-schema over a relational storage engine.

At least 25 percent of hacks involve SQL injection. With the recent advent of ORM (object relational mapping), in which developers do not directly write the SQL code, this is becoming less of a problem. But there are still many systems written manually that are still vulnerable. Until more green field applications are created with the new ORM techniques, the security problems of SQL injection will persist. The ODB is not necessarily the total cure for this, but it is certainly less vulnerable because it does a 20 percent query instead of a 100 percent SQL-based query.

Looking back, the No. 1 cause of people not using an ODB has been “nobody ever lost their job for choosing Oracle.” If the project failed, it had to be for some other reason, not the choice in technology.??í That attitude has changed, possibly because there have been so many RDB failures. Other than this business and attitude issue, the main technical reasons were vendor lock-in and reporting ability. Both of these objections have now been removed; the programming interface to the ODB now is the same API used to access an RDB. The bottom line is that there is now a whole world full of ODB experts.??í

Everybody is dealing with the level of data complexity that used to be the realm of niche applications 20 years ago. ODBs have been solving this for a while. ODBs were ahead of their time then and are still ahead of their time; the competitive forces of the likes of Facebook, Twitter and others have brought to light the real value that is held in the ODB??íapproach to database IT.??í