A plain-language glossary unpacking the acronyms in StarRocks research reports. The original article ties everything to one image: a restaurant that only serves made-to-order answers—you ask "which distributor in East China sold the most personal-care products," and the dish comes out in seconds.
1. Three umbrella terms
- OLAP (On-Line Analytical Processing): the "ask now, answer now" business model itself—one query scans a huge range of data.
- OLTP (On-Line Transaction Processing): its opposite sibling, handling "one row at a time"—POS terminals, ERP transactions.
- MPP (Massively Parallel Processing): many stoves cooking at once. A big query is split into chunks and processed across machines in parallel.
- Vectorized execution: computes in column batches rather than row by row, letting the CPU process a group of numbers per instruction—often a multiple-fold speedup by itself.
- CBO (Cost-Based Optimizer): a seasoned head waiter who estimates costs (row counts, filter selectivity, cross-machine data movement) and picks the cheapest plan—unlike the rule-based RBO.
- Pipeline execution engine: data flows forward in small chunks on a conveyor belt, keeping latency low and supporting hundreds of concurrent queries.
- FE (Frontend): the head waiter—parses SQL, plans, and dispatches work.
- BDBJE (Berkeley DB Java Edition): the replication library FEs use to share the metadata ledger.
- Follower / Observer: Followers hold ledger copies and can vote for a new leader; Observers only replicate for read scaling.
- BE (Backend): the stoves—machines that actually store and compute data.
- Tablet: the smallest unit of data movement; a large table is cut into bricks, ideally 1–10 GB each.
- Storage-compute separation (since 3.0): data lives centrally in object storage (S3/OSS); compute nodes (CN, Compute Node) only compute, keeping a local Data Cache. New compute scales in seconds, and central storage costs roughly a tenth of local SSD. JD Logistics reports ~90% storage cost reduction.
- StarOS: the official name for the scheduling, storage access, and cache management layer behind this architecture.
- File Bundling (in 4.0): small files are packed into larger ones before entering object storage, cutting API calls by roughly 90% (official figure).
- Duplicate: a raw ledger—every row kept forever, ideal for audit.
- Aggregate: pre-summarized by key with per-column functions (sum, max, replace); fast to read, but details are lost.
- Unique: same key overwrites the old row. The old implementation is MoR (merge-on-read)—slow queries, no predicate pushdown; MoW (merge-on-write) resolves old values at write time and is the modern choice.
- Primary Key (PK): StarRocks' flagship model. The PK index lives in memory; new data does delete-and-insert, deduplicating on write. Best for real-time updates—but keep keys short (use integer surrogate keys).
- upsert: update + insert; partial update: modify only some columns.
- Prefix index: the sorted leading columns of a table give the fastest lookup path—chosen at table design time.
- Bitmap index: for low-cardinality columns; equality filters become bit operations.
- Bloomfilter: for high-cardinality point lookups; "no" is certain, "yes" may be a false positive.
- BITMAP exact distinct count: an order of magnitude faster than row-by-row comparison.
- Partitioning / partition pruning / TTL: bind ledgers by month; irrelevant partitions are skipped; expired data is auto-discarded.
- Bucketing: hash(key) distribution across buckets for parallelism; rule of thumb: nodes × disks × 1–2.
- Colocate Join: two tables bucketed by the same key co-located, eliminating shuffle (with bucket-count constraints); Bucket Shuffle Join shuffles only one side.
- Runtime Filter: mid-query, the join side tells the big table "only East China rows—skip the rest."
- Materialized View (MV): pre-cooked dishes. Synchronous MVs refresh in the load transaction (single table); asynchronous MVs (since 2.4) support multi-table joins, scheduled refreshes, and partition-level incremental refresh. Query rewrite serves the precomputed result transparently.
- Stream Load: HTTP batch push (e.g., daily manual files).
- Routine Load: persistent Kafka subscription, auto-unloads.
- Broker Load: bulk history loads from data lakes or HDFS.
- Flink Connector: the conveyor belt between Flink and StarRocks.
- 2PC exactly-once (two-phase commit): all-or-nothing commits—no loss, no duplicates, essential for inventory numbers.
- Profile: a per-step timing report for each query—tuning means reading it (partition pruning hits, join order, MV rewrite hits, parallelism).
- TPC-DS: the industry's standardized decision-support benchmark; the 4.0 release claims ~60% faster than the previous generation on it.
- External catalog: query Iceberg/Hive data lakes in place, no copying.
- Iceberg: the leading open table format on object storage. ClickHouse excels at single-table speed but struggles with joins and high concurrency; Doris is StarRocks' sibling project, split in 2020.
2. The engine trio
3. Architecture: FE, BE, CN, and the ledger
4. Table models: four bookkeeping styles
5. Speed-up techniques
6. Loading data
7. Miscellany
8. Wrap-up
Thirty-odd acronyms boil down to: a front desk, some stoves, four ledgers, lookup tricks, and loading lanes. Related terms (ODS/DWD/DWS/DIM, SCD, fact tables) are covered in the series' companion posts on warehouse layering and slowly changing dimensions.