Sign in to save

Bookmark this page so you can find it later.

Sign in to save

Bookmark this page so you can find it later.

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. 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. 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. 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. 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.