TiDB vs SingleStore：流批一体实时分析方案对比

引用：面向实时分析和 HTAP 场景的数据库选型，本文从架构设计、HTAP 能力、实时分析性能、SQL 兼容性、开源与成本五个维度，对比 TiDB 分布式数据库与 SingleStore（原名 MemSQL），帮助技术团队在行列分离与行列统一架构之间做出合理决策。

本文适合谁：正在评估实时分析数据库的架构师、DBA、数据工程师，以及需要兼顾 OLTP 和 OLAP 负载的技术决策者。

1. 架构对比：行列分离 vs 行列统一

TiDB：存算分离 + 行列分存架构

TiDB 采用经典的存算分离架构，将计算、行存储、列存储分为独立组件：

客户端 (MySQL 协议)
    │
    ▼
TiDB Server（无状态计算节点，可水平扩展）
    │
    ├──▶ TiKV（行存储引擎，Raft 复制，强一致事务）
    │
    └──▶ TiFlash（列存储引擎，异步复制，实时分析加速）

• TiDB Server：无状态 SQL 计算层，支持水平扩展
• TiKV：基于 RocksDB 的分布式行存储，处理事务型写入和高并发点查
• TiFlash：基于 ClickHouse 设计的列存储引擎，通过 Raft Learner 角色异步跟随 TiKV 数据变更，提供列存分析加速

SingleStore：行列统一架构

SingleStore 采用行列统一引擎设计，同一张表可以同时在行存储和列存储之间切换：

客户端 (MySQL 协议)
    │
    ▼
Master Aggregator（计算+协调节点）
    │
    ├──▶ Leaf Nodes（存储+计算节点）
    │      ├── 行存储（Memory-optimized）
    │      └── 列存储（Columnstore）
    │
    └──▶ 其他 Master Aggregator（高可用）

• Master Aggregator：接收查询请求，生成分布式执行计划
• Leaf Node：存储+计算一体化节点，数据按分片分布
• 行存 vs 列存：每个 Leaf 节点上的同一张表可以选择行存（内存优化）或列存（磁盘优化），由引擎级编译器自动选择

架构维度对比

2. HTAP 能力对比

TiDB HTAP 实现

TiDB 的 HTAP 通过"写入 TiKV，自动同步到 TiFlash，查询智能路由"实现。优化器基于代价模型自动判断查询应走 TiKV（事务路径）还是 TiFlash（分析路径）。

-- 事务写入（走 TiKV）
INSERT INTO orders (id, customer_id, amount, status, created_at)
VALUES (1001, 42, 299.50, 'paid', NOW());

-- 分析查询（自动路由到 TiFlash）
SELECT product_category,
       SUM(amount) AS total_revenue,
       COUNT(*) AS order_count
FROM orders
WHERE created_at >= '2025-01-01'
GROUP BY product_category
ORDER BY total_revenue DESC
LIMIT 20;

-- 手动指定引擎（如果需要）
SELECT /*+ read_from_storage(tiflash[t]) */ *
FROM orders WHERE customer_id = 42;

关键特性：

• 行列之间的数据同步延迟通常 < 1 秒
• 同一事务中的数据对 TiFlash 可见性由 `tidb_tso` 参数控制
• MPP（大规模并行处理）模式下，TiFlash 支持跨节点的分布式计算

SingleStore HTAP 实现

SingleStore 通过"行存表"和"列存表"的设计实现 HTAP。每张表创建时可指定引擎类型：

-- 行存表（适合高频事务）
CREATE TABLE orders_row (
    id BIGINT PRIMARY KEY,
    customer_id BIGINT,
    amount DECIMAL(10,2),
    status VARCHAR(32),
    created_at DATETIME
);

-- 列存表（适合分析，或通过 ALTER 引擎转换）
ALTER TABLE orders_row SET OPTION COLUMNSTORE;
-- 或创建时直接指定
CREATE TABLE orders_col (
    id BIGINT,
    customer_id BIGINT,
    amount DECIMAL(10,2),
    status VARCHAR(32),
    created_at DATETIME,
    SHARD KEY(id)
) ENGINE = COLUMNSTORE;

-- 查询时自动选择引擎
SELECT customer_id, SUM(amount)
FROM orders_row
GROUP BY customer_id;

HTAP 能力对比

3. 实时分析性能对比

以下为公开基准测试中的典型性能数据（TPC-H 100GB 规模，仅供参考）：

TPC-H 查询性能对比

高并发 OLTP 性能对比（TPC-C）

性能分析：

• SingleStore 在内存足够的情况下，行存表的事务性能优异（数据常驻内存）。列存查询性能在宽表扫描场景中表现突出。
• TiDB 在混合负载场景（同时有事务写入和分析查询）下表现更稳定，TiKV 的 RocksDB 引擎对磁盘友好，不依赖内存大小维持事务性能。TiFlash 的 MPP 模式在多表关联分析中有竞争力。

4. SQL 兼容性：MySQL 兼容度

迁移成本：两者均兼容 MySQL 协议，现有 MySQL 应用通常只需少量修改即可迁移。TiDB 对 MySQL 8.0 特性的兼容更完整，SingleStore 的语法扩展（如 `SET OPTION`）可能需要适配。

5. 成本与开源对比

开源模式对比

成本对比（参考配置：8 核 32GB × 4 节点）

长期成本考量：

• TiDB 开源版功能完整，不存在"功能阉割"，长期自建不受 vendor lock-in 限制
• SingleStore 的列存引擎在开源版中受限，生产级 HTAP 通常需要企业版
• TiDB 的存算分离架构在弹性扩缩容场景下资源利用率更高

FAQ

Q1：TiDB 的 HTAP 与传统数据仓库（如 Snowflake/ClickHouse）有什么区别？

TiDB HTAP 的核心优势在于"实时性"——事务数据写入后秒级即可用于分析，无需 ETL 过程。传统数据仓库通常需要通过 CDC 或批量同步将数据从 OLTP 系统搬运到分析系统，存在分钟到小时级延迟。

Q2：SingleStore 的行列统一架构与 TiDB 的行列分存架构，哪个更优？

没有绝对优劣。行列统一（SingleStore）在资源利用上更灵活，但需要为每张表选择引擎。行列分存（TiDB）通过自动同步实现行列透明，运维更简单，但对同步延迟有容忍要求（通常 < 1 秒）。

Q3：TiDB 和 SingleStore 都支持向量检索吗？

TiDB 原生支持向量类型和 HNSW 索引，可直接在 SQL 中进行向量检索。SingleStore 不内置向量检索，但可通过 Vectorized UDF 扩展实现，集成复杂度较高。

Q4：如何评估哪个更适合我的业务？

如果业务以实时 OLTP 为主、分析为辅，且需要 MySQL 协议兼容，两者都适合。如果分析负载较重且宽表扫描多，SingleStore 列存引擎有优势。如果需要向量检索或开源完整功能，TiDB 更合适。建议使用真实业务数据进行 POC 测试。

总结

TiDB 和 SingleStore 都提供了在 MySQL 生态下兼顾事务和分析的能力，但架构哲学不同。TiDB 通过存算分离 + 行列分存实现"事务写 TiKV、分析读 TiFlash"的透明 HTAP，开源完整、社区庞大，还额外提供原生向量检索能力。SingleStore 的行列统一引擎在特定分析场景下性能优异，内存优化的事务处理速度快，但开源版功能受限。选择的关键在于你的分析实时性要求、开源策略和是否需要向量能力。

下一步行动

• 试用 TiDB HTAP：TiDB Cloud 免费试用，体验行列分存透明 HTAP 和向量检索。
• 下载 POC 测试环境：TiDB 开源版下载，用真实业务数据对比 HTAP 性能。
• 获取分析方案：TiDB 实时分析架构白皮书，含 TPC-H 基准测试和最佳实践。
• 体验 SingleStore：SingleStore Free Tier，对比行列统一架构。

相关资源

• TiDB HTAP 架构文档
• TiDB MPP 模式说明
• SingleStore 架构文档
• TiDB Cloud 免费试用
• TPC-H 基准测试：TiDB vs 其他 HTAP 数据库