This document discusses NoSQL databases and why they are used. It begins by defining NoSQL as "not only SQL" or "not SQL" databases that do not use a relational schema. The need for NoSQL databases arose in the early 2000s due to difficulties scaling MySQL databases for large amounts of data. NoSQL databases are classified based on their data model, consistency, and performance. They offer flexible data models including structured, unstructured, and semi-structured data. NoSQL databases focus on developer agility by being easy to use and integrate with modern frameworks. While they scale well horizontally, they generally lack ACID compliance and transaction support of relational databases.

1. D H A R S H A N R A N G E G O W D A
F O U N D E R , S C A L E G R I D . I O
A P R I L 2 0 1 4
Why NoSQL?

2. What is NoSQL?
 “Not only SQL”
 “Not SQL”
 Term popularized by Eric
Evans of Rackspace in 2009
 Class of databases that don’t
use a “Relational schema”
 NoSQL <> No T-SQL

3. NoSQL history
 Need arose in Early 2000 due to difficulties scaling
MySQL databases
 Need to deal with large amounts of data
 E.g. MongoDB founders are from Doubleclick

4. Classification
• Classified along
multiple dimensions
• Data model
• Consistency
• Performance

5. Complete classification

6. Data model
 Flexible data model
 structured, unstructured & semi structured data
 Different types of data
 JSON/XML
 Documents
 Files
 Store files & structured data
 No separate workflow for files

7. Schema less
 Each row in a table can be different!
 Double edged sword
 There is always a schema, in the db or in the code

8. Developer agility
Focus on developer
agility
 Extremely easy to get
started
 Got rid of impedance
mismatch between
app code and SQL
 Always work with
objects
• Big hit with developers

9. Developer agility
 Great Geo query support
 Extremely important for most web apps today
 Great integration with new frameworks
 Node.js, Meteor.js

10. Database Scaling
• Easy (relatively) scale for your database
– Scale up or scale out
– Scale out using commodity servers
– Automatic partitioning & rebalancing

11. Scale out : MongoDB shards

12. Cons?
 Not ACID compliant (mostly)
 Transaction scope is usually limited
 Consistency can also vary
 If you are writing a banking application stick to RDBMS 
 Engineering
 Relatively immature
 Don’t have 3 decades of engineering in them

13. Adoption
• Web properties
– Scale features
– Document support
– Geo support
• Data warehouse
– Handle TB’s of data
– Cost

14. Future?

15. Q & A
Email : Dharshanr@scalegrid.io
Twitter: @dharshanrg