KVIV / NoSQL : the new generation of database servers

NoSQL
de nieuwe generatie van database servers
KVIV IT - 3/6/2010

http://www.ﬂickr.com/photos/wolfgangstaudt/2215246206/

IIC » TECHNOLOGIEPARK 3 » B-9052 ZWIJNAARDE (GENT) » www.outerthought.org

Who am I

» Steven Noels - stevenn@outerthought.org

» Outerthought : scalable content applications

» makers of Daisy and Lily open source CMS

IIC » TECHNOLOGIEPARK 3 » B-9052 ZWIJNAARDE (GENT) » www.outerthought.org 2

An evolution
driven by pain.


History

2. simpliﬁcation

1. standardization
hierarchical databases

IMS
XMLDB RDBMS

OODBMS


History

4. rethinking
the problem

RDBMS NOSQL

caching
denormalisation
sharding
replication ...
3. pain


Scalability


Numbers of scale

http://qos.doubleclick.net/counters/


Types of scaling
» scaling for usage » scaling types of ops
» volume of users » concurrent read
» volume of data » concurrent write

availability partioning
replication consistency

distribution


Scaling

database app server users


Scaling



Scaling: vertical partitioning



Scaling: horizontal partitioning

c
o
m
p
l
e
x
i
t
y
databases app servers users


Scaling through architecture

data layer app layer users


Distributed
systems are
hard !

8 fallacies of distributed computing
» The network is reliable.

» Latency is zero.

» Bandwidth is inﬁnite.

Peter Deutsch and James Gosling
» The network is secure.

» Topology doesn't change.

» There is one administrator.

» Transport cost is zero.

» The network is homogeneous.


Scaling relational systems

» When scaling relational systems you loose
their advantages but retain their overhead
» The pain is all about locking (i.e. writes)

» Caching alleviates the read pain to the cost of
complexity


The Perspective of Cost


Enter NoSQL


Cambrian Explosion


Buzz-oriented
development

?

Cambrian Explosion

N-O-SQL


Common themes

» SCALE SCALE SCALE

» new datamodels

» devops

» N-O-SQL

» The Cloud :
technology is of no interest anymore


New Data

» sparse structures

» weak schemas

» graphs

» semi-structured

» document-oriented


NoSQL

» Not a movement.

» Not ANSI NoSQL-2010.

» Not one-size-ﬁts-all.

» Not (necessarily) anti-RDBMS.

» No silver bullet.


NoSQL = pro Choice


NoSQL = toolbox


The NOSQL footprint
free-structured or sparse data

NOSQL

MongoDB
CouchDB
neo4j

Cassandra

available (complexity)
simple operational

HBase

highly scalable and
constraints
ACID,

SQL

referential integrity,
typed data


NOSQL, if you need ...

» horizontal scaling (out rather than up)

» unusually common data (aka free-structured)

» speed (especially for writes)

» the bleeding edge


SQL/RDBMS, if you need ...

» SQL

» ACID

» normalisation

» a deﬁned liability


Theory


Academic background

» Amazon Dynamo

» Google BigTable

» Eric Brewer CAP theorem


Amazon Dynamo
» coined the term ‘eventual consistency’

» consistent hashing


Consistent hashing

- node C
+ node D

http://www.lexemetech.com/2007/11/consistent-hashing.html


Google BigTable
» multi-dimensional column-oriented database

» on top of GoogleFileSystem

» object versioning


CAP theorem

strong high
consistency availability

partition-
tolerance


CAP
» Strong Consistency: all clients see the
same view, even in the presence of updates
» High Availability: all clients can ﬁnd some
replica of the data, even in the presence of
failures
» Partition-tolerance: the system
properties hold even when the system is
partitioned


Culture Clash
» ACID » BASE
» highest priority: strong » availability and scaling
consistency for highest priorities
transactions » weak consistency
» availability less important
» optimistic
» pessimistic
» best effort
» rigorous analysis
» simple and fast
» complex mechanisms

spectrum


Availability ≠
total async !


✘
The Enterprise Service Bus

bus =

congestion


Bus systems

» objects don’t ﬁt in a pipe

» object ➙ message

» serialization / de-serialization cost

» message size

» queuing = cost


Use a mixture of both

»async + sync

stuff which matters !


Processing large datasets :

Map/Reduce


Hadoop: HDFS + MapReduce
» single ﬁlesystem + single execution-space


MapReduce example: WordCount


Hadoop ecosystem
» Hadoop Common
» Subprojects
» Chukwa: A data collection system for managing large distributed systems.
» HBase: A scalable, distributed database that supports structured data storage for
large tables.
» HDFS: A distributed ﬁle system that provides high throughput access to application
data.
» Hive: A data warehouse infrastructure that provides data summarization and ad hoc
querying.
» MapReduce: A software framework for distributed processing of large data sets on
compute clusters.
» Pig: A high-level data-ﬂow language and execution framework for parallel
computation.
» ZooKeeper: A high-performance coordination service for distributed applications.
» Mahout: machine learning libaries


Processing large datasets with MR

» Beneﬁt from parallellisation

» Less modelling upfront (ad-hoc processing)

» Compartmentalized approach reduces
operational risks
» AsterData et al. have SQL/MR hybrids for
huge-scale BI


Market
overview


Four Trends

» Trend 1 : Data Size

» Trend 2 : Connectedness

» Trend 3 : Semi-structure

» Trend 4 : Architecture


Trend 1: Data size
ExaBytes (10!") of data stored per year
988
1000
Each year more and
more digital data is
created. Over t wo
750 years we create more
digital data than all 623
the data created in
history before that.
500
397

253
250 161

0
2006 2007 2008 2009 2010
Data source: IDC 2007 3


Trend 2: Connectedness
Giant
Global
Graph (GGG)

Over time data has evolved to Ontologies
be more and more interlinked
and connected.
RDF
Hypertext has links,
Blogs have pingback,
Tagging groups all related data Folksonomies
Information connectivity

Tagging

Wikis User-generated
content
Blogs

RSS

Hypertext

Text documents
web 1.0 web 2.0 “web 3.0”

1990 2000 2010 2020 4


Trend 3: Semi-structure
! Individualization of content
• In the salary lists of the 1970s, all elements had exactly one job
• In Or 15? lists of the 2000s, we need 5 job columns! Or 8?
the salary

! All encompassing “entire world views”
• Store more data about each entity
! Trend accelerated by the decentralization of content generation
that is the hallmark of the age of participation (“web 2.0”)

5


Trend 4: Architecture

1980s: Mainframe applications

Application

DB

6



1990s: Database as integration hub

Application Application Application

DB

7



2000s: (moving towards) Decoupled services
with their own backend

Application Application Application

DB DB DB

8


Products
overview


We welcome
the Polyglot
Persistence
overlords.

Categories

» key-value stores

» column stores

» document stores

» graph databases


Key-value stores

» Focus on scaling to huge amounts of data

» Designed to handle big loads

» Often: cfr. Amazon Dynamo
» ring partitioning and replication

» Data model: key/value pairs


Key-value stores

» Redis

» Voldemort

» Tokyo Cabinet


Redis

» REmote DIctionary Server

» http://code.google.com/p/redis/

» vmware


Redis Features
» persisted memcache, ‘awesome’

» RAM-based + persistable

» key ➙ values: string, list, set

» higher-level ops
» i.e. push/pop and sort for lists
» fast (very)

» conﬁgurable durability

» client-managed sharding


Voldemort

» http://project-voldemort.com/

» LinkedIn


Voldemort

» persistent

» distributed

» fault-tolerant

» hash table


Voldemort

API: GET, PUT,
DELETE


Voldemort

routing logic moving up the stack,
smaller latency


Column stores

» BigTable clones

» Sparseness!

» Data model: columns ➙ column families ➙ ACL
» Datums keyed by: row, column, time, index
» Row-range ➙ tablet ➙ distribution


Column stores

» BigTable

» HBase

» Cassandra


BigTable

» http://labs.google.com/papers/bigtable.html

» Google

» layered on top of GFS


HBase

» http://hadoop.apache.org/hbase/

» StumbleUpon / Adobe / Cloudera


HBase
» sorted » persisted
» distributed » storage system
» column-oriented
» multi-dimensional
» highly-available » adds random access
» high-performance reads and writes atop
HDFS


HBase data model
» Distributed multi-dimensional sparse map

» Multi-dimensional keys:
(table, row, family:column, timestamp) → value

» Keys are arbitrary strings

» Access to row data is atomic

Storage architecture

© lars george


Cassandra

» http://cassandra.apache.org/

» Rackspace / Facebook


Cassandra
» Key-value store (with added structure)

» Reliability (identical nodes)

» Eventual consistent

» Distributed
A
C
» Tunable
» Partitioning
P
» Replication


Cassandra applicability
FIT NO FIT

» Scalable reliability » Flexible indexing
(through identical » Only PK-based
nodes) querying
» Linear scaling » Big Binary Data
» Write throughput » 1 Row must ﬁt in
» Large Data Sets RAM entirely


Document databases

» ≈ K/V stores, but DB knows what the Value is

» Lotus Notes heritage

» Data model: collections of K/V collections

» Documents often versioned


Document stores

» CouchDB

» MongoDB

» Riak

» MarkLogic


CouchDB

» http://couchdb.apache.org/

» couch.io


CouchDB

» fault-tolerant

» schema-free

» document-oriented

» accessible via a RESTful HTTP/JSON API


CouchDB documents

{
“_id”: ”BCCD12CBB”,
“_rev”: ”AB764C”,
“type”: ”person”,
“name”: ”Darth Vader”,
“age”: 63,
“headware”: [“Helmet”, “Sombrero”],
“dark_side”: true
}


CouchDB REST API

» HTTP
» PUT /db/docid
» GET /db/docid
» POST /db/docid
» DELETE /db/docid


CouchDB Views
» MapReduce-based

» Filter, Collate, Aggregate

» Javascript

map reduce
function (doc) { function (Key, Values) {
for(var i in doc.tags) var sum = 0;
emit(doc.tags[i], 1); for(var i in Values)
} sum += Values[i];
return sum;
}


CouchDB

» be careful on semantics
» replication ≠ partioning/sharding !
» distributed database = distributable database

» sharded / distributed deployment
requires proxy layer


MongoDB

» http://www.mongodb.org/

» 10gen


MongoDB
» cfr. CouchDB, really

» except for:
» C++
» performance focus
» runtime queries (mapreduce still available)
» native drivers (no REST/HTTP layering)
» no MVCC: update-in-place
» auto sharding (alpha)


Graph databases

» Focus on modeling structure of data -
interconnectivity
» Scale, but only to the complexity of data

» Data model: property graphs


Graph databases

» Neo4j

» AllegroGraph (RDF)


Neo4j

» http://neo4j.org/

» Neo Technology


Neo4j
» data = nodes + relationships + key/value properties


Neo4j
» many language bindings, little remoting

» ‘whiteboard’ friendly

» scaling to complexity (rather than volume?)

» lots of focus on domain modelling

» SPARQL/SAIL impl for triple geeks

» mostly RAM centric (with disk swapping &
persistence)


Market
maturization


Rise of integrators

» Cloudera (H-stack)

» Riptano (Cassandra)

» Cloudant (hosted CouchDB)

» (Outerthought: HBase)


VC capital

» Cloudera

» couch.io

» Neo

» 10gen

» many others


Experiences &
(h)in(d)sights


the ﬁreside conversations

http://www.ﬂickr.com/photos/52641994@N00/516394238/


NOSQL applicability

» Horizontal scaling

» Multi-Master

» Data representation
» search of simplicity
» data that doesn’t ﬁt the E-R model
(graphs, trees, versions)
» Speed


Tool selection
» be careful on the marketeese:
smoke and mirrors beware!
» monitor dev list, IRC, Twitter, blogs

» monitor project ‘sponsors’

» mix-and-match: polyglot persistency

» DON’T NOSQL WITHOUT INTERNAL SYS
ARCHS & DEV(OP)S !


Our Context: Lily

» cloud-scalable content store and search
repository
» successor (in many ways) of Daisy


}
aptness

NOSQL
internet
enterprise

}

SQL
corporate
community

complexity

Lily essentials

» (open source)

» scalable store (Apache HBase)

» and search (Apache SOLR)

» content repository

» α due mid 2010

» www.lilycms.org or @outerthought


Choosing a NoSQL store for Lily: step I
» automatic scaling to large data sets

» fault-tolerance

» ﬂexible datamodel with sparse data

» commodity hardware

» efﬁcient random access

» community-based open source

» Java if possible


Choosing a NoSQL store for Lily: step II

» need for consistency

» atomic single-row updates

» M/R for index regeneration


Choosing a NoSQL store for Lily: step III

HBase
» datamodel with column families and cell
versioning
» ordered tables with range scans

» HDFS for blob storage

» Apache


distributed process coordination
and conﬁguration (ZooKeeper)

}
query update indexer
Lily
Lily Lily Store Server
store
client
node WAL MQ M/R

client

}
store
node 2ary WAL / HBase Region Server
documents
indexes MQ
client

store
node

} Hadoop DFS

REST

index
replica
inverted index

replica replica
} SOLR

lily simpliﬁed architecture

lily architecture

lily distributed architecture


Distribution,
durability,
and availability
is everywhere

When combining store
and search, make sure
your (search) index
doesn’t become the
store.


Key lessons learned
» unlearning normalization is very difﬁcult

» integrity checking in code = not so bad

» doing joins in code can be very liberating

» importance of keyspace design
» secondary indexing
» data de-normalization = size! (x3)

» schema vs. code ﬂexibility?

» distribution is everywhere
and you shouldn’t forget about it

Mis-use cases
» SQL (or ORM) is a prerequisite

» Deeply hierarchical datasets (unless graph)

» Data integrity is listed on DBA job description

» High-security apps (enforced in DB)

» Transactional data (banking)

» Usage is highly unpredictable, combinatorial, or
likely to change suddenly


Reading material

» Amazon Dynamo, Google BigTable, CAP

» http://nosql.mypopescu.com/

» http://nosql-database.org/

» http://twitter.com/nosqlupdate

» http://highscalability.com/


Questions?

http://www.ﬂickr.com/photos/leehaywood/4237636853/


Thanks for your
attention !

» stevenn@outerthought.org

» @stevenn


KVIV / NoSQL : the new generation of database servers

Recommandé

Recommandé

Contenu connexe

Similaire à KVIV / NoSQL : the new generation of database servers

Similaire à KVIV / NoSQL : the new generation of database servers (20)

Plus de NGDATA

Plus de NGDATA (6)

Dernier

Dernier (20)

KVIV / NoSQL : the new generation of database servers