In the enterprise application world, JavaScript Object Notation (JSON) continues to grow in popularity as a data format among developers. Consequently, many SQL-based database vendors have jumped on the JSON bandwagon, claiming JSON support. For many developers that are dealing with an integrated SQL set-up, this may seem like a convenient add-on. However, it is important to realize the purpose and function of a rich JSON document before stuffing it into a relational database with rows and columns.
Advantages of JSON
To better understand this, let’s first look at a brief history of JSON and its advantages. One of the main benefits of using JSON is the minimal joins and schema changes that are required when an app changes. There are several other application advantages as well:
● JSON was created from a subset notation in JavaScript and has stricter rules than JavaScript. That said, the format greatly reduces the mismatch for developers building agile applications.
● JSON is self-describing, which allows applications to easily manipulate JSON data. Application objects are rich and can be easily represented in JSON format whether sparse, hierarchical, or deeply nested.
● JSON is simple and compact, facilitating easy data transfer across platforms, and among a wide range of users. Part of JSON’s widening appeal with developers is due to the fact that it is easy to learn, read and understand.
● JSON is dynamically typed. It contains no fixed data type and the attributes can vary across different documents.
The great benefits of JSON have led many relational database companies to try and find ways to force JSON documents into a row-and-column structure. In a relational database when you insert a record, you’re inserting a set of well-defined fields that have certain types, and it is rigorously defined in a database schema. However, putting JSON into a tabular format makes manipulation of individual JSON attributes more difficult. When a JSON document is large, indexing and searching through the JSON document also becomes harder in this setting.
This impedance mismatch between the application data model and the underlying database makes it hard to write the end application program and hinders flexibility, agility and ease of development – JSON’s top benefits. These types of databases don’t support JSON natively, but instead offer band-aid JSON extensions on top of a relational technology that is already difficult to scale out.
In summary, slicing and dicing a JSON document into several tables completely negates the easy, simple and compact nature of JSON.
JSON & NoSQL fulfill need for flexibility
In NoSQL databases that support JSON natively, the JSON document is self- and schema-free. This means that an application can change without the time-consuming process of editing the schema, including adding more tables or columns. Developers don’t have to early bind the schema during the insert operation. However, if a developer later reconsiders about capturing other data attributes, the developer would not have to update a schema and re-normalize all the things, as one would in a relational database. This is especially important for the enterprises of today that demand business agility. A decade ago, many of the business applications that were written required little change for years after their creation. Now, business applications must evolve quickly and change regularly with the enterprises that deploy them. NoSQL and JSON technologies adeptly fulfill this need for flexibility in businesses that seek to remain competitive through expanding the amount of data in their use, without any database schema changes.
NoSQL also supports indexing and querying across JSON data. This means accessing data in a key-value fashion, through views, and using a rich query language like N1QL. So for developers working in the enterprise application world, now is the time to look into an alternative data storage option like NoSQL, instead of stuffing JSON into a relational database. With more and more JSON data in NoSQL databases today and the need for rich, interactive applications, businesses need a way to search JSON data. By complementing NoSQL databases with search technologies, developers will have the ability to search and facet on JSON content in an application.
As JSON documents are flexible and easy to use, application developers can quickly start working with the data, while the database easily adapts to changes in the data structure. JSON documents can store rich data that can be sparse, hierarchical or collect values that are deep-nested, such as arrays. JSON values are also dynamically typed, with no fixed data type for attributes across different documents.
Self-contained JSON documents makes sharding data across a cluster easy. The JSON document is not confined within a column in a relational table, but is stored naturally as-is and can be indexed by the database. In some NoSQL databases, JSON documents are automatically sharded and evenly distributed across multiple servers. The multiple copies of a document within the cluster increases reliability: If a node goes down, the database keeps chugging along without any significant loss.
When building an application that is already generating JSON documents, or managing JSON documents within an existing application, consider a NoSQL database to store your data. For example, in an operational store where data is being collected from users, systems, or social networks, a NoSQL database is the perfect JSON companion. Between its schema-free properties, its support for JSON indexing and querying, flexibility, and auto-sharding, NoSQL just makes more sense than a SQL solution.
As businesses are increasingly pressured to deliver results and drive revenue up in an ever-changing environment, technology leaders will look to solutions like NoSQL and JSON that can keep pace. This is especially relevant for the sectors that overlap with big data, the Internet of Things, and mobile enterprise applications. Business leaders must take care to understand how the technologies they are considering compliment or hinder each other, instead of trusting the “label information” alone.
Ravi Mayuram is Senior Vice President of Engineering at Couchbase.
Feature image via Unsplash, Creative Commons.
