Embed Size (px)
DESCRIPTION
This presentation lets you know what the nosql movement is all about
Citation preview
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
