Duration
3 days
OVERVIEW
The market is abuzz with terms like NoSQL, Big Data etc. IT decision makers get very confused why they should consider a newer, alternative database when RDBMSs have been around for 20+ years. The characteristics of the data play a major role in selecting the right database. Data such as geo-spatial, engineering parts or molecular modelling requires multiple levels of nesting and complete data model which cannot fit into two-dimensional row-column structure naturally. Multi-level nesting and hierarchies are easily represented in NoSQL products. The next characteristics of the data are volatility of the data model, how frequently does it change. The modern technology world requires dynamic schema, where changes need to be made daily, to fit the ever changing data model.
There are a few popular open source NoSQL databases in market such as Apache CouchDB, MongoDB, Reddis and etc. Those databases are easy scalable, document oriented and NoSQL databases. Most of these databases use JSON or in-memory key-value to store data. NoSQL databases are designed for data whose relations are well represented as a graph consisting of elements interconnected with a finite number of relations between them. This data could be social relations, network topologies, public transport links or road maps.
MongoDB is an open-source document oriented database. MongoDB provides JSON-like structured documents and Dynamic Schema with a highly scalable and performance oriented database. MongoDB has become one of the leading NoSQL databases, helping businesses to rapidly react to new requirements and scale up capabilities. Apache CouchDB focuses on ease of use and having a scalable architecture. It has a document-oriented NoSQL database architecture and it uses JSON to store data, JavaScript as its query language using MapReduce, and HTTP for an API. CouchDB database maintains its data as a collection of independent documents. In CourchDB document metadata contains revision information. CouchDB also implements a form of multi version concurrency control (MVCC) so it does not lock the database file during writes. This course focus on various NoSQL concepts and participants get the hands on experience using MongoDB and Apache CouchDB.
OBJECTIVES
- Understand NoSQL concepts
- Understand categories of NoSQL Databases
- Understand how data stored in a NoSQL data storage
- Architecture of Mongo & CouchDB
- Understand NoSQL database queries and update languages
- Indexing and searching in NoSQL Databases
- Reducing data via reduce function
- Securing NoSQL Database
- Clustering and Scaling of NoSQL Databases
PREREQUISITES
Participant should have a basic understanding of database, text editor and execution of programs. Because during the course participant is required to develop high performance database, so it will be good if the participant has an understanding on the basic concepts of Database (RDBMS).
Day 1
- Introduction and Defining NoSQL Database
Introduction
- What is NoSQL
- What NoSQL Database can do
- Categories of NoSQL Databases
- Installing MongoDB
- Installing CouchDB
- NoSQL Client
- Introduction to MongoDB
- Overview of MongoDB
- MongoDB fundamentals
- Architecture of MongoDB
- Database
- Collection
- Document
- Advantages of MongoDB
- Why use MongoDB
- When to use MongoDB
- Data Modelling
- Create Database
- Drop Database
- Create Collection
- Drop Collection
- Data Types
- Insert Document
- Query Document
- Update Document
- Delete Document
- Queries
- Field equality tests
- Operators available
- Projections
- Limiting Records
- Paging
- Sorting Records
- Simple Updates and Deletes
- Field updates
- Field insertions and removal
- Document deletion
- Existential field values
Day 2
- Indexing and query optimization
- Indexing theory
- Indexing in practice
- Query optimization
- Join $lookup
- Replication
- Replication overview
- Replica sets
- Master - slave replication
- Drivers and replication
- Sharding
- Sharding overview
- A sample shard cluster
- Querying and indexing a shard cluster
- Choosing a shard key
- Sharding in production
- Introduction to CouchDB
- Overview of CouchDB
- CouchDB fundamentals
- Architecture of CouchDB
- Database
- Document
- Advantages of CouchDB
- Why use CouchDB
- When to use CouchDB
- Data Modelling
- Create Database
- Drop Database
- Create Collection
- Drop Collection
- Data Types
- Insert Document
- Query Document
- Update Document
- Delete Document
- Indexing and query optimization
- Indexing theory
- Indexing in practice
- Query optimization
- Join $lookup
- Replication
- Replication overview
- Replica sets
- Master - slave replication
- Drivers and replication
Day 3
- Introduction to Redis
13.1 Redis Compared to Other Databases and Software
13.2 Features
13.3 Why Redis?
- What Redis Data Structures Look Like
- Strings in Redis
- Lists in Redis
- Sets in Redis
- Hashes in Redis
- Sorted sets in Redis
- Redis Web Applications
- Login and Cookie Caching
- Shopping Carts in Redis
- Web Page Caching
- Database Row Caching
- Web Page Analytics
- Commands in Redis
- Strings
- Lists Sets
- Hashes
- Sorted Sets
- Publish/Subscribe
- Sorting
- Transactions
- Expiring Keys
- Data Management
- Persistence Options
- Snapshots
- Append-only File Persistence
- Rewriting/Compacting Append-only Files
- Replication
- Configuring for Replication
- Master/Slave Chains
- Verifying Disk Writes
- System Failures
- Search-based Applications
18.1 Searching in Redis
18.2 Basic Search Theory
18.3 Sorting Search Results
18.4 Sorted Indexes
18.5 Sorting Search Results with ZSETs
- Reducing Memory Use
19.1 Short Structures
19.2 The ziplist Representation
19.3 The intset Encoding for SETs
19.4 Performance Issues for Long ziplists and intsets
19.5 Sharded Structures
19.6 HASHes
19.7 SETs
- Scaling Redis
20.1 Scaling Reads
20.2 Scaling Writes and Memory Capacity
20.3 Handling Shard Configuration
20.4 Creating a Server-sharded Connection Decorator
20.5 Scaling Complex Queries
20.6 Scaling Search Query Volume
20.7 Scaling Search Index Size
20.8 Scaling a Social Network
Programme scope, delivery arrangements and suitability are confirmed during enquiry.