No Right Way

A discussion on Databases and a guide to CouchDB and Cloudant

ANY VIEWS OR OPINIONS EXPRESSED IN THIS PRESENTATION ARE THOSE OF THE AUTHOR, AND DO NOT NECESSARILY REPRESENT OFFICIAL POSITIONS, STRATEGIES OR OPINIONS OF INTERNATIONAL BUSINESS MACHINES (IBM) CORPORATION.

THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY.

WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED.

IN ADDITION, THIS INFORMATION IS BASED ON IBM’S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM WITHOUT NOTICE.

IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY OTHER DOCUMENTATION.

NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, OR SHALL HAVE THE EFFECT OF:CREATING ANY WARRANTY OR REPRESENTATION FROM IBM (OR ITS AFFILIATES OR ITS OR THEIR SUPPLIERS AND/OR LICENSORS); ORALTERING THE TERMS AND CONDITIONS OF THE APPLICABLE LICENSE AGREEMENT GOVERNING THE USE OF IBM SOFTWARE.

Who the are you…?

Mike Elsmore

Developer Advocate for Cloudant

mike.elsmore@uk.ibm.com

@ukmadlz

Kinds of database

Relational Databases

NoSQL

What is NoSQL

What's the appeal

Data Model Flexibility

Elastic (automatic) scale in/out

Lower-cost operational data management platform for thousands & millions of users

Data Model Flexibility

Data models that are native to the application space (e.g. JSON)
No “schema-first” requirement: rapid and agile development process

Elastic (automatic) scale in/out

Easy elasticity and scalability to multiple racks (10s to 100s of severs)
Supports dynamic workloads
Optimized for web scale and extreme performance
Ease of replication

Lower-cost operational data management platform for thousands  millions of users

Increase in volumes of data, retention requirements (3-15 years)
Commodity hardware and pay-for services
Fault-tolerance and high availability

CAP Theorem

Taken from

And this applies to Relation how?

When to use Relational Database Management Systems (RDBMS)

Data normalization is critical for elimination of redundancy and ensuring master data consistency
Many “justifications” for using relational databases are cultural, not technical
e.g. Solution already built with relational DB  resistance to change
Prioritization of data availability and consistency lends RDBMS well to handling transactional, reporting, log, and warehouse data
Analytics and BI tooling are valid reasons for maintaining a relational database, but this too is rapidly changing

According to the CAP Theorem, it is impossible for relational databases to be partition tolerant

So long as RDBMS prioritizes availability and consistency, they are unable to scale out (horizontally)!
Vertical scaling is the alternative, but this practice becomes prohibitively expensive and is not sustainable

And NoSQL fits in here…?

Key Value Stores

Columnar Stores

Graph Stores

Document Stores

                
        {
             "firstName“ : "John",
             "lastName" : "Smith",
             "age“ : 25,
             "address" :
             {
                 "streetAddress“ : "21 2nd Street",
                 "city" : "New York",
                 "state“ : "NY",
                 "postalCode" : "10021"
             },
             "phoneNumber":
             [
                 {
                   "type" : "home",
                   "number“ : "212 555-1234"
                 },
                 {
                   "type" : "fax",
                   "number“ : "646 555-4567"
                 }
             ]
         }

How does this apply to CAP theorem

As I said, all these datastore use or fallback to an AP approach. Which means…

Instead of prioritizing consistency and availability, shift focus towards ensuring availability and partition tolerance

Unlikely to find a scenario where loss in availability would be tolerable
Selecting for partition tolerance opens up possibility for horizontal scaling!
Distribution over cluster also improves availability
In aggregate the cluster is more reliable than the individual nodes that comprise it

This comes at the cost of a weakened consistency model

Can no longer guarantee that all nodes (and clients connected to these nodes) share identical versions of the same data at a given moment
The result is an “eventual consistency” model
The premise that all nodes in a distributed system will eventually share the same versioning of all data, given sufficient time

Why use MongoDB

It's quick

It's easy to use

            
              db.unicorns.insert({name: 'Aurora', gender: 'f', weight: 450});
              db.unicorns.find();
              db.system.indexes.find();

Why use Cloudant / CouchDB

It works as a HTTP API

It's eventually consistant

It's managed - if you use Cloudant

Why carry on with Relational

http://sqoop.apache.org/

The End

Slides