This document introduces the concepts of NoSQL databases. It discusses that NoSQL aims to provide scalability, flexibility, naturalness and distribution over ACID properties. It covers the CAP theorem, BASE properties and the four main types of NoSQL databases - columnar families, bigtable systems, document databases and graph databases. It also provides examples for each type.

1. CS315: Principles of Database Systems
NoSQL
Arnab Bhattacharya
arnabb@cse.iitk.ac.in
Computer Science and Engineering,
Indian Institute of Technology, Kanpur
http://web.cse.iitk.ac.in/˜cs315/
2nd
semester, 2013-14
Tue, Fri 1530-1700 at CS101
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 1 / 12

2. NoSQL
NoSQL is
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 2 / 12

3. NoSQL
NoSQL is not “no-SQL”
It is not only SQL
It does not aim to provide the ACID properties
Originated as no-SQL though
Later changed since RDBMS is too powerful to always ignore
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 2 / 12

4. NoSQL
NoSQL is not “no-SQL”
It is not only SQL
It does not aim to provide the ACID properties
Originated as no-SQL though
Later changed since RDBMS is too powerful to always ignore
Aims to provide
Scalability
Flexibility
Naturalness
Distribution
Performance
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 2 / 12

5. CAP theorem
All of C, A, P cannot be satisfied simultaneously
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 3 / 12

6. CAP theorem
All of C, A, P cannot be satisfied simultaneously
CA: single-site; partitioning is not allowed
CP: what is available is consistent
AP: everything is available but may not be consistent
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 3 / 12

7. CAP theorem
All of C, A, P cannot be satisfied simultaneously
CA: single-site; partitioning is not allowed
CP: what is available is consistent
AP: everything is available but may not be consistent
Not a theorem – just a hypothesis
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 3 / 12

8. BASE properties
Basically Available: System guarantees availability
Soft state: State of system is soft, i.e., it may change without input to
maintain consistency
Eventual consistency: Data will be eventually consistent without any
interim perturbation
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 4 / 12

9. BASE properties
Basically Available: System guarantees availability
Soft state: State of system is soft, i.e., it may change without input to
maintain consistency
Eventual consistency: Data will be eventually consistent without any
interim perturbation
Sacrifices consistency
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 4 / 12

10. BASE properties
Basically Available: System guarantees availability
Soft state: State of system is soft, i.e., it may change without input to
maintain consistency
Eventual consistency: Data will be eventually consistent without any
interim perturbation
Sacrifices consistency
To counter ACID
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 4 / 12

11. Types
Four main types of NoSQL data stores:
1 Columnar families
2 Bigtable systems
3 Document databases
4 Graph databases
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 5 / 12

12. Columnar storage
Instead of rows being stored togther, columns are stored
consecutively
A single disk block (or a set of consecutive blocks) stores a single
column family
A column family may consist of one or multiple columns
This set of columns is called a super column
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 6 / 12

13. Columnar storage
Instead of rows being stored togther, columns are stored
consecutively
A single disk block (or a set of consecutive blocks) stores a single
column family
A column family may consist of one or multiple columns
This set of columns is called a super column
Two main types
Columnar relational models
Key-value stores and/or big tables
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 6 / 12

14. Columnar relational models
Not NoSQL and is actually RDBMS
Column-wise storage on the disk
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 7 / 12

15. Columnar relational models
Not NoSQL and is actually RDBMS
Column-wise storage on the disk
Allows faster querying when only few columns are touched on the
entire data
Allows compression of columns
Provides better memory caching
Joins are faster since they are mostly on similar columns from two
tables
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 7 / 12

16. Columnar relational models
Not NoSQL and is actually RDBMS
Column-wise storage on the disk
Allows faster querying when only few columns are touched on the
entire data
Allows compression of columns
Provides better memory caching
Joins are faster since they are mostly on similar columns from two
tables
Is not good for updates
Is not good when many columns of a few tuples are accessed
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 7 / 12

17. Columnar relational models
Not NoSQL and is actually RDBMS
Column-wise storage on the disk
Allows faster querying when only few columns are touched on the
entire data
Allows compression of columns
Provides better memory caching
Joins are faster since they are mostly on similar columns from two
tables
Is not good for updates
Is not good when many columns of a few tuples are accessed
Good for OLAP (online analytical processing)
Not good for OLTP (online transaction processing)
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 7 / 12

18. Columnar relational models
Not NoSQL and is actually RDBMS
Column-wise storage on the disk
Allows faster querying when only few columns are touched on the
entire data
Allows compression of columns
Provides better memory caching
Joins are faster since they are mostly on similar columns from two
tables
Is not good for updates
Is not good when many columns of a few tuples are accessed
Good for OLAP (online analytical processing)
Not good for OLTP (online transaction processing)
Example: MonetDB
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 7 / 12

19. Key-value stores
Two columns: a key and a value
Key is mostly text
Value can be anything and is simply an object
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 8 / 12

20. Key-value stores
Two columns: a key and a value
Key is mostly text
Value can be anything and is simply an object
Essentially, actual data becomes “value” and an unique id is
generated which becomes “key”
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 8 / 12

21. Key-value stores
Two columns: a key and a value
Key is mostly text
Value can be anything and is simply an object
Essentially, actual data becomes “value” and an unique id is
generated which becomes “key”
Whole database is then just one big table with these two columns
Becomes schema-less
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 8 / 12

22. Key-value stores
Two columns: a key and a value
Key is mostly text
Value can be anything and is simply an object
Essentially, actual data becomes “value” and an unique id is
generated which becomes “key”
Whole database is then just one big table with these two columns
Becomes schema-less
Can be distributed and is, thus, highly scalable
So, in essence a big distributed hash table
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 8 / 12

23. Key-value stores
Two columns: a key and a value
Key is mostly text
Value can be anything and is simply an object
Essentially, actual data becomes “value” and an unique id is
generated which becomes “key”
Whole database is then just one big table with these two columns
Becomes schema-less
Can be distributed and is, thus, highly scalable
So, in essence a big distributed hash table
All queries are on keys
Keys are necessarily indexed
Uses memcache where most queried keys are persisted in memory
for faster access
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 8 / 12

24. Key-value stores
Two columns: a key and a value
Key is mostly text
Value can be anything and is simply an object
Essentially, actual data becomes “value” and an unique id is
generated which becomes “key”
Whole database is then just one big table with these two columns
Becomes schema-less
Can be distributed and is, thus, highly scalable
So, in essence a big distributed hash table
All queries are on keys
Keys are necessarily indexed
Uses memcache where most queried keys are persisted in memory
for faster access
Example: Cassandra, CouchDB, Tokyo Cabinet, Redis
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 8 / 12

25. Bigtable systems
Started from Google’s BigTable implementation
Uses a key-value store
Data can be replicated for better availability
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 9 / 12

26. Bigtable systems
Started from Google’s BigTable implementation
Uses a key-value store
Data can be replicated for better availability
Uses a timestamp
Timestamp is used to
Expire data
Delete stale data
Resolve read-write conflicts
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 9 / 12

27. Bigtable systems
Started from Google’s BigTable implementation
Uses a key-value store
Data can be replicated for better availability
Uses a timestamp
Timestamp is used to
Expire data
Delete stale data
Resolve read-write conflicts
Same value can be indexed using multiple keys
Map-reduce framework to compute
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 9 / 12

28. Bigtable systems
Started from Google’s BigTable implementation
Uses a key-value store
Data can be replicated for better availability
Uses a timestamp
Timestamp is used to
Expire data
Delete stale data
Resolve read-write conflicts
Same value can be indexed using multiple keys
Map-reduce framework to compute
Example: BigTable, HBase, Cassandra, HyperTable, SimpleDB
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 9 / 12

29. Document databases
Uses documents as the main storage format of data
Popular document formats are XML, JSON, BSON, YAML
Document itself is the key while the content is the value
Document can be indexed by id or simply its location (e.g., URI)
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 10 / 12

30. Document databases
Uses documents as the main storage format of data
Popular document formats are XML, JSON, BSON, YAML
Document itself is the key while the content is the value
Document can be indexed by id or simply its location (e.g., URI)
Content needs to be parsed to make sense
Content can be organised further
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 10 / 12

31. Document databases
Uses documents as the main storage format of data
Popular document formats are XML, JSON, BSON, YAML
Document itself is the key while the content is the value
Document can be indexed by id or simply its location (e.g., URI)
Content needs to be parsed to make sense
Content can be organised further
Extremely useful for insert-once read-many scenarios
Can use map-reduce framework to compute
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 10 / 12

32. Document databases
Uses documents as the main storage format of data
Popular document formats are XML, JSON, BSON, YAML
Document itself is the key while the content is the value
Document can be indexed by id or simply its location (e.g., URI)
Content needs to be parsed to make sense
Content can be organised further
Extremely useful for insert-once read-many scenarios
Can use map-reduce framework to compute
Example: MongoDB, CouchDB
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 10 / 12

33. Graph databases
Nodes represent entities
Edges encode relationships between nodes
Can be directed
Can have hyper-edges as well
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 11 / 12

34. Graph databases
Nodes represent entities
Edges encode relationships between nodes
Can be directed
Can have hyper-edges as well
Easier to find distances and neighbors
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 11 / 12

35. Graph databases
Nodes represent entities
Edges encode relationships between nodes
Can be directed
Can have hyper-edges as well
Easier to find distances and neighbors
Example: Neo4J, HyperGraph, Infinite Graph, FlockDB
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 11 / 12

36. Discussion
NoSQL, although started as anti-SQL, is no more so
More a realisation that for some cases
RDBMS does not scale or distribute, and in some other cases
ACIDity is an overkill
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 12 / 12

37. Discussion
NoSQL, although started as anti-SQL, is no more so
More a realisation that for some cases
RDBMS does not scale or distribute, and in some other cases
ACIDity is an overkill
NoSQL is not good for every scenario
Not every good feature reported has been validated
Most legacy systems still use RDBMS
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 12 / 12

38. Discussion
NoSQL, although started as anti-SQL, is no more so
More a realisation that for some cases
RDBMS does not scale or distribute, and in some other cases
ACIDity is an overkill
NoSQL is not good for every scenario
Not every good feature reported has been validated
Most legacy systems still use RDBMS
NoSQL horizon is shifting rapidly with almost no control or sense
However, trend is for NoSQL as cloud computing and big data relies
on it
Arnab Bhattacharya (arnabb@cse.iitk.ac.in) CS315: NoSQL 2013-14 12 / 12