Introduction Presentation about NoSQL Agenda: - Why NoSQL - What is NoSQL - Distribution Models - The CAP Theorem - NoSQL Types - NoSQL or Relational or Both - Demo!

1. INTRODUCTION TO NOSQL
AHMED HELMY | SENIOR SOFTWARE DEVELOPER

2. AGENDA
 Why NoSQL?
 What is NoSQL?
 Distribution Models
 The CAP Theorem
 NoSQL Types
 NoSQL or Relational or Both?
 Demo!

3. WHY NOSQL
 Relational databases provides
 Default choice for serious data storage
 Concurrency
 Almost Standard
 Big data
 Websites tracking activities in a very detailed way
 Links, social networks, activity logs, etc…
 Require more computing resources
 Scaling up
 Scaling out (Clusters)
 Relational databases are not designed to be run on clusters
 Relational sharding has to be controlled by the application
 Relational on clusters has high license prices
 Google and Amazon (BigTable, Dynamo)

4. WHAT IS NOSQL
 NoSQL databases known by it’s characteristics
 Not using Relational Model
 No relations
 No normalization
 No joins
 No Grouping
 Not using SQL
 CQL
 Distributed (Run on Clusters)
 Open-source
 Schemaless
 BASE (Basically Available, Soft state, Eventual consistency) instead of ACID

5. DISTRIBUTION MODELS
 Single Server
 simplest
 No distribution at all
 Sharding
 Horizontal Scalability
 Putting different parts of the data onto different servers
 Each node does its own reads and writes
 Improve performance
 Can place the data close to where it’s being accessed
 Many NoSQL databases offers auto-sharding
 Replication
 One node is the master or primary
 Master used to update data
 Slave nodes used for scaling read requests horizontally
 If Master fails, the slaves can still handle read request
 Slave can act as a hot backup

6. THE CAP THEOREM
Distribute
d
System
Consistency
Partitioning
Availabilit
y
Node A Node B
Value 1 Value 1
Value 2

7. NOSQL TYPES
 Classified into four types
 Key-Value pair
 Document
 Column Family
 Graph

8. KEY-VALUE
 Hash table, used when all access to the database is via primary key
 Redis, the aggregate being stored does not have to be a domain object, it could be any data structure, Redis supports lists, sets,
hashes, and can do range, diff, union, and intersection operations
 Schema may differ from row to row
 Consistency: is applicable only for operations on a single key
 Newest write wins
 Both values are returned to the client to resolve the conflict
 Transactions: no guarantees on the writes
 Using w factor – replication factor – during the write API call
 The write is reported as successful only when it is written and reported as a success on at least three of the nodes
 Scaling:
 Sharding
 Replication

9. KEY-VALUE
 Use Cases
 Storing Session Information
 Caching (Redis)
 User Profiles, Preferences
 Shopping Cart Data
 When Not to Use
 Relationships among data
 Multi-operation Transactions
 Query by Data
 Workaround to use (Riak Search, Solr,..)
SQL Server Redis
Database instance Redis cluster
Table Namespace
Row Key-value pair
rowid Key

10. DEMO!

11. DOCUMENT
 Documents are the main concept in document databases
 Very geared towards JavaScript and JSON
 Documents are JSON, BSON objects
 CouchDB/MongoDB use javascript as native language
 Document databases store documents in the value part of the key-value store, think about document databases as key-value stores where the value is examinable
 Although MongoDB supports join via DBRef, Embedding child documents as sub-objects inside documents provides for easy access and better performance
 CouchDB supports full REST interface
 Consistency:
 MongoDB database is configured by using replica sets
 Every write can specify the number of servers the write has to be propagated to before it returns as successful
 You can increase the w value for stronger consistency but will suffer on write performance
 Transactions:
 Transactions involving more than one operation are not possible, although there are products such as RavenDB that do support transactions across multiple operations
 Availability: MongoDB implements replication, providing high availability using replica sets
 Scaling:
 Sharding
 Replication

12. DOCUMENT
 Use Cases
 Event Logging
 CMS, Blogs
 Web analytics
 E-commerce
 CouchDB get called “web database”, think of EverNote
 When Not to Use
 Complex Transactions
SQL Server MongoDB
Database instance MongoDB instance
Database database
Table collection
Row document
rowid _id
join DBRef

13. DEMO!

14. KEY FAMILY
 Store data with keys mapped to values, and the values grouped into multiple column families
 Use Cases
 Event Logging
 CMS, Blogs
SQL Server Cassandra
Database instance cluster
Database keyspace
Table Column family
Row row
Column same for all rows Column can be different per row

15. GRAPH
 Store entities and relations between these entities
 Use Cases
 Social Networks
 Routing, and location-based services

16. RELATIONAL IS GOOD
 Familiarity
 Stability
 Feature set
 Support
 Transactions

17. NOSQL OR RELATIONAL OR BOTH
 Type of App
 Consistency vs Massive Scale
 Internal system vs Public
 Below a certain threshold of concurrent usage, NoSQL may be slower than relational
 Productivity
 NoSQL db tooling still immature
 Queries require significant work, and testing
 Programming platforms, frameworks and components may support RDBMSes much more robustly
 If schema subject to frequent change then NoSQL may be more productive
 Skill Sets and Investment
 Does your staff have RDBMS skills already?
 Do you have significant investment in relational database hw/sw?
 Do you want to retool/support both?
 Startups can employ developers who possess NoSQL skills and prefer NoSQL?
 Recommendations
 Large, public, content-centric properties: NoSQL
 Internal, LOB supporting business operations: relational

18. QUESTIONS!

19. REFERENCES
 NoSQL Distilled
 https://martinfowler.com/books/nosql.html
 Understanding NoSQL
 https://www.pluralsight.com/courses/understanding-nosql

20. THANK YOU