NOSQL Database: Apache Cassandra

NoSQL Database: ApacheNoSQL Database: Apache
CassandraCassandra
www.folio3.com@folio_3

Folio3 – OverviewFolio3 – Overview
www.folio3.com @folio_3

Who We Are
 We are a Development Partner for our customers
 Design software solutions, not just implement them
 Focus on the solution – Platform and technology agnostic
 Expertise in building applications that are:
Mobile Social Cloud-based Gamified

What We Do
 Areas of Focus
 Enterprise
 Custom enterprise applications
 Product development targeting the enterprise
 Mobile
 Custom mobile apps for iOS, Android, Windows Phone, BB OS
 Mobile platform (server-to-server) development
 Social Media
 CMS based websites for consumers and enterprise (corporate, consumer,
community & social networking)
 Social media platform development (enterprise & consumer)

Folio3 At a Glance
 Founded in 2005
 Over 200 full time employees
 Offices in the US, Canada, Bulgaria & Pakistan
 Palo Alto, CA.
 Sofia, Bulgaria
 Karachi, Pakistan
Toronto, Canada

Areas of Focus: Enterprise
 Automating workflows
 Cloud based solutions
 Application integration
 Platform development
 Healthcare
 Mobile Enterprise
 Digital Media
 Supply Chain

Some of Our Enterprise Clients

Areas of Focus: Mobile
 Serious enterprise applications for Banks,
Businesses
 Fun consumer apps for app discovery,
interaction, exercise gamification and play
 Educational apps
 Augmented Reality apps
 Mobile Platforms

Areas of Focus: Web & Social Media
 Community Sites based on
Content Management Systems
 Enterprise Social Networking
 Social Games for Facebook &
Mobile
 Companion Apps for games

NoSQL Database: ApacheNoSQL Database: Apache
CassandraCassandra
www.folio3.com @folio_3

Agenda
 What is NOSQL?
 Motivations for NOSQL?
 Brewer’s CAP Theorem
 Taxonomy of NOSQL databases
 Apache Cassandra
 Features
 Data Model
 Consistency
 Operations
 Cluster Membership
 What Does NOSQL means for RDBMS?

What is NOSQL?
 Refers to databases that differs from traditional relational database
management system (RDBMS)
 Distributed, flexible, horizontally scalable data stores
 Confusion with the term NOSQL
 NOSQL != No SQL (or Anti-SQL)
 NOSQL = Not Only SQL
 NOSQL is an inaccurate term since it is commonly used to refer to
"non-relational" databases but the term has stuck

Motivations for NOSQL
 Classical RDBMS unsuitable for today's web applications
because:
 Performance (Latency): Variable
 Flexibility: Low
 Scalability: Variable
 Functionality

Brewer's CAP Theorm
 Consistency (C)
 Availability (A)
 Partition Tolerance (P)
 Pick any two
 Most NOSQL databases sacrifice Consistency
in favor of high Availability and Performance

Taxonomy of NOSQL
 Key/Value Stores - Distributed Hash Tables (DHT)
 Memcached, Amazon’s Dynamo, Redis, PStore
 Document Stores
 Semi structured data (stores entire documents)
 CouchDB, MongoDB, RDDB, Riak
 Graph Databases *
 Based on graph theory
 ActiveRDF, AllegroGraph, Neo4J
 Object Database *
 Versant, Objectivity
 Column-oriented Stores
 * these are considered soft NOSQL databases and are usually in NOSQL category because of being
"non-relational".

Column-Oriented Data Stores
 Semi-structured column-based data stores
 Stores each column separately so that aggregate operations for one column
of the entire table are significantly quicker than the traditional row storage
model
 Popular examples
 Hadoop/HBASE
 Apache Cassandra
 Google's BigTable
 HyperTable
 Amazon's SimpleDB

Apache Cassandra
 Fully distributed column oriented data store
 Also provides Map Reduce implementation using Hadoop (increased
performance)
 Based on Google's BigTable (Data Model) and Amazon's Dynamo
(Consistency & Partition Tolerance)
 Cassandra values Availability and Partitioning tolerance (AP) while
providing tunable consistency levels.

History
 Developed at Facebook
 Released as open source project on Google Code in July 2008
 Became an Apache Incubator Project in March 2009
 Became a top level Apache project in February 2010 Performance
 Rumors of Facebook having started working on its own separate
version of Cassandra

Features
 Fully Distributed
 Highly Scalable
 Fault Tolerant (No single point of failure)
 Tunable Consistency (Eventually Consistent)
 Semi-structured key-value store
 High Availability
 No Referential Integrity
 No Joins

Data Model
 KeySpace (Uppermost namespace)
 Column Family / Super Column Family (analogous to table)
 Super Column
 Column (Name, Value, Timestamp)
 Rows are referenced through keys
 Each column is stored in a separate physical file

Super Column Family: Static/Static

Super Column Family: Static/Dynamic

Super Column Family: Dynamic/Static

Super Column Family: Dynamic/Dynamic

Apache Cassandra: Consistency
 Consistency refers to whether a system is left in a consistent state
after an operation. In distributed data systems like Cassandra, this
usually means that once a writer has written, all readers will see that
write.
 If W + R > N, you will have strong consistent behavior; that is, readers
will always see the most recent write
 W is the number of nodes to block for on write
 R is the number to block for on reads
 N is the replication factor (number of replicas)

Apache Cassandra: Consistency
 Relational databases provide strong consistency (ACID)
 Cassandra provide eventual consistency (BASE) meaning the database
will eventually reach a consistent state
 QUORUM reads and writes gives consistency while still allowing
availability
 Q = (N / 2) + 1 (simple majority)
 If latency is more important than consistency, you can lower values
for either or both W and R.

Apache Cassandra: Consistency Levels
 Write
 ZERO
 ANY
 ONE
 QUORUM
 ALL
 Read
 ZERO
 ANY
 ONE
 QUORUM
 ALL

Write Operation
 Client sends a write request to a random node; the random node
forwards the request to the proper node (1st replica responsible for
the partition - coordinator)
 Coordinator sends requests to N replicas
 If W replicas confirm the write operation then OK
 Always writable, hinted handoff (If a replica node for the key is down,
Cassandra will write a hint to the live replica node indicating that the
write needs to be replayed to the unavailable node.)

Read Operation
 Coordinator sends requests to N replicas, if R replicas respond then
OK
 If different versions are returned then reconcile and write back the
reconciled version (Read Repair)

Cluster Membership
 Gossip Protocol
 Every T seconds each node increments its heartbeat counter
and gossips to another node about the state of the cluster;
the receiving node merges the cluster info with its own copy
 Cluster state (node in/out, failure) propagated quickly:
O(LogN) where N is the number of nodes in the cluster

Storage Ring
 Cassandra cluster nodes are organized in a virtual ring.
 Each node has a single unique token that defines its place in the ring
and which keys it is responsible for
 Key ranges are adjusted when the nodes join or leave

Apache Cassandra: MySQL Comparison
 MySQL (> 50 GB data)
 Read Average: ~ 350 ms
 Write Average: ~ 300 ms
 Cassandra (> 50 GB data)
 Read Average: 15 ms
 Write Average: 0.12 ms

Apache Cassandra: Client API
 Low level API
 Thrift
 High Level API
 Java
 Hector, Pelops, Kundera
 .NET
 FluentCassandra, Aquiles
 Python
 Telephus, Pycassa
 PHP
 phpcassa, SimpleCassie

Apache Cassandra: Where to Use?
 Use Cassandra, if you want/need
 High write throughput
 Near-Linear scalability
 Automated replication/fault tolerance
 Can tolerate low consistency
 Can tolerate missing RDBMS features

Apache Cassandra: Users
 Facebook (of course)
 To power inbox search (previously)
 Twitter
 To handle user relationships, analytics (but not for tweets)
 Digg & Reddit
 Both use Cassandra to handle user comments and votes
 Rackspace
 IBM
 To build scalable email system
 Cisco's WebEx
 To store user feed and activity in near real time

What does NOSQL mean for the future of RDBMS?
 No worries! RDBMSs are here to stay for the foreseeable future
 NOSQL data stores can be used in combination with RDBMS in some
situations
 NOSQL still has a long way to go, in order to reach the widespread
(mainstream) use and support of the RDBMS

Weakness of NOSQL
 No or limited support for complex queries
 No transactions available (operations are atomic)
 No standard interface for NOSQL databases (like SQL in relational
databases)
 No or limited administrative features available for NOSQL databases
 Not suitable (yet) for mainstream use

Why Still Use RDBMS?
 All the weaknesses of NOSQL
 Relational databases are widely used and understood
 RDBMS DBAs and developers are easily available in the market
 For big business, relational databases are a safe choice because they
have heavily invested in relational technology
 Many database design and development tools available

References
 http://www.allthingsdistributed.com/2008/12/eventually_consistent.
html
 http://wiki.apache.org/cassandra/FrontPage
 http://en.wikipedia.org/wiki/Apache_Cassandra
 http://www.slideshare.net/gdusbabek/cassandra-presentation-for-
san-antonio-jug
 http://www.slideshare.net/Eweaver/cassandra-presentation-at-nosql
 http://nosql-database.org/
 http://nosqlpedia.com/

Contact
 For more details about our
services, please get in touch with
us.
contact@folio3.com
US Office: (408) 365-4638
www.folio3.com

NOSQL Database: Apache Cassandra

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to NOSQL Database: Apache Cassandra (20)

More from Folio3 Software (20)

Recently uploaded (20)

NOSQL Database: Apache Cassandra