Google Cloud services
21 / 24
Google Cloud

NoSQL Data Modelling — Firestore & Bigtable

Model for the queries each store can actually answer, and design a Bigtable row key that does not create a hotspot.

Two NoSQL stores for genuinely different jobs.

Firestore is a filing cabinet with an index card for every attribute. Bigtable is a very long shelf sorted one way only — put all the new books under the same letter and one person is permanently in the way.

Key Concepts

1
    Firestore  document store. Real-time listeners, offline sync,
               strong consistency. Web and mobile backends.
    Bigtable   wide-column. Petabytes, single-digit millisecond,
               no secondary indexes at all. Time series, IoT.
2
Firestore indexes every field automatically, which is the opposite of most NoSQL stores. Single-field queries just work; composite queries need a composite index, and the error message helpfully contains a link that creates it.
3
    where("status", "==", "open").orderBy("createdAt")
      -> needs a composite index on (status, createdAt)
4
Its limits shape the model.
    1 write per second per document (sustained)
    1 MB per document
    no joins -- denormalise and duplicate
5
The sustained write limit is the trap. A counter document updated on every order will throttle. The answer is distributed counters: shard across N documents and sum on read.
6
Collection group queries search every subcollection of a name at any depth, which is what makes a nested model workable.
7
Bigtable is a different discipline entirely. One index — the row key — sorted lexicographically. No secondary indexes, no joins, no ad-hoc queries.
8
The row key is the whole design.
    device#1234#20261001T1200     good: spread by device, then time
    20261001T1200#device#1234     BAD: every write today hits one
                                  contiguous range -- a hotspot
9
Sequential keys are the classic Bigtable mistake. Timestamps or increasing ids put all current writes on one node while the rest of the cluster idles. Prefix with a high-cardinality field, or salt the key.
10
Field promotion and reversed timestamps are the idioms: put the query dimension in the key, and store the timestamp reversed so the newest rows sort first.
11
Choosing. User-facing app data with live updates and modest write rates: Firestore. Enormous append-heavy time series read by key range: Bigtable. Relational queries with joins: neither — use Cloud SQL or Spanner.
12
What the interviewer is probing.1. "What is the Firestore write limit people hit?" Probing: the per-document cap. Stalls: "There is no limit." Moves up: about one sustained write per second per document, so a single counter document throttles — shard it and sum on read.
13
2. "Why does a Firestore query fail asking for an index?" Probing: composite indexes. Stalls: "The data is missing." Moves up: single fields are indexed automatically, but a multi-field query needs a composite index, and the error contains a link that creates it.
14
3. "Design a Bigtable row key for device readings." Probing: the hotspot. Stalls: "Timestamp first." Moves up: device first then timestamp — a timestamp prefix puts every current write in one contiguous range and on one node.
15
4. "Firestore or Bigtable?" Probing: the fit. Stalls: "Both are NoSQL." Moves up: Firestore for app data with live updates and modest write rates; Bigtable for huge append-heavy time series read by key range, with no secondary indexes at all.
Use cases:firestorebigtablerow-keyhotspotcomposite-index