핵심 요약
- An HTAP database runs transactional writes and analytical queries against the same live data, with no ETL pipeline in between.
- TiDB pairs two storage engines under one SQL layer: TiKV for row-based transactions, TiFlash for columnar analytics.
- The optimizer picks the engine per query. Point lookups go to TiKV, large aggregations go to TiFlash, and the SQL never changes.
- Trip.com runs real-time settlement and reporting on this model, removing the pipeline that used to sit between the two.
An HTAP (Hybrid Transactional and Analytical Processing) database runs transactional writes and analytical queries against the same live data, on the same system, without moving that data through an ETL pipeline first. 티DB implements HTAP with two storage engines under one SQL layer: TiKV handles transactional reads and writes, TiFlash handles analytical queries, and TiDB keeps the two in sync in real time rather than through a nightly batch job.
How a Query Gets Routed: TiKV vs TiFlash
When an application writes a row, that write lands in TiKV, TiDB’s row-based storage engine, and commits with the same consistency guarantees as any transactional database. The write then replicates to TiFlash, TiDB’s columnar storage engine, through the Multi-Raft Learner protocol, typically within a few seconds.
When a query arrives, TiDB’s optimizer decides where to send it. Point lookups and small-range scans go to TiKV. Large aggregations and full-table scans go to TiFlash, where the columnar layout reads far fewer bytes off disk to answer the same question. The application never names the engine: the same SQL statement reaches the analytical engine automatically whenever the optimizer calculates that route is faster.
Seeing the Routing Decision: A Worked Example
The routing behavior above is observable rather than theoretical. Give a table a TiFlash replica, then read the execution plan for two different queries against it.
Start by adding the replica and confirming it is available before running anything against it. A replica that is still building will not receive queries.
ALTER TABLE orders SET TIFLASH REPLICA 1;
SELECT TABLE_NAME, REPLICA_COUNT, AVAILABLE, PROGRESS
FROM information_schema.tiflash_replica
WHERE TABLE_SCHEMA = 'shop' AND TABLE_NAME = 'orders';
ANALYZE TABLE orders;
SET SESSION tidb_allow_mpp = 1;Now compare two queries. The first fetches one row by primary key, the access pattern that suits row storage.
EXPLAIN SELECT * FROM orders WHERE order_id = 84213;id estRows task operator info
--------------------------------------------------------
Point_Get_1 1.00 root table:orders, handle:84213Plan output is abridged for readability. A point lookup resolves against TiKV; TiFlash never enters the plan.
The second aggregates across the whole table, the access pattern that suits columnar storage.
EXPLAIN SELECT region, COUNT(*) FROM orders GROUP BY region;id task operator info
-----------------------------------------------------------
TableReader_31 root data:ExchangeSender_30
└─ExchangeSender_30 mpp[tiflash] ExchangeType: PassThrough
└─Projection_26 mpp[tiflash] Column#4
└─HashAgg_27 mpp[tiflash] group by: region
└─ExchangeReceiver_29 mpp[tiflash]
└─ExchangeSender_28 mpp[tiflash] ExchangeType: HashPartition
└─HashAgg_9 mpp[tiflash] group by: region
└─TableFullScan_25 mpp[tiflash] table:ordersAbridged and illustrative: operator IDs, row estimates, and column widths vary with your data and version. On versions before MPP, the task column reads batchCop[tiflash] instead of mpp[tiflash].
Three things in that second plan are worth reading carefully. The task column says mpp[tiflash], so every operator below the reader runs on TiFlash nodes rather than TiKV. TableFullScan scans 4.2 million rows without anyone worrying about it, because columnar storage reads only the region column off disk instead of every column in every row. And the plan splits into two fragments at the ExchangeSender boundaries: one doing a first-stage aggregation local to each node, one combining those partial results.
Nothing in either SQL statement named an engine. The optimizer chose, using table statistics and cost estimates, which is why ANALYZE matters before you judge a routing decision. If you want to confirm what a query would do on one engine only, constrain the session rather than rewriting the query.
SET SESSION tidb_isolation_read_engines = 'tidb,tiflash';
EXPLAIN SELECT region, COUNT(*) FROM orders GROUP BY region;That is a diagnostic, not a production setting. In normal operation the point is that the same application, issuing the same SQL, reaches whichever engine answers it faster.
What HTAP Replaces: The ETL Pipeline
Without HTAP, running analytics on transactional data usually means a separate OLAP warehouse that a batch ETL job feeds hourly or nightly. That pipeline costs you three things:
- Staleness, so the dashboard always trails production by hours.
- Duplicated infrastructure, so you run and pay for two databases.
- An added failure point, because a broken ETL job goes stale quietly rather than loudly.
TiDB’s real-time TiFlash replication removes all three. One cluster holds one copy of the data, replicated for two access patterns, with no batch job left to break.
Verified Result: Trip.com
Trip.com adopted TiDB to speed up real-time data processing and financial settlement, workloads that need transactional accuracy and near-instant analytical visibility on the same data. Running both on TiDB’s HTAP architecture removed the separate settlement and reporting pipeline that would otherwise sit between the transactional system and the numbers its finance teams need to see.
Two Engines, One Source of Truth
An HTAP database removes the pipeline between what happened and what it means. It does that not by making one engine do two jobs badly, but by running two engines that stay in sync automatically, each shaped for the access pattern it serves.
Start with a free TiDB Cloud Starter cluster to test HTAP query routing against your own schema and see which of your queries the optimizer sends to TiFlash.
HTAP Database FAQs
What Does HTAP Stand For, and What Problem Does It Solve?
HTAP stands for Hybrid Transactional and Analytical Processing. It solves the staleness and duplicated-infrastructure problem created by running a separate OLTP database and OLAP warehouse connected by a pipeline. In an HTAP system, transactions and analytics run against the same live data on one system.
Does an HTAP Database Sacrifice Transactional Performance for Analytics?
In TiDB’s design, no. TiKV carries the transactional load independently of TiFlash, and analytical queries route to TiFlash, so the two workloads never compete for the same storage engine. Replication to TiFlash runs asynchronously, so it does not block transactional writes.
How Is HTAP Different From Running Analytics on a Read Replica?
A read replica adds read capacity but keeps row-based storage, which stays slow for large aggregations no matter how fresh the data is. TiFlash adds a different storage engine entirely: columnar, built for analytical scan patterns. The difference is which access pattern the engine serves, not how much read capacity you add.