7 min read
Today, MapR has announced the developer preview of MapR Database with native support of JSON, and the new library OJAI (Open JSON Application Interface), pronounced "OH-hy." MapR Database is a recognized NoSQL engine allowing developers to build fast and scalable applications using a popular wide column NoSQL API. With the support of JSON, MapR simplifies the development of scalable applications in the Hadoop environment.
MapR Database with native JSON support is the first and only document model NoSQL database in the Hadoop ecosystem. With the MapR Database multi-model database engine, you can build applications using simple key/values, wide column, and now JSON documents.
Why JSON in MapR Database?
Let's see how the support of JSON is bringing exciting capabilities to developers and business owners! In my opinion, one of the biggest benefits of JSON support in MapR Database, and the associated JSON API and MapR Database Client, is the flexibility.
In many applications, the same type of information, a business object, is represented using different structures. A few concrete examples of common use cases for document databases are:
These examples illustrate the importance of a flexible data structure. Many other examples of applications requiring this flexibility exist, from sensor data in an Internet-of-Things deployment to content management.
Also, during the life of the application, JSON facilitates the natural evolution of the structure of data. Some concrete examples of such an evolution include:
If you are familiar with relational database and design, you know how complex it is to represent such information, and how difficult it is to update the schema in production when you have a large volume of data and users.
All these use cases and requirements are a perfect fit for a document database, and this is why MapR has enhanced MapR Database with native JSON support. Developers now have the freedom to store any complex structure and change it when necessary.
From a business point of view, this flexibility has great impact on time to market. The application now controls the data model, and each time a new feature is deployed, the database automatically adapts to the new structure, without any complex database operations.
The following images show the different ways of representing a product. The example below shows that you can use a very complex, but flexible relational model, and its equivalent in JSON:
In the relational model, when using a flexible model based on the Entity Attribute Value pattern, it is difficult to get the property of a product except without using a complex SQL query; whereas, with a simple JSON document, the structure is directly in the document, so it is very easy to understand from a user or developer perspective.
Now that you have a better idea of how to represent a product using a document, you can see how easily you can append a few attributes, such as ratings or comments, to documents.
Another benefit of working with documents, especially compared to a relational model, is that the documents are much easier to scale. In the relational model, a business object is usually represented using multiple tables, and one or more joins are necessary to send the data to the application. Think about a purchase order with its header, line items, and all other information. Having multiple tables is not an issue, until you have to scale and distribute the data on many servers: joins and transactions are very complex to distribute. This is one of the main drivers of the “NoSQL movement;” we need to scale much more easily!
Another great advantage of using a document model is that your business object is often represented using a single document; your purchase order is a single JSON document that contains all the necessary information. Creating, updating, or retrieving an order is very efficient. Also, it is really easy to distribute the data on many servers, and scale out, simply by adding new nodes.
In the following image, using the same model of an e-commerce product catalog, you can see how to get a product out of the database in SQL or using the JSON API:
As you can see, data retrieval is quite different, which is just due to the fact that a JSON document stored inside MapR Database is a complete business object and the list of attributes will vary depending of its type. On the other hand, in SQL it is necessary to retrieve many records for each attribute. Intuitively, the complex SQL query is very resource-intensive, which will impact your ability to remain fast at scale. The NoSQL query will be fast no matter how complex the records get.
The JSON API offers all the operations necessary to find and delete documents, and also update them. Updating a document includes many tasks, and just a few examples include:
Discover MapR Database
Now that you have learned more about the MapR Database document database Developer Preview, I invite you to go to the http://maprdb.io site and test it yourself!Here you can find information about the product, as well as a getting started guide with sample code.
Stay ahead of the bleeding edge...get the best of Big Data in your inbox.