NoSQL data modeling focuses on designing data structures for systems that do not rely on traditional relational tables as the main model. This cheat sheet helps college students compare document, key-value, wide-column, and graph databases using practical design rules. It is useful when choosing schemas for scalability, flexible data, low-latency reads, or highly connected data.
The goal is to model around application queries instead of only around normalized entities.
The most important ideas are access patterns, denormalization, partition keys, indexes, and consistency choices. A common rule is to store together the data that is read together, even if that creates duplication. Partition design controls how data is distributed, while indexing controls how efficiently it can be found.
Consistency models such as strong consistency and eventual consistency affect correctness, speed, and availability.
Key Facts
- Model NoSQL data from queries first: access pattern + required filters + sort order + expected read or write volume should guide the schema.
- Use denormalization when a query needs fast reads: duplicate selected fields so one read can answer the request without joins.
- For document databases, embed data for one-to-few relationships and reference data for many-to-many or frequently changing relationships.
- For key-value stores, the main operation is value = get(key), so the key must encode the lookup pattern clearly.
- For wide-column stores, a common primary key pattern is partition key + clustering key, where the partition key distributes data and the clustering key sorts rows within a partition.
- For graph databases, model entities as nodes and relationships as edges when queries need fast traversal such as friend-of-friend or dependency paths.
- A useful partition rule is choose a high-cardinality partition key that spreads writes evenly and avoids hot partitions.
- Under the CAP idea, during a network partition a distributed database must prioritize availability or consistency, so design choices affect failure behavior.
Vocabulary
- Document database
- A NoSQL database that stores records as flexible documents, often JSON-like objects with nested fields.
- Key-value store
- A database model that stores each value under a unique key and retrieves data primarily by exact key lookup.
- Wide-column store
- A database model that organizes data into rows with flexible columns and uses partitioning for large-scale distribution.
- Denormalization
- The intentional duplication or grouping of data to make reads faster and reduce the need for joins.
- Partition key
- A field or set of fields used to decide where data is stored across database nodes or partitions.
- Eventual consistency
- A consistency model where replicas may temporarily disagree but should converge to the same value if no new updates occur.
Common Mistakes to Avoid
- Designing a NoSQL schema like a fully normalized SQL schema is wrong because many NoSQL systems do not support efficient joins across large distributed data sets.
- Choosing a low-cardinality partition key is wrong because values such as status = active can place too much traffic on one partition and create a hot spot.
- Embedding unbounded arrays in one document is wrong because a document can grow too large and make updates, reads, or storage limits difficult to manage.
- Creating indexes for every field is wrong because indexes improve selected reads but add storage cost and slow down writes.
- Ignoring consistency requirements is wrong because eventual consistency may show stale data in workflows that require immediate correctness, such as payments or inventory reservations.
Practice Questions
- 1 A shopping app must fetch an order and all of its line items in one read. Should the line items usually be embedded in the order document or stored in a separate collection with joins, and why?
- 2 A key-value cache stores user session data using keys in the form session:{sessionId}. If there are 2,000,000 sessions and one get operation per session per day on average, about how many get operations occur per day?
- 3 A wide-column table stores events with primary key userId + timestamp. If user A writes 50,000 events per hour and most other users write 10 events per hour, what partitioning problem may occur?
- 4 Explain why a graph database can be a better fit than a document database for finding all people connected to a user within three friendship steps.
Understanding NoSQL Data Modeling Reference
A useful model begins with a concrete request from the application. For a course portal, this might be showing one student’s current classes, assignments due this week, and recent grades. Write down the exact inputs, the result size, and how often the request runs.
A request that returns one student profile needs a different structure from a report that scans grades across an entire department. Estimate the largest realistic data size, not just the size at launch. A design that works for thirty students may fail when thousands submit work at the same deadline.
Duplication makes reads simpler, but it creates an update responsibility. Suppose each assignment document stores the course title and instructor name for display. If the instructor changes, old documents can show stale information unless the system updates them.
Some copied fields are safe because they rarely change, such as a course code from a completed term. Other fields need a repair plan.
Applications often update copies at the time of a change, place updates in a background job, or accept a short period of stale display data. Students should distinguish data that is authoritative from data that is a read-focused copy.
Indexes are not free shortcuts. They speed up a known lookup by storing extra organization, much like a book index stores terms with page locations. Each index consumes storage and adds work during writes.
An index on every field can make inserts slower and can still perform poorly if many records share the same value. For example, indexing grade status is not very selective when most records say submitted.
Indexes work best when a filter narrows the result sharply. Check whether a query can use one index efficiently, whether it must sort a large result afterward, and whether its filter is supported by the database rather than only by application code.
Distribution problems often appear as uneven workload rather than obvious errors. A popular course, a single campus, or the current minute can receive far more writes than other values. That concentration can overload one machine even when the overall cluster has plenty of capacity.
A common response is to add a small calculated bucket to a busy grouping, then read several buckets when needed. This improves spread but makes retrieval more complex. Failure behavior needs equal attention.
A grade submission usually needs confirmation that the saved value is the current one. A social feed can often tolerate a delayed update.
Define what must never be lost, what may temporarily differ between copies, and how conflicts are resolved when two devices change the same record. Test these rules with delayed networks, repeated requests, and partial write failures.