Chapter 4: NoSQL Databases
✅ Slide 3–4: What Does NoSQL Mean?
• NoSQL = Not Only SQL (not "No SQL")
• It’s a nickname for non-relational databases.
• Unlike traditional SQL databases (which use tables), NoSQL databases:
o Use different structures (like key-value, documents, graphs).
o Are not based on rows & columns.
✅ Slide 5: What’s Special About NoSQL Databases?
• They handle huge data sizes (Big Data).
• Designed for many users at once (scalable).
• Easier for modern app development than traditional databases.
• Perfect for problems that SQL databases struggle with.
✅ Slide 6: History Before NoSQL
• Before 2000: Only a few non-relational databases existed (e.g. IBM IMS).
• Most systems used relational databases like:
o Oracle
o IBM DB2
o Microsoft SQL Server
o MySQL
✅ Slide 7: Rise of the Web & Big Scale
• Late 1990s / early 2000s: Internet exploded.
• Apps had to serve millions, not just office workers.
• Needed databases that could handle speed, scale, and availability.
• This pressure created demand for new tech → NoSQL born.
✅ Slide 8: Big Tech & NoSQL
• Companies like IBM, Google, Amazon, Facebook created new solutions:
o Google MapReduce – process big data across many machines.
o Amazon Dynamo – scalable key-value store.
• These ideas inspired open-source NoSQL databases:
o CouchDB, Cassandra, HBase, MongoDB, Redis, Riak, Neo4j
✅ Slide 9: Database-as-a-Service (DBaaS)
• Many NoSQL databases now offered as fully managed cloud services.
• Means: You don’t have to install/manage the database.
• Examples:
o IBM Cloudant
o Amazon DynamoDB
✅ Slide 10: Quick Recap
• NoSQL = Non-relational databases
• Common traits:
o Handle Big Data
o Flexible
o Great for modern applications
• Gaining popularity since 2000
✅ Slide 11: Recap — Why NoSQL?
• All NoSQL databases are non-relational.
• They're popular now because:
o Big Data needs
o Fast app development
o Scalability and flexibility
✅ Slide 12: Benefits of Using NoSQL
• Fast development (less setup, easy to change structure)
• Flexible schema (no strict tables)
• Good for modern apps (web/mobile)
• High performance with lots of data/users
✅ Slide 13: DBaaS (Database as a Service)
• DBaaS = Cloud-hosted database service
• Pros:
o No need to manage servers
o Faster development
o Less technical burden
• Helps you choose the right hosting type for your database
✅ Slide 14: Performance & Functionality
• Ask yourself:
o What questions will your app ask the database?
o Do you need fast answers (e.g. for web/mobile apps)?
• For fast responses: Use NoSQL
✅ Slide 15: NoSQL or SQL for Analytics?
• For analytics/batch reports:
o Use Relational DBs or Hadoop (good for data warehousing)
• For fast user interaction:
o Use NoSQL
✅ Slide 16: Scalability Questions
• Is your app going to grow?
• How many users will use it at once?
• If unsure → Use NoSQL (scales easily as you grow)
✅ Slide 17: Horizontal Scaling
• Horizontal scaling = add more servers instead of upgrading one
• NoSQL is great for this
• Works well with cloud apps
✅ Slide 18: Data Durability
• Some NoSQL databases store data in memory (faster but risky).
• If you need to keep data safe always:
o Use a database that writes to disk immediately
✅ Slide 19: Strong Consistency
• Relational DBs are good when:
o You need transactions (banking, inventory)
o You want strong consistency (always correct data)
✅ Slide 20: High Availability
• Many NoSQL databases run in clusters:
o No downtime
o Multiple servers working together
• Supports high availability (very reliable)
✅ Slide 21: Replication & Offline Access
• NoSQL databases can:
o Replicate data across servers and locations
o Let apps sync data offline
• Helps with disaster recovery and user availability
✅ Slide 22: Handling Replication
• Some NoSQL databases:
o Handle complex replication safely
o Avoid data corruption
• Many also have flexible schemas (easy to change)
✅ Slide 23: Schema Flexibility
• Most NoSQL databases:
o Allow you to change schema without downtime
o This means you can add/change fields anytime
✅ Slide 24: Skills Matter
• Choose a database that your team can understand and manage
• Match your skills and resources before using NoSQL or bringing it on-premise
✅ Slide 25–26: Integration With App Layer
• Does your app use JSON? → Use NoSQL (e.g. MongoDB)
• Do you need BI tools or dashboards? → Use SQL (they prefer rows & columns)
✅ Slide 27: Cost & Management
• DIY (do-it-yourself) approach:
o You manage everything: hardware, installation, updates
• Can be complex and costly
✅ Slide 28: DBaaS = Simplicity
• Fully managed DBaaS:
o Provider handles everything (setup, scaling, backups)
o You just use the database to build your app
o Fast development
o Better performance
✅ Slide 29: Hosted DB vs DBaaS
• Hosted DB:
o Provider gives you a server
o But you manage the database
• DBaaS:
o Fully managed — no admin work for you
o Saves time and reduces developer stress
✅ Slide 30: Focus on What Matters
• With DBaaS:
o Developers just focus on the app, not the database
o Uptime, scaling, and maintenance = handled by provider
✅ Slide 31: Hosting Decision Summary
• This lesson helps you:
o Understand database hosting options
o Choose the best type based on your needs
Slides 32–40: The 4 Types (Flavors) of NoSQL Databases
1️⃣ Key-Value Stores
• Store data as a simple pair: Key → Value
• Think of it like a dictionary: userID123 → "Deri"
• Best for: Caching, session storage, simple lookups
• Examples: Redis, Amazon DynamoDB, Riak
2️⃣ Document Stores
• Store structured data in documents (usually JSON or XML)
• Flexible: Each document can have a different structure
• Best for: Web/mobile apps, content management, user data
• Examples: MongoDB, CouchDB, Firebase
3️⃣ Column-Family Stores
• Store data in columns instead of rows
• Good for writing/reading massive amounts of data quickly
• Best for: Big Data, analytics, IoT, logs
• Examples: Cassandra, HBase, ScyllaDB
4️⃣ Graph Databases
• Store data as nodes (entities) and edges (relationships)
• Ideal for connected data like social networks or maps
• Best for: Social graphs, recommendations, fraud detection
• Examples: Neo4j, Amazon Neptune, ArangoDB
