Information Storage and Retrieval: NoSQL Models for Retrieval and Scale

Lesson overview

Introduce NoSQL data models including key-value, document store, column-family and graph database approaches, with retrieval and scalability trade-offs.

CourseInformation Storage and Retrieval

Topic strandNoSQL data

Assessment styleWorked scenario, applied task and digital exam practice

EvidenceDefinitions, representation, method, result and interpretation

Starter

Write down the user need, the data being stored or searched, and the decision the system has to support. Then predict which representation, index, query method or governance control will matter most in this lesson.

Learning objectives

Compare key-value, document store, column-family and graph database models.
Explain why NoSQL systems often denormalise around access patterns.
Evaluate consistency, query flexibility and scale trade-offs.

Learning outcomes

Students can compare key-value, document store, column-family and graph database models.
Students can explain why NoSQL systems often denormalise around access patterns.
Students can evaluate consistency, query flexibility and scale trade-offs.

Key vocabulary, acronyms and terminology

NoSQL: Not only SQL: a broad family of non-relational or SQL-adjacent data systems designed around particular scale and access-pattern needs.
SQL: Structured Query Language: the relational query language that NoSQL systems do not primarily rely on, though some offer SQL-like interfaces.
key-value: Storage model retrieving values by unique keys.
document store: Database storing semi-structured documents such as JSON.
column-family: Wide-column model designed for distributed scale.
graph database: Database optimised for nodes, relationships and traversals.
access pattern: The way an application needs to read or write data.

Detailed teaching notes

Core concept

NoSQL is not one technology. It is a set of models that trade relational generality for particular access patterns, scale properties or flexible structures.

Representation choice

A document store might keep one product record with nested reviews. A graph database might store users and follows relationships. A key-value store might cache sessions by id.

Method and reasoning

Start from access patterns. If retrieval is by id, key-value may be enough. If documents vary in shape, document store may fit. If relationships are central, graph database is stronger.

Risk and limitation

Denormalising around one access pattern can make another query difficult. NoSQL design still requires modelling discipline.

Degree-level deep dive

NoSQL is model choice, not chaos

NoSQL systems are designed around access patterns, scale and flexibility. A document store, key-value store, column-family store and graph database solve different retrieval problems.

Denormalisation moves responsibility

NoSQL designs often duplicate data for fast reads. That can improve scale but shifts consistency and update responsibility to the application, pipeline or database features. The design must say how duplicated facts stay acceptably current.

What excellent work shows

A strong answer maps each access pattern to a data model and states the trade-off. It should explain why a graph is good for traversals, a key-value store for direct lookup and a document store for variable aggregates.

Concrete example to study

Access-pattern mapping

Need: retrieve session by id -> key-value store
Need: retrieve product with varied attributes -> document store
Need: find friends-of-friends -> graph database
Need: scan event counts by user and day -> column-family store

Reasoning

Each model is chosen from the read/write pattern.
The document store may duplicate category names for fast reads.
The graph model is chosen because relationship traversal is central.

Reveal takeaway

NoSQL design is disciplined modelling around access patterns, consistency and scale, not a decision to ignore schema or data quality.

Worked example

Scenario

A social app needs user profiles, login sessions and friend recommendations.

Worked solution

Use key-value storage for short-lived sessions by session id.
Use a document store for profile documents if fields vary.
Use a graph database or graph projection for friend relationships and recommendations.
State consistency needs separately for sessions, profiles and relationships.

Reveal model result

Different NoSQL models can coexist because each retrieval pattern has different requirements.

\text{Define the data, choose the representation, apply the method, interpret the result.}

Applied retrieval task

Choose NoSQL models for an online learning platform.

Deliverables

Map three access patterns to suitable models.
Identify one denormalised field.
State one consistency risk.

Success checks

The model choice follows access patterns.
Trade-offs are explicit.

Common misconception

NoSQL does not mean unplanned storage. The schema may be flexible or application-managed, but modelling still matters.

Quick checks

1. In this lesson, why does NoSQL matter?

Not only SQL: a broad family of non-relational or SQL-adjacent data systems designed around particular scale and access-pattern needs.It replaces the need to understand user tasks or data representation.It is only a presentational label and has no effect on retrieval quality.

2. Which answer best shows degree-level understanding of nosql models for retrieval and scale?

Name as many technologies as possible without explaining the scenario.Give a final recommendation without showing how the data or query was represented.Define SQL, apply it to the scenario, then explain the trade-off or risk.

Digital exam practice

Example exam task

A large application stores user sessions, product catalogues and recommendation relationships, and the relational database is struggling under scale. In your answer, define the relevant objects or data structures, use course-specific vocabulary, show the method rather than only the result, and finish with a decision about the storage or retrieval system.

Notation and technical toolkit

key -> valuekey-value retrieval Use for direct lookup.

{ JSON document }document store record Use for semi-structured aggregates.

(node)-[edge]->(node)graph database relationship Use for relationship-heavy retrieval.

What a good answer is expected to show

A strong answer for NoSQL Models for Retrieval and Scale the answer should compare key-value, document store, column-family and graph database options and connect each to retrieval patterns. It should connect the formal or technical representation to the user's information need instead of listing terms without using them.

How to solve it

List the main access patterns.
Map each access pattern to an appropriate NoSQL model.
Explain denormalisation or duplication needed for fast reads.
Discuss consistency and query-flexibility trade-offs.

Model answer

Reveal model answer

User sessions are a good fit for key-value storage because the application retrieves a session by id. Product catalogues may fit a document store because each product can keep nested attributes and media metadata that vary by category. Recommendation relationships may fit a graph database because traversal is central. A column-family design could support very large time-series or event records. These choices improve scale for specific access patterns but may duplicate data and require explicit consistency policies.

Practise next

Give one retrieval task where a graph database is better than a document store.
Explain why NoSQL does not mean no schema at all.

Self-marking criteria

Defines the scenario objects, data forms or system components before solving.
Uses the lesson vocabulary accurately and in context.
Shows a clear method with enough working for a marker to follow.
Connects the result back to retrieval, storage, analytics or governance.
States a limitation, trade-off or quality risk rather than presenting the answer as absolute.

Extension

Research CAP theorem at a high level and connect it to one NoSQL consistency choice.

Study route

Save a short worked answer from this lesson using this pattern: define the need or data, choose the representation, show the method, state the result and interpret the implication for the system.

Next lesson: Cloud Storage and Distributed Processing.