关于TiDB HTAP、TiKV/TiFlash及TiSpark的技术问题咨询

1. TiKV是否足以同时支撑OLTP和OLAP工作负载？ #

TiKV本身是为OLTP优化的分布式存储引擎，低延迟、高并发是它的核心优势。如果OLAP查询量级小、频率低，TiKV可以勉强兼顾，但面对大规模复杂OLAP查询（如多表关联、大聚合）时，会抢占TiKV资源，导致OLTP业务延迟飙升。因此不建议用TiKV单独支撑高负载的混合OLTP+OLAP场景，TiFlash的核心价值就是分流OLAP负载，避免影响OLTP业务。

2. TiKV和TiFlash分别支持的压缩率是多少？ #

• TiKV：默认采用LZ4压缩，压缩率约为3:1到8:1；若开启ZSTD高级压缩，压缩率可达5:1到12:1，但会增加少量CPU开销。
• TiFlash：基于列式存储天生适配高压缩，默认使用ZSTD压缩，压缩率普遍在8:1到20:1之间，数值型、日期型等结构化数据的压缩率甚至能达到30:1。

3. 是否有TiDB针对HTAP工作负载的基准测试数据？ #

有，基于TPC-C（OLTP）+TPC-H（OLAP）混合场景的典型测试数据如下：

• 集群配置为3个TiDB节点、3个TiKV节点、3个TiFlash节点时，OLTP部分可达到纯TiKV集群约90%以上的TPC-C吞吐量，同时OLAP的TPC-H查询延迟比纯TiKV场景低60%-80%；
• 混合负载下，OLTP的P99延迟基本稳定在200ms以内，不会因OLAP查询出现大幅波动。

4. 是否可通过包含TiKV和TiFlash的3副本数据复制实现完整的数据高可用性（HA）？ #

可以。TiDB基于Raft协议实现端到端的HA机制：

• TiKV默认3副本，任意副本故障时，Raft会自动选主并同步数据，保障OLTP服务不中断；
• TiFlash作为TiKV的列式副本，通常采用与TiKV一致的副本数部署，单个TiFlash节点故障时，剩余副本可继续提供OLAP查询；
• 只要集群中存活的副本数超过半数，就不会出现数据丢失或服务不可用的情况。

5. TiSpark与TiFlash的OLAP工作负载基准测试对比数据？ #

针对相同OLAP查询场景（如TPC-H的19条标准查询），二者的核心对比数据如下：

• 查询延迟：TiFlash的延迟普遍比TiSpark（基于TiKV）低50%-90%，大表聚合、多表关联类查询的差距更为显著；
• 吞吐量：TiFlash支持MPP并行查询，高并发OLAP场景下的吞吐量是TiSpark的3-10倍；
• 资源影响：TiFlash查询几乎不占用TiKV的CPU和IO资源，而TiSpark会消耗TiKV资源，可能对OLTP业务造成干扰。

内容的提问来源于stack exchange，提问作者Ajay