INTRODUCTION OF NoSQL DATABASES ITE311

Summary

The presentation introduces NoSQL databases, with particular emphasis on document-oriented databases and MongoDB. It explains when NoSQL can be useful, how document data is structured and queried, and how document databases scale and maintain availability.

1. What NoSQL Is and Why It Is Used

• NoSQL means “not only SQL.” Unlike traditional relational databases, which organize information into tables of rows and columns, NoSQL databases use other ways to store data.
• NoSQL can suit applications that handle large amounts of data, changing data structures, or many users at once. Examples include social media and online learning applications.
• Relational databases remain useful for structured data. NoSQL is presented as an option when flexibility and scalability are important.
• The presentation identifies four main NoSQL types:
  • Key–value: Stores each item as a key and its value; useful for caching, sessions, and simple lookups. Redis is given as an example.
  • Column-family: Organizes data into rows whose columns can vary; useful for large datasets with flexible columns.
  • Graph: Represents entities as nodes and their relationships as edges, with labels and properties; useful for social networks and other relationship-focused applications.
  • Document: Stores related information in individual documents, often using JSON-like structures. This is the presentation’s main focus.

2. Document Databases and MongoDB

• A document contains fields and values; it may also contain nested documents or arrays.
• A collection groups related documents and is roughly comparable to a relational table. Unlike a table, documents in a collection do not all need identical fields.
• Keeping related information in one document can make it easier to retrieve together and can avoid some joins. The tradeoff is that duplicated data and relationships across documents may be harder to manage.
• MongoDB stores documents in BSON, a binary format based on JSON that supports additional data types.
• The presentation compares MongoDB concepts with relational ones:
  • A collection is similar to a table.
  • A document is similar to a row, but it can hold nested objects, arrays, and multiple related values.

3. Flexible Schemas and Polymorphic Data

• A schema describes a data structure, including fields, data types, and which fields are expected or required.
• In MongoDB, documents in the same collection can have different structures. The presentation calls this a flexible or “schema-less” approach.
• Polymorphic data means storing different kinds of documents in one collection while allowing each kind to have its own fields. For instance, a printed book might have a page count, while an ebook might have a file size and supported devices.
• This flexibility is useful when requirements change, but it can also make validation and queries more complicated. Good data management is still needed.

4. Document Design: Embedding, Referencing, and Nesting

The presentation describes two common approaches for organizing related information:

• Embedding

  • Store related data inside the main document—for example, a student record that includes an array of skills.
  • Best when the related information is usually accessed together.
  • Can reduce extra queries, but may make documents large if too much data is embedded.

• Referencing

  • Store related information separately and connect it using identifiers—for example, keeping students and courses in separate records.
  • Useful when related data is shared, updated, or accessed independently.
  • Requires fetching the related records separately.

• Nesting

  • Put objects or arrays inside other objects or arrays.
  • A few shallow levels can keep related information together. Excessive nesting can make documents harder to read, query, update, and maintain, and may hurt performance.

Practical design guidance from the presentation:

• Choose embedding or referencing based on how data is accessed, updated, and shared.
• Keep frequently used related data together when that simplifies reads.
• Avoid oversized documents and deeply nested structures.
• Balance convenient retrieval against document size and ease of maintenance.

5. Querying and Indexing

• MongoDB uses a JSON-like query syntax, called the MongoDB Query Language (MQL), to find matching documents.
• Queries can use:
  • Comparison operators such as equal, not equal, greater than, less than, and membership in a list.
  • Logical operators: AND requires all conditions to match; OR requires at least one; NOT negates a condition.
• The presentation also explains querying fields inside embedded documents and arrays, including the use of dot notation.
• An index helps MongoDB find matching documents without checking every document. Indexes can cover ordinary fields, fields inside embedded documents, and array values.
• Indexes improve relevant searches but use extra storage and can add work when data is inserted or updated. They are most useful for fields that applications search frequently.

6. CAP, ACID, and BASE

• The CAP theorem concerns distributed databases during a network partition. A system must make a tradeoff between:
  • Consistency: Users see the same, up-to-date data.
  • Availability: The system continues responding to requests.
  • Partition tolerance: The system continues operating despite communication failures between nodes.
• The presentation illustrates that, during a partition, one system might reject requests to preserve consistency, while another might accept requests even if replicas temporarily differ.
• ACID describes transaction properties:
  • Atomicity: A transaction completes fully or not at all.
  • Consistency: A transaction preserves valid database rules.
  • Isolation: Concurrent transactions do not interfere improperly.
  • Durability: A committed result remains saved.
• BASE is presented as an approach associated with highly available distributed systems:
  • Basically Available: The system aims to keep responding.
  • Soft state: Data may change as updates propagate.
  • Eventual consistency: Replicas may temporarily differ but are expected to converge.

7. Scaling, Sharding, and Replication

• Vertical scaling (scale up): Give one server more resources, such as RAM or processing power. It is comparatively simple, but the server has practical limits and remains a single point of failure.
• Horizontal scaling (scale out): Add servers and distribute work among them. This can handle growth across multiple machines but is more complex to set up.
• Sharding: Split a large database into smaller pieces called shards, stored on different servers.
  • Choose a shard key that distributes data reasonably evenly and matches common query patterns.
  • The presentation cautions against keys that concentrate new data on one server, such as timestamps, or keys with too few distinct values, such as a simple status field.
  • User ID is offered as an example of a possible shard key.
• Replica sets: Keep copies of data on multiple servers. The presentation describes a primary that handles writes and secondary copies that can support reads; if the primary fails, another member can take over. Replication is intended to support availability and recovery.

8. Aggregation and Appropriate Use Cases

• MongoDB’s aggregation framework processes and summarizes data inside the database rather than requiring an application to retrieve all records first.
• The described workflow is:
  1. Start with the input data.
  2. Filter out records that do not match.
  3. Sort the remaining records.
  4. Calculate totals or other values.
  5. Reshape the output into a useful report.
• An example is filtering sales from 2026, totaling sales by country, and sorting countries by total.

Document databases are presented as useful for:

• Data whose structure changes or varies between records.
• Product catalogs and content systems.
• Logs and real-time analytics.
• Mobile and social applications with nested data such as posts, comments, and likes.
• Applications with substantial data volumes or high traffic that need horizontal scaling.

Potential poor fits include:

• Workloads with frequent, complex relationships and joins across many collections.
• Systems that require strict transactional consistency everywhere, such as some financial applications.
• Frequent updates to individual fields across many records when another data model would be more efficient.
• Very small or simple applications for which distributed-database complexity would be unnecessary.

Overall, the presentation’s central lesson is that document databases offer flexible data modeling and scaling options, but their benefits depend on thoughtful document design, indexing, and shard-key selection.

Speakers and Sources Featured

• Katrina Montes — Introduces the topic and presents the initial overview of NoSQL, database types, document databases, CAP, ACID, and BASE.
• Reynold Castillo — Presents document databases and MongoDB fundamentals.
• An unnamed presenter — Continues with polymorphic data, document design patterns, nesting, and queries.
• Kian Andrean — Presents indexing.
• Kas — Presents scaling, sharding, replica sets, aggregation, use cases, anti-patterns, and the conclusion.
• The introduction also mentions additional group members, but their names are unclear in the auto-generated subtitles.