In Q&A, there was a question and comment by Lyn Robison from Gartner on advising customers to use the right data model for the right problem/application.
We completely agree. We'd like customers to use the right model for the right problem. With informix not only you can use either standard relational model or flexible schema with JSON for your appdev. Obviously, this can create data silos if your API is tied to specific data model. We believe data model should not restrict data access. Hence the hybrid access.

So, how does this hybrid access work in Informix NoSQL?

Informix provides both SQL and NoSQL semantics. You can define regular relational schema or simply use MongoAPI and Informix creates the database, collections and documents just like MongoDB does. Let’s look at the implementation details. Some of these are already in our detailed deepdive at: slidesha.re/1gEGXW6

Data representation:

SQL: SQL (relational) data is stored in regular tables with rows and columns. Logical schema is distinct from the physical schema.

NoSQL: Flexible schema for the data means, no upfront definition of tables or rows or columns or their types. Each row could have random values. To achieve this, NoSQL databases like MongoDB store data in JSON (actually in its binary form called BSON). JSON is a series of key-value pair. You can nest key-value pars within other key value pairs to form hierarchical structures or arrays. This is generally referred to as document-structure.

For each NoSQL collection, we create a table with a BSON data type. BSON is Binary JSON (http://bsonspec.org/). JSON is Java Script Object Notation (http://www.json.org/). All the MongoDB APIs exchange information with the server using BSON. When the client sends data as BSON, it’s stored AS IS in BSON.

NoSQL pays more attention to application flexibility and agile appdev instead of storage efficiency. So, for now, additional space for key in key-value pair is fine. Eventually, all the databases will be looking at making JSON/BSON storage efficient. Within Informix, you can use compression to get space savings.

The moment you have this kind of access, from MongoDB API, you can exploit the relational database features like transactions, views, joins, grouping, OLAP window functions, stored procedures, etc.

In this case, if a JSON query references a non-existent column, they’ll get the error. The intent is not to simply extend existing relational schema, but to make the existing enterprise data available to new APIs seamlessly.

Currently, you’ll have to use expressions and dotted notations to extract the specific key-value pairs.

SELECT bson_value_int(jc1.data, 'x'),

bson_value_lvarchar(jc1.data, 'y'),

bson_value_int(jc1.data, 'z') ,

bson_value_int(jc2.data, 'c1'),

bson_value_lvarchar(jc2.data, 'c2')

FROM w jc1, v jc2

WHERE bson_value_int(jc1.data, 'x') = bson_value_int(jc2.data, "c1");

You can also create views on top of these and make the access much simpler for application developers.

create view vwjc(jc1x, jc1y, jc1z, jc2c1, jc2c2) as

SELECT bson_value_int(jc1.data, 'x'),

bson_value_lvarchar(jc1.data, 'y'),

bson_value_int(jc1.data, 'z') ,

bson_value_int(jc2.data, 'c1'),

bson_value_lvarchar(jc2.data, 'c2')

FROM w jc1, v jc2

WHERE bson_value_int(jc1.data, 'x') = bson_value_int(jc2.data, 'c1');

Summary:

You can model using relational or NoSQL concepts within the same database and access data from either SQL and MongoDB API without replicating the data or having ETL. Since you just have one copy of the data, you'll be accessing the consistent copy of the data.

Applications generally look for NoSQL database for one of the following reasons:

Flexible schema or schema on read. Data or its type cannot be predetermined. In Informix NoSQL, it's accomplished via JSON and BSON type, added natively into the database. Just like LVARCHAR. Not only you won't know the column names (in this case KEY-VALUE pair, you won't know their type as well). It's not just you're able to store, you need to index and query as well.

Scaling out for increase data capacity, lower latency and performance.

New type of data modelling like GRAPH.

While NoSQL generally means Not Only SQL, if you attend any of the NoSQL conferences, meetups, people more often mean SQL. Recently, Michael Stonebraker made a point in SE Radio (http://www.se-radio.net/2013/12/episode-199-michael-stonebraker/) that most popular NoSQL databases like MongoDB and Cassandra have query languages very similar to SQL -- they're Not Yet SQL. While Hadoop when thru a phase of customer query languages, majority of vendors have SQL like interface to Hadoop.

In case of Informix, we started with SQL. Added flexible schema with the native support of JSON, MongoDB compatible query language (in fact, Informix NoSQL customers have to use the driver for MongoDB) and scale out via range and hash based sharding.

Once we added that, the question was, how would enterprises with TBs of data in relational form and hundreds of applications running on this data exploit the innovations in the API and the technology advantages.

When it comes to data and its infrastructure, evolutions seems to work much better than revolution.

Replicating the data from one form to another just won't work in most cases due to cost and consistency issues. So, we've added support for MongoDB APIs to access SQL data (relational data), features (joins, stored procedures, views) and enabled SQL to access JSON data.

Tomorrow, TUES Dec 17th 11.30 EST, John miller will be talking on these features. Rigister Now.