Thanksgiving and turkey go hand-in-hand! And while, stuffing a turkey can be quite fun (with cupcakes – see below), stuffing a JSON rich document in a relational database with rows and columns is not.

 

In the last couple of years, with JSON becoming a popular data format among developers, many SQL based database vendors have jumped on the JSON bandwagon offering JSON support. However, such systems don’t provide the same intuitive programming surface as JSON document stores – they don’t support JSON natively but rather offer bandaid JSON extensions on-top of a relational technology that is already difficult to scale out.

 

So, why does JSON in a relational database not fly ?

Fundamentally, the answer lies in the data model and the architecture.

 

In a relational database when you insert a record, you're inserting a set of well-defined fields that have certain types, and it's very rigorously defined in a database schema. When you have JSON built on-top of a relational technology, there is an impedance mismatch that involves defining beforehand that a column has a JSON data-type or that the JSON document must be sliced and diced into several tables.

 

With a NoSQL database like Couchbase that supports JSON natively, the JSON document is self-contained and schema-free. The JSON document format is flexible and easy to use. Application devs 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 values that are deep nested like 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.  With Couchbase, your JSON documents are auto-sharded and evenly distributed across multiple servers. There are multiple copies of a document within the cluster that increases reliability: If a node goes down, the database keeps chugging along without data loss.

 

Schema-free means that your application can change without any database changes. You don’t have to early bind the schema during the insert operation. However, if you change your mind later about capturing other data attributes, you don’t have to update a schema and re-normalize all the things like in a relational database. You can keep stuffing data into the backend, without any database schema changes.

 

Couchbase supports indexing, and querying across your JSON data.  This means, accessing your data in a key-value fashion, through views, or using N1QL, a SQL-like language to query your rich JSON data in Couchbase. N1QL presents easy and familiar abstractions to quickly develop scalable Couchbase apps. It allows for joins, filter expressions, aggregate expressions and many other features to build a rich application.

 

Conclusion

What all of this means is that if you're working in the enterprise application world, now is the time to start familiarizing yourself with an alternative data storage option like NoSQL instead of stuffing JSON into a relational database.

 

So, if you’re building a new app that is already generating JSON documents or if the data is too complex to model in a relational database, you might want to consider Couchbase to store your data. For example, in an operational store where data is being collected from users, systems, or social networks, a NoSQL database such as Couchbase is a good fit.

Posted by Don Pinto

Don Pinto is a Principal Product Manager at Couchbase and is currently focused on advancing the capabilities of Couchbase Server. He is extremely passionate about data technology, and in the past has authored several articles on Couchbase Server including technical blogs and white papers. Prior to joining Couchbase, Don spent several years at IBM where he maintained the role of software developer in the DB2 information management group and most recently as a program manager on the SQL Server team at Microsoft. Don holds a master's degree in computer science and a bachelor's in computer engineering from the University of Toronto, Canada.

One Comment

Leave a reply