Not Only SQLNOSQL is simply…

it's not "Never SQL"

NOSQL \no-seek-wool\ n. Describes ongoing trend where developers increasingly opt for non-relational databases to help solve their problems, in an effort to use the right tool for the right job

Why NOSQL now?

Driving trends

Trend 1: Data Size

Trend 2: ConnectednessIn

form

ation

con

necti

vity

Text Documents

Hypertext

Feeds

Blogs

Wikis

UGC

Tagging

Folksonomies

RDFa

Onotologies

GGG

Trend 3: Semi-structured information

• Individualisation of content– 1970’s salary lists, all elements exactly one job– 2000’s salary lists, we need many job columns!

• All encompassing “entire world views”• Store more data about each entity• Trend accelerated by the decentralization of

content generation – Age of participation (“web 2.0”)

Trend 4: Architecture

DB

Application

1980’s: Single Application

Trend 4: Architecture

DB

Application

1990’s: Integration Database Antipattern

ApplicationApplication

Trend 4: Architecture

2000’s: SOA

DB

Application

DB

Application

DB

Application

RESTful, hypermedia, composite apps

Side note: RDBMS performanceSalary list

Most Web apps

Social Network

Location-based services

Four NOSQL Categories

Aggregate-Oriented Databases

Four NOSQL Categories

Key-Value Stores

• “Dynamo: Amazon’s Highly Available Key-Value Store” (2007)

• Data model:– Global key-value mapping– Big scalable HashMap– Highly fault tolerant (typically)

• Examples:– Riak, Redis, Voldemort

Pros and Cons

• Strengths– Simple data model– Great at scaling out horizontally

• Scalable• Available

• Weaknesses:– Simplistic data model– Poor for complex data

Column Family (BigTable)

• Google’s “Bigtable: A Distributed Storage System for Structured Data” (2006)

• Data model:– A big table, with column families– Map-reduce for querying/processing

• Examples:– HBase, HyperTable, Cassandra

Pros and Cons

• Strengths– Data model supports semi-structured data– Naturally indexed (columns)– Good at scaling out horizontally

• Weaknesses:– Unsuited for interconnected data

Document Databases

• Data model– Collections of documents– A document is a key-value collection– Index-centric, lots of map-reduce

• Examples– CouchDB, MongoDB

Pros and Cons

• Strengths– Simple, powerful data model (just like SVN!)– Good scaling (especially if sharding supported)

• Weaknesses:– Unsuited for interconnected data– Query model limited to keys (and indexes)

• Map reduce for larger queries

Graph Databases

• Data model:– Nodes with properties– Named relationships with properties– Hypergraph, sometimes

• Examples:– Neo4j (of course), Sones GraphDB, OrientDB,

InfiniteGraph, AllegroGraph

Pros and Cons

• Strengths– Powerful data model– Fast

• For connected data, can be many orders of magnitude faster than RDBMS

• Weaknesses:– Sharding

• Though they can scale reasonably well• And for some domains you can shard too!

Disclaimer

• I don’t hold any sort of copyright on any of the content used including the photos, logos and text and trademarks used. They all belong to the respective individual and companies

• I am not responsible for, and expressly disclaims all liability for, damages of any kind arising out of use, reference to, or reliance on any information contained within this slide .

You can follow me at @ajitkoti on twitter