For nine chapters this book taught one family, because the relational model earns the default. This chapter tours the others honestly: document stores, key-value stores and the cache, search engines, wide-column stores, and graphs — each built to win one specific job. The question to carry through every page never changes: what did it give up to win?
5 topics
Chapter 1 hung a map on the wall: the relational family at the center, other families around the edge, each with a one-line promise. Nine chapters later you know the center deeply, and the map is due its other half. This chapter walks the edge — the families collectively called NoSQL, a name best read as "not only SQL", because almost nobody replaces the relational core; they add specialists beside it.
Five topics, one refrain. First, why these families exist at all: the three honest pressures that push specific jobs off the relational model. Then a fair portrait of each family in turn, and every portrait ends on the same question, the one you should ask of every database pitch you ever hear: what did it give up? The chapter closes with a family photo — the Marquee running several families side by side, each on the one job it wins.
The four NoSQL families — and the data each one loves
Document storesMongoDB · nested records
Loves data where every item carries its own varying shape — a film with its awards list tucked inside.
Key-value storesRedis · key → value pairs
Loves one tiny question asked a million times a minute — this key, that value, in a millisecond.
Search enginesElasticsearch · an index card per word
Loves real text typed by real people — finds Night Bus even when they type "nihgt bus".
Graph databasesNeo4j · linked dots
Loves connections as the data itself — who follows whom, three hops out.