StarRocks Terminology Explained: Breaking Down Every Acronym

The original report is dense with jargon: MPP, CBO, FE, CN, MoR, 2PC — two dozen or more pieces of jargon in one pot. This glossary untangles them, all hung on one picture: a restaurant that serves only made-to-order answers. You run chain stores and want to ask, at year end, "which distributor in East China sold the most personal-care products?" — throw that question into the restaurant and dishes come out within seconds.

For a sense of scale: a transaction table can accumulate a billion rows a year — printed out, stacked from the first floor to the third. An OLAP engine is the kitchen that can find the answer in that stack within seconds.

1. Three umbrella terms: OLAP, OLTP, MPP

• OLAP (On-Line Analytical Processing): the "ask now, answer now" business model itself. One question scans a wide swath — asking for annual sales means going through the whole year's ledger.
• OLTP (On-Line Transaction Processing): its opposite sibling, handling "one row at a time" — a cashier opens a ticket, one inventory line changes. ERP and POS systems do this. One serves the boss's questions; the other serves the counter's pen.
• MPP (Massively Parallel Processing): multiple woks stir-frying at once. A big question is cut into pieces, ten machines each cook their share, then plates are assembled. When the restaurant scales up, a single stove is doomed.

2. The engine trio: vectorization, CBO, Pipeline

• Vectorized execution: how the math is done. Old engines compute row by row; vectorized engines compute column by column, batch by batch — the CPU consumes a whole group of numbers per instruction. This single change alone often yields several-fold differences.
• CBO (Cost-Based Optimizer): after the order comes in and before cooking starts, an experienced head waiter figures out "which pot first, which two pots can share a stove." Estimates by cost — row counts, filter selectivity, which path requires moving data across machines — and picks the cheapest route. The older alternative is RBO (rule-based optimization), which recites fixed rules without checking conditions.
• Pipeline execution engine: assembly-line work. Data flows forward in small chunks like parts on a conveyor belt, never waiting for a full basket. The belt never stops. Query latency is kept low, and hundreds of concurrent queries run on the belt simultaneously.

3. Architecture terms: FE, BE, CN, and the ledger

• FE (Frontend): the head waiter. Receives SQL, parses, plans, dispatches work. Never cooks — only talks.
• BDBJE (Berkeley DB Java Edition): the replication library the head waiters use to copy each other's ledgers. Its role: the FE group jointly maintains one metadata ledger (where tables live, their schemas), so no single departure loses the books.
• Follower / Observer: two kinds of assistants. Followers each hold a full ledger copy and vote to elect a new leader if the current one falls; Observers copy the ledger but don't vote — they handle extra order-taking (read scaling).
• BE (Backend): the stoves. The machines that actually store and compute data. A restaurant's capacity is measured in stoves.
• tablet: the smallest unit of data movement. A big table is cut into small bricks; each should ideally be 1–10 GB — too big to carry, too small means debris everywhere (metadata explosion).
• Storage-compute separation: the new store format since 3.0. Ingredients go to a central warehouse (object storage — S3/OSS and the like), and stoves become CNs (Compute Nodes) that cook without hoarding, keeping only a local fridge (Data Cache for hot data). Opening a new store requires no ingredient moves — second-level startup; central warehouse storage costs roughly a tenth of local SSD. JD Logistics publicly reported about a 90% storage cost reduction.
• StarOS: the official name for the scheduling, storage-access, and cache-management layer behind storage-compute separation.
• 4.0's File Bundling: small ingredients are packed into big boxes before entering the central warehouse, cutting object-storage API calls by about 90% per official figures.

4. Table models: four ways of keeping books

• Duplicate (detail model): a transaction log. Every row is recorded as-is, never merged. For audit and traceability — a lost row can be reconciled even months later.
• Aggregate model: a summary ledger. Pre-aggregated by key (e.g., distributor × product × day), with measures configured — sum for sales, max for inventory, replace for latest value. Fast to scan, but detail is lost and changing definitions requires rewriting the book.
• Unique (update model): an overwrite ledger. For the same key, a new row covers the old. The old implementation is MoR (merge-on-read) — both versions kept at write time, merged on the fly at query time, making queries slow and blocking predicate pushdown; MoW (merge-on-write) settles old rows at write time instead. (Over at Doris, MoW has been the default since 2.1.) In one line: MoR is lazy bookkeeping that torments auditors — no reason to choose it for new tables.
• Primary Key (PK) model: StarRocks's flagship ledger. The primary key index lives in memory; incoming data checks it first — old rows are deleted and new ones inserted (delete-and-insert), deduplicating on write. The first choice for real-time updates. The cost is obvious: the PK index eats memory, so keep keys short — use integer surrogate keys, not long concatenated strings that blow up memory.
• upsert: portmanteau of update + insert. Modify if present, insert if absent — one instruction, two outcomes.
• partial update: change only certain columns, leave the rest alone. Inventory increments depend on it — refresh just the on-hand quantity column each hour.

5. Speed-up terms: from flipping ledgers to pre-made dishes

• Prefix index: each ledger has a predefined sort order (the sort key); the leading columns are the fastest way to flip through it. If queries always filter by distributor, put distributor first. Set at table design time — hard to change later.
• Bitmap index: for low-cardinality columns — e.g., "business format" with a dozen values like convenience store, supermarket, department store. Each value gets a 0/1 string; the Nth store lights up 1 if it matches. Blazing fast for equality filters.
• Bloomfilter: for point lookups on high-cardinality columns — document numbers, device IDs, millions of distinct values. Its temperament: "no" is always true; "yes" might be a false positive. Used to skip batches that "most likely don't contain it," saving scans.
• BITMAP exact distinct count: for "how many stores had sales" style count distinct, paint each value into a bitmap and count the 1s — an order of magnitude faster than pairwise comparison. The column type must be BITMAP.
• Partitioning: ledgers bound by month; a March query pulls only the March book. Partition pruning is the fulfillment of that promise — with query conditions given, irrelevant books are skipped entirely. TTL (Time To Live): each ledger's shelf life; expired ones are auto-recycled, preventing the warehouse from being choked by prehistoric data.
• Bucketing: within each ledger, rows are hashed by key into different cabinets. Two benefits: multiple clerks searching in parallel, and the same key always lives in the same cabinet (setting up the next term). Rule of thumb for bucket count: stoves × disks per machine × 1 to 2.
• Colocate Join: two tables bucketed by the same key, locked into the same row of cabinets. When reconciling, both cabinets open facing each other — no pushing ingredients across the store on a cart (shuffle-free). The price is constraints: identical bucket counts and bound cabinet positions, decided at table creation.
• Bucket Shuffle Join: during the join, only one table is scattered by key into the other's cabinets — less hauling than all-to-all shuffling.
• Runtime Filter: cleverness in reverse. Before the big table finishes scanning, the join side already knows "only East China matters," and shouts back: "everyone not East China, stop flipping!" Scan volume shrinks on the spot.
• Materialized View (MV): pre-made dishes. Frequently ordered dishes are cooked and plated in advance. Synchronous MVs refresh within the load transaction and handle single tables only; asynchronous materialized views (since 2.4) are far more capable — multi-table joins, scheduled refreshes, even partition-level incremental refresh (redoing only the changed month). Query rewrite is its magic: you order a freshly cooked dish, but the kitchen finds the same dish already plated among the pre-made ones and serves it — you notice nothing, except a much shorter bill time.

6. Loading terms: how goods enter the warehouse

• Stream Load: HTTP bulk receiving. The distributor's daily hand-made report file — one push and it's in.
• Routine Load: a standing subscription. Attach to a Kafka stream and goods unload automatically, nonstop.
• Broker Load: bulk-moving history from data lakes, HDFS, and similar big warehouses.
• Flink Connector: the conveyor belt between the Flink stream engine and StarRocks — the main workhorse for real-time loading.
• 2PC exactly-once (two-phase commit): even if the conveyor loses power, nothing is lost or duplicated. First ask "is everyone ready?" — only when all nod does the ledger record; a mid-flight crash rolls everything back. For inventory numbers, even one duplicate is an incident — this is what prevents it.

7. Miscellany: profile, TPC-DS, external catalog

• profile: a query's medical checkup report, listing time spent at every step. Tuning isn't mysticism — it's reading the report: did partition pruning hit, is the join flowing, did the MV rewrite trigger, is parallelism sufficient.
• TPC-DS: the industry's standardized mock exam (the TPC council's decision-support benchmark; DS = Decision Support), dozens of business-analysis questions that engines line up to take. The official 4.0 claim of ~60% speedup over the previous generation is a score on this exam.
• external catalog: hanging name tags on the ledgers of Iceberg, Hive, and other data lakes so you can read them in-store without moving them. That's how five years of cold detail in the lake gets queried.
• Iceberg: an open table format on object storage — the current standard-bearer of lakehouse architecture.
• ClickHouse: another engine lineage — terrifyingly fast at single-table queries, weaker at joins and high concurrency. Doris: StarRocks's same-origin sibling; they split in 2020 and grew into different trees.

8. Closing

Thirty-odd acronyms, and taken apart it's just this: one front desk, several stoves, four kinds of ledgers, a set of ledger-flipping tricks, and a few loading channels. Next time someone at a review meeting hurls acronyms, ask them to explain in plain words — if they can't, they haven't taken the acronyms apart themselves.

Related terms from earlier posts in the series (ODS/DWD/DWS/DIM, SCD, fact tables) are covered in the plain-language versions of "Data Warehouse Layering" and "Slowly Changing Dimensions (SCD)."