NoSql Database

 Some history
 What is NoSQL –Why?
 CAP Theorem
 What is lost
 Types of NoSQL
 Typical NoSQL API
 Data Model
 NoSQL Database Examples-Demo
 Future trends
 Conclusion
 Question?

 Casing
 Master/slave
 Master/Master
 Cluster
 Table programming
 Sharing
 Distributed data

 WHAT?
 Stands for Not Only SQL
 Class of non-relational data storage systems
 Usually do not require a fixed table schema nor do they use the concept of joins
 All NoSQL offerings relax one or more of the ACID properties
 WHY?
 For data storage, an RDBMS cannot be the be-all/end-all
 Just as there are different programming languages, need to have other data storage tools in the toolbox
 A NoSQL solution is more acceptable to a client now than even a year ago
 Explosion of social media sites (Facebook, Twitter) with large data needs
 Rise of cloud-based solutions such as Amazon S3 (simple storage solution)
 Just as moving to dynamically-typed languages (Ruby/Groovy), a shift to dynamically-typed data with
frequent schema changes
 Open-source community

 Explosion of social media sites (Facebook, Twitter) with large
data needs
 Rise of cloud-based solutions such as Amazon S3 (simple
storage solution)
 Just as moving to dynamically-typed languages
(Ruby/Groovy), a shift to dynamically-typed data with
frequent schema changes
 Open-source community

 Three major papers were the seeds of the NoSQL movement
 Big Table (Google)
 Dynamo (Amazon)
▪ Gossip protocol (discovery and error detection)
▪ Distributed key-value data store
▪ Eventual consistency
 CAP Theorem

 Three properties of a system:
 Consistency
 Availability
 Partitions
 You can have at most two of these three properties for any
shared-data system
 To scale out, you have to partition. That leaves either
consistency or availability to choose from
 In almost all cases, you would choose availability over
consistency

 Traditionally, thought of as the server/process available five
9’s (99.999 %).
 However, for large node system, at almost any point in time
there’s a good chance that a node is either down or there is a
network disruption among the nodes.
 Want a system that is resilient in the face of network disruption

 A consistency model determines rules for visibility and
apparent order of updates.
 For example:
 Row X is replicated on nodes M and N
 Client A writes row X to node N
 Some period of time t elapses.
 Client B reads row X from node M
 Does client B see the write from client A?
 Consistency is a continuum with tradeoffs
 For NoSQL, the answer would be: maybe
 CAP Theorem states: Strict Consistency can't be achieved
at the same time as availability and partition-tolerance.

 When no updates occur for a long period of time, eventually
all updates will propagate through the system and all the
nodes will be consistent
 For a given accepted update and a given node, eventually
either the update reaches the node or the node is removed
from service
 Known as BASE (Basically Available, Soft state, Eventual
consistency), as opposed to ACID

 NoSQL solutions fall into two major areas:
 Key/Value or ‘the big hash table’.
▪ Amazon S3 (Dynamo)
▪ Voldemort
▪ Scalar
 Schema-less which comes in multiple flavors, column-
based, document-based or graph-based.
▪ Cassandra (column-based)
▪ CouchDB (document-based)
▪ Neo4J (graph-based)
▪ HBase (column-based)

Pros:
 very fast
 very scalable
 simple model
 able to distribute horizontally
Cons:
- many data structures (objects) can't be easily modeled as key
value pairs

Pros:
- Schema-less data model is richer than key/value pairs
- eventual consistency
- many are distributed
- still provide excellent performance and scalability
Cons:
- typically no ACID transactions or joins

 Cheap, easy to implement (open source)
 Data are replicated to multiple nodes (therefore identical and
fault-tolerant) and can be partitioned
 Down nodes easily replaced
 No single point of failure
 Easy to distribute
 Don't require a schema
 Can scale up and down
 Relax the data consistency requirement (CAP)

 Basic API access:
 get(key) -- Extract the value given a key
 put(key, value) -- Create or update the value given its key
 delete(key) -- Remove the key and its associated value
 execute(key, operation, parameters) -- Invoke an operation
to the value (given its key) which is a special data structure
(e.g. List, Set, Map .... etc).

 Within Cassandra, you will refer to data this way:
 Column: smallest data element, a tuple with a name and a
value
:Rockets, '1' might return:
{'name' => ‘Rocket-Powered Roller Skates',
‘toon' => ‘Ready Set Zoom',
‘inventoryQty' => ‘5‘,
‘productUrl’ => ‘rockets1.gif’}

 ColumnFamily: There’s a single structure used to group both the
Columns and SuperColumns. Called a ColumnFamily (think table), it
has two types, Standard & Super.
▪ Column families must be defined at startup
 Key: the permanent name of the record
 Keyspace: the outer-most level of organization. This is usually
the name of the application. For example, ‘Acme' (think database
name).

 Talked previous about eventual consistency
 Cassandra has programmable read/writable consistency
 One: Return from the first node that responds
 Quorom: Query from all nodes and respond with the one
that has latest timestamp once a majority of nodes
responded
 All: Query from all nodes and respond with the one that has
latest timestamp once all nodes responded. An unresponsive
node will fail the node

 Zero: Ensure nothing. Asynchronous write done in
background
 Any: Ensure that the write is written to at least 1 node
 One: Ensure that the write is written to at least 1 node’s
commit log and memory table before receipt to client
 Quorom: Ensure that the write goes to node/2 + 1
 All: Ensure that writes go to all nodes. An unresponsive node
would fail the write

 Partition using consistent hashing
 Keys hash to a point on a fixed
circular space
 Ring is partitioned into a set of
ordered slots and servers and
keys hashed over these slots
 Nodes take positions on the circle.
 A, B, and D exists.
 B responsible for AB range.
 D responsible for BD range.
 A responsible for DA range.
 C joins.
 B, D split ranges.
 C gets BC from D.

 Tomcat context.xml
<Resource name="cassandra/CassandraClientFactory"
auth="Container"
type="me.prettyprint.cassandra.service.CassandraHostConfigurator"
factory="org.apache.naming.factory.BeanFactory"
hosts="localhost:9160"
maxActive="150"
maxIdle="75" />
 J2EE web.xml
<resource-env-ref>
<description>Object factory for Cassandra clients.</description>
<resource-env-ref-name>cassandra/CassandraClientFactory</resource-env-ref- name>
<resource-env-ref-type>org.apache.naming.factory.BeanFactory</resource-env-ref-type>
</resource-env-ref>

 Spring applicationContext.xml
<bean id="cassandraHostConfigurator“
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName">
<value>cassandra/CassandraClientFactory</value></property>
<property name="resourceRef"><value>true</value></property>
</bean>
<bean id="inventoryDao“
class="com.acme.erp.inventory.dao.InventoryDaoImpl">
<property name="cassandraHostConfigurator“
ref="cassandraHostConfigurator" />
<property name="keyspace" value="Acme" />
</bean>

try {
cassandraClient = cassandraClientPool.borrowClient();
// keyspace is Acme
Keyspace keyspace = cassandraClient.getKeyspace(getKeyspace());
// inventoryType is Rockets
List<Column> result = keyspace.getSlice(Long.toString(inventoryId), new
ColumnParent(inventoryType), getSlicePredicate());
inventoryItem.setInventoryItemId(inventoryId);
inventoryItem.setInventoryType(inventoryType);
loadInventory(inventoryItem, result);
} catch (Exception exception) {
logger.error("An Exception occurred retrieving an inventory item", exception);
} finally {
try {
cassandraClientPool.releaseClient(cassandraClient);
logger.warn("An Exception occurred returning a Cassandra client to the pool", exception);
}
}

try {
cassandraClient = cassandraClientPool.borrowClient();
Map<String, List<ColumnOrSuperColumn>> data = new
HashMap<String, List<ColumnOrSuperColumn>>();
List<ColumnOrSuperColumn> columns = new ArrayList<ColumnOrSuperColumn>();
// Create the inventoryId column.
ColumnOrSuperColumn column = new ColumnOrSuperColumn();
columns.add(column.setColumn(newColumn("inventoryItemId".getBytes("utf-
8"), Long.toString(inventoryItem.getInventoryItemId()).getBytes("utf-8"), timestamp)));
column = new ColumnOrSuperColumn();
columns.add(column.setColumn(newColumn("inventoryType".getBytes("utf-
8"), inventoryItem.getInventoryType().getBytes("utf-8"), timestamp)));
….
data.put(inventoryItem.getInventoryType(), columns);
cassandraClient.getCassandra().batch_insert(getKeyspace(), Long.toString(inventoryItem.getInvent
oryItemId()), data, ConsistencyLevel.ANY);
…
}

 www.google.com
 Cassandra
 http://cassandra.apache.org
 Hector
 http://wiki.github.com/rantav/hector
 http://prettyprint.me
 NoSQL News websites
 http://nosql.mypopescu.com
 http://www.nosqldatabases.com
 High Scalability
 http://highscalability.com
 Video
 http://www.infoq.com/presentations/Project-Voldemort-at-Gilt-
Groupe
 www.youtube.com

NoSql Database

Recommended

More Related Content

What's hot (20)

Similar to NoSql Database (20)

Recently uploaded (20)

NoSql Database