Unit 1: Introduction to NoSQL and MongoDB - Subjective Questions

NoSQL means "Not Only SQL" and refers to database systems designed to store and process large volumes of semi-structured, unstructured, or distributed data.

Key characteristics include:

• Flexible schema: NoSQL databases generally do not require every record to have the same structure.
• Horizontal scalability: Data and workloads can be distributed across multiple servers by adding more machines.
• High availability: Replication and distributed architectures help systems remain operational during failures.
• High performance: NoSQL systems are optimized for specific access patterns and large-scale workloads.
• Multiple data models: Common models include key-value, document, column-oriented, and graph databases.
• Eventual consistency: Some systems prioritize availability and partition tolerance over immediate consistency.

NoSQL databases are commonly used in big data, real-time analytics, content management, Internet of Things applications, and social networking systems.

SQL and NoSQL databases differ in several important ways:

• Data model: SQL databases use tables, rows, and columns, whereas NoSQL databases may use documents, key-value pairs, column families, or graphs.
• Schema: SQL databases usually require a predefined and rigid schema. NoSQL databases generally support flexible or schema-on-read designs.
• Scalability: SQL systems traditionally scale vertically by increasing server capacity. NoSQL systems are commonly designed for horizontal scaling across multiple servers.
• Transactions: SQL databases provide strong support for multi-row and multi-table ACID transactions. NoSQL transaction support varies by product and may be optimized for simpler or distributed operations.
• Consistency: SQL databases normally emphasize strong consistency. NoSQL databases may provide tunable consistency or eventual consistency.
• Query language: SQL databases use standardized SQL, while NoSQL systems use product-specific APIs or query languages.
• Applications: SQL is suitable for banking, accounting, and highly structured systems. NoSQL is suitable for social media, real-time applications, large-scale content systems, and rapidly changing data.

The correct choice depends on data structure, transaction requirements, scalability needs, and workload characteristics.

Advantages:

• Flexible schemas support changing application requirements.
• Horizontal scaling allows capacity to grow by adding servers.
• Distributed replication can improve availability and fault tolerance.
• Specialized data models can provide efficient access for particular use cases.
• NoSQL systems can handle large volumes of high-velocity and diverse data.
• Development may be faster because application objects can be stored in a form close to their programming representation.

Limitations:

• Query languages and features are less standardized than SQL.
• Complex joins and analytical queries may be difficult or inefficient.
• Consistency may be weaker in systems designed for high availability.
• Data modeling often depends heavily on anticipated query patterns.
• Different NoSQL products have different APIs, operational models, and transaction capabilities.
• Poorly designed denormalized data may lead to duplication and update anomalies.

NoSQL is valuable when scale, flexibility, or availability is more important than strict relational structure, but it should be selected according to the application's actual requirements.

MongoDB is a distributed, document-oriented NoSQL database designed for storing and processing data at scale.

It is classified as a document database because:

• Data is stored in BSON documents, which are binary representations of JSON-like data.
• Documents contain fields and values, including nested documents and arrays.
• Related data can often be stored together in one document instead of being distributed across many tables.
• Collections contain documents and are broadly comparable to tables in relational databases.
• Documents in the same collection can have different fields, providing schema flexibility.
• MongoDB supports indexes, aggregation, replication, sharding, and transactions.

For example, a customer document can contain the customer's name, contact information, and address as a nested object. This model is convenient for applications that work with hierarchical or rapidly changing data.

The CAP theorem states that a distributed data store cannot simultaneously guarantee all three of the following properties during a network partition:

• Consistency: Every read receives the most recent write or an error.
• Availability: Every request receives a response, even if the response may not contain the latest data.
• Partition tolerance: The system continues operating despite communication failures between nodes.

Because network partitions are unavoidable in distributed systems, practical systems must tolerate partitions and choose how to balance consistency and availability.

• A CP system prioritizes consistency and partition tolerance. It may reject or delay requests during a partition.
• An AP system prioritizes availability and partition tolerance. It continues responding but may temporarily return stale data.
• A system that behaves like CA can provide consistency and availability only when partitions are not considered, which is generally unsuitable for widely distributed systems.

The CAP theorem concerns behavior during partitions. It does not mean that a database must permanently choose only two properties in every situation.

A key-value database stores data as a collection of unique keys associated with values.

Structure and operations:

• A key uniquely identifies an item.
• The value may be text, numbers, serialized objects, or binary data.
• Common operations are put, get, and delete.

Advantages:

• Very simple data model.
• Extremely fast lookup when the key is known.
• Easy horizontal scaling and partitioning.
• Suitable for high-throughput workloads.

Limitations:

• Queries based on value contents may be limited.
• Relationships between values are not naturally represented.
• Complex filtering and joins are usually unavailable.
• Applications must often manage data structure and relationships themselves.

Applications:

Key-value databases are commonly used for caching, session management, shopping carts, user preferences, configuration data, and rapidly accessed lookup information. Redis and Amazon DynamoDB are examples of key-value-oriented systems.

A column-oriented database stores values from the same column together rather than storing an entire row contiguously.

Differences from row-oriented storage:

• Row-oriented systems are efficient when retrieving or updating complete records.
• Column-oriented systems are efficient when reading a small number of columns from many records.
• Columns often compress well because values in the same column have similar types and patterns.
• Aggregation operations such as sums, averages, and counts can be performed efficiently.
• Column-oriented NoSQL systems often distribute data across nodes using column families or partitions.

Advantages:

• Efficient analytical queries.
• High compression ratios.
• Good performance for large-scale datasets.
• Horizontal scalability and fault tolerance.

Limitations:

• Less suitable for frequent complete-row updates.
• Data modeling is often driven by query patterns.
• Relationships and ad hoc joins may be limited.

Apache Cassandra and HBase are examples of wide-column or column-family databases.

A document database stores data as self-contained documents, usually represented using JSON-like structures such as BSON.

Important features:

• Documents contain fields, nested objects, and arrays.
• Documents in one collection may have different structures.
• Related data can be embedded inside a document.
• Documents can be indexed and queried by field values.
• The model maps naturally to objects used by many application programs.

Compared with relational databases:

• A document is broadly comparable to a row, and a collection is broadly comparable to a table.
• Documents are usually more flexible than rows with fixed columns.
• Relationships may be represented through embedding or references instead of normalized foreign-key tables.
• Document databases often reduce joins by storing frequently accessed data together.
• Relational databases generally provide stronger standardization and mature support for complex joins and transactions.

The document model is particularly effective for catalogs, user profiles, content management, and event data.

A graph database represents information using nodes, edges, and properties.

• Nodes represent entities such as users, products, or locations.
• Edges represent relationships such as follows, purchased, connected-to, or located-in.
• Properties store attributes on nodes or relationships.

Graph databases are appropriate when relationships are central to the application and must be traversed efficiently. Examples include:

• Social network analysis.
• Recommendation systems.
• Fraud detection.
• Network and route analysis.
• Knowledge graphs.
• Identity and access management.

Unlike relational systems, graph databases can traverse connected data directly without repeatedly performing complex joins. Their performance is especially useful for multi-hop relationship queries, where the system must discover entities connected through several relationships.

The choice should be based on the dominant access pattern. Key-value systems are best when direct lookup is required, document systems when records are hierarchical, column-oriented systems for large distributed datasets, and graph systems when relationships are the primary focus.

The main components of MongoDB architecture are:

• Database: A logical container for collections and associated data.
• Collection: A group of MongoDB documents, broadly comparable to a table.
• Document: A BSON data record composed of fields and values.
• Field: A named attribute within a document.
• Index: A data structure that improves query performance by avoiding full collection scans.
• MongoDB server process: The mongod process manages data storage, queries, indexes, replication, and configuration.
• MongoDB client: Applications, the MongoDB Shell, Compass, and drivers send commands to the server.
• Replica set: A group of MongoDB servers that maintain copies of data for redundancy and high availability.
• Sharded cluster: A distributed deployment that partitions data across shards for horizontal scaling.
• Config servers and mongos: In a sharded deployment, config servers store cluster metadata and mongos routes client operations to the appropriate shards.

Together, these components support flexible document storage, high availability, and distributed scaling.

A MongoDB document is a set of field-value pairs stored in BSON format. BSON is a binary serialization format that extends JSON-like data with additional types such as dates, binary data, and decimal values.

Important document features include:

• Fields: Each field has a name and a value.
• _id field: Every document must have a unique _id value within its collection. MongoDB generates an ObjectId by default when one is not supplied.
• Embedded documents: An object can be placed inside another document to represent related hierarchical data.
• Arrays: A field may contain multiple values, including arrays of documents.
• Flexible structure: Documents in the same collection may contain different fields, although applications should still maintain logical consistency.

For example, a customer document may contain an embedded address document and an array of phone numbers. This structure can reduce the need for joins and allow related information to be retrieved together.

Embedding stores related data inside the parent document, while referencing stores related data in separate documents and connects them using an identifier.

Embedding is suitable when:

• Related data is usually accessed together.
• The relationship is one-to-one or one-to-few.
• The embedded data does not grow without limit.
• Duplication is acceptable for faster reads.

Referencing is suitable when:

• Related data is shared by many documents.
• The relationship is one-to-many with potentially large growth.
• Child data is accessed independently.
• Frequent updates should occur in one place.
• Embedding would make documents too large or difficult to maintain.

The decision should consider read and write patterns, relationship cardinality, document size, update frequency, and consistency requirements. MongoDB modeling is therefore query-oriented: data should be organized according to how the application reads and updates it.

A typical installation process for MongoDB Community Edition is as follows:

1. Identify the operating system and select the appropriate MongoDB Community Edition package.
2. Download the official installer or repository package for the required version.
3. Install the MongoDB server and, where appropriate, MongoDB Shell and related tools.
4. Configure the database storage and log directories according to the operating system.
5. Start the MongoDB server as a service or run the mongod process manually.
6. Ensure that the required executable paths and configuration settings are available.
7. Install or verify the MongoDB Shell, mongosh.

Verification steps:

• Check that the MongoDB service is running.
• Run mongosh and connect to the local server.
• Execute a basic command such as show dbs or db.runCommand({ ping: 1 }).
• Confirm that the server version is the expected version.
• Review logs if the server fails to start.
• Verify that firewall and network settings permit only the required access.

Production installations should also configure authentication, authorization, backups, monitoring, and secure network access.

The MongoDB Shell, commonly invoked as mongosh, is an interactive command-line interface used to connect to MongoDB deployments and execute database commands.

Common operations include:

• Connecting to a local server or a remote deployment.
• Selecting a database with use databaseName.
• Listing databases with show dbs.
• Listing collections with show collections.
• Inserting documents using insertOne() or insertMany().
• Reading documents using find() and findOne().
• Updating documents using updateOne() or updateMany().
• Removing documents using deleteOne() or deleteMany().
• Creating indexes and examining query behavior.
• Running aggregation pipelines.
• Checking server status and database statistics.

mongosh is useful for administration, learning, diagnostics, scripting, and testing database operations. Access should be protected with proper authentication and secure connection settings.

MongoDB Compass is a graphical user interface for MongoDB. It allows users to explore and manage databases without entering every command manually.

Features of Compass include:

• Viewing databases, collections, and documents.
• Filtering and sorting documents.
• Creating and analyzing indexes.
• Building aggregation pipelines visually.
• Inspecting schema patterns and field distributions.
• Viewing server and collection information.
• Editing documents through a graphical interface.

Comparison with mongosh:

• mongosh is command-line based, lightweight, scriptable, and useful for automation and administration.
• Compass is visual, easier for browsing data, and helpful for schema inspection and interactive query development.
• Both tools connect to MongoDB servers and execute database operations through MongoDB drivers or protocols.

Compass is not a replacement for server security or operational planning. It should use authenticated and encrypted connections when accessing remote deployments.

MongoDB Atlas is a managed cloud database service that provides MongoDB clusters through cloud infrastructure providers.

Atlas commonly provides:

• Cluster creation through a web interface or API.
• Automated deployment and scaling options.
• Monitoring, metrics, and alerts.
• Automated backups and point-in-time recovery options, depending on the plan.
• High availability through replica sets and multiple regions.
• Security features such as authentication, encryption, network access controls, and private connectivity.
• Integration with cloud services and deployment tools.

In a self-managed MongoDB Community Edition deployment, the organization is responsible for installing MongoDB, maintaining servers, configuring replication, applying updates, managing backups, monitoring performance, and securing the network.

Atlas reduces operational overhead but introduces cloud costs, provider dependencies, and the need to understand cloud networking and access policies. Community Edition provides more direct infrastructure control but requires greater administrative responsibility.

MongoDB organizes data hierarchically:

• A MongoDB deployment can contain multiple databases.
• A database contains collections.
• A collection contains documents.
• A document contains fields and values.
• A field may contain scalar values, arrays, or embedded documents.

For example, an online store may have a database named store. It may contain a collection named products. A product document could contain fields such as name, price, category, and inventory.

An inventory field might be an embedded document containing warehouse quantities, while a reviews field might be an array of review documents.

This hierarchy provides flexible organization while preserving the document-oriented model. Unlike a relational table, documents within one collection do not necessarily need identical columns, although consistent application design is still important.

Replication maintains multiple copies of data across MongoDB servers. A replica set normally has a primary node that accepts writes and secondary nodes that replicate the data. If the primary fails, an eligible secondary can be elected as the new primary.

Replication improves:

• High availability.
• Fault tolerance.
• Read distribution in suitable configurations.
• Disaster recovery options.

Sharding distributes data across multiple servers called shards. A sharded cluster uses a shard key to determine where documents are stored. A router process, mongos, directs operations to the appropriate shard.

Sharding improves:

• Horizontal storage capacity.
• Write and read throughput.
• Ability to handle datasets larger than one server's capacity.

Replication primarily addresses redundancy and availability, while sharding primarily addresses distribution and scale. A production cluster may use both: each shard can itself be a replica set.

A flexible schema means MongoDB does not force every document in a collection to have identical fields, but it does not eliminate the need for careful design.

Good schema design is important because it affects:

• Query performance: Frequently accessed fields should be modeled and indexed appropriately.
• Read efficiency: Data commonly retrieved together may be embedded in one document.
• Write behavior: Frequently changing data may need to be separated to avoid excessive document updates.
• Document size: Unbounded arrays and excessive embedding can make documents difficult to manage.
• Data consistency: Similar documents should follow predictable naming, types, and validation rules.
• Scalability: A suitable shard key and balanced data distribution depend on thoughtful modeling.
• Maintenance: Consistent structures simplify application code, reporting, and migration.

MongoDB supports validation rules when needed. Therefore, schema flexibility should be used to accommodate legitimate variation, not as a reason to ignore data quality and access patterns.