Search and Wide-Column Stores

Two more families share this page, and they are portraits rather than full lessons — enough to recognize each on sight and know what it trades. The first, the search engine, makes text genuinely findable, the way LIKE only pretended to. The second, the wide-column store, takes the spreading-across-machines pressure from earlier in the chapter and rebuilds the whole idea of a table around it.

Why LIKE Was Never Search

Back in Chapter 3 you could match text loosely with LIKE '%night%' — find rows whose title contains those letters. It works for exact fragments, and that's where it stops. Try to build the Marquee's film-search box on it and the cracks show at once:

SELECT title FROM films WHERE title LIKE '%night%';

It can't rank results by how well they match. It can't forgive a typo — search "nihgt" and you get nothing. It can't understand that "running" and "run" are the same word, and it slows to a crawl over long text. LIKE matches characters; real search understands words, and that difference is a whole different machine.

The Search Engine's Shape

A search engine — Elasticsearch is the household name — is fed documents and builds an inverted index. Remember Chapter 8's phone book, sorted so you could jump straight to a name? An inverted index is that idea turned inside out. A normal book index at the back lists, for each page, roughly nothing — you read the page to get its words. An inverted index lists, for each word, every place it appears. Instead of "page 90's words", it stores "the word's pages".

With every word pre-indexed that way, the engine can find matches instantly, rank them by relevance, forgive typos, and treat "running" and "run" alike. Type "nihgt bus" into the Marquee's search and Night Bus comes back at the top — the win LIKE could never manage. The honest trade, and it's the chapter's refrain a third time: the search engine holds a copy of the film text, fed from the relational database, which stays the source of truth. Lose the search index and you lose fast searching, never a fact — rebuild it from the films and carry on.

The Wide-Column Store

The second portrait answers a different pressure entirely. A wide-column store — Cassandra is the name — begins from the assumption that data will spread across many machines, and it accepts every limit that spreading imposes rather than fighting them. There are no JOINs. Writes can land on any machine. And crucially, you don't design tables around your nouns the way Chapter 6 taught — you design them around your questions.

That last part is the deliberate reversal. In the relational world you modeled films, screenings, and customers as things, then queried them any way you liked. In a wide-column store you decide the exact questions up front and build a table shaped to answer each one, because the key that spreads the data across machines also dictates what you can ask. "Design per query, not per noun" is the anti-Chapter-6 bargain, taken on purpose to make planet-scale spreading work.

When Each Earns Its Keep

A search engine earns its place in any product with a search box over real text — a film catalog, a shop, a help center, a news archive. Whenever people type words and expect ranked, forgiving results, there's a search engine behind the box, quietly holding its copy. A wide-column store earns its place in write-heavy, planet-spread, key-shaped workloads: floods of sensor readings, activity feeds for hundreds of millions of users, anything where the volume outgrows one machine and the questions are known in advance.

And neither one earns a place at the Marquee's core. Bookings are a modest, interconnected, transaction-shaped job — the relational database's home ground, and the refrain holds. These are specialists you add beside the core when a specific pressure calls, not replacements for it.