第2章数据库选型对比

数据库选型对比：关系型、NoSQL与专用时序数据库

做金融时序数据库选型，我踩过的坑真不少。记得刚入行那会儿，团队拍脑袋选了MySQL来存高频交易数据，结果三个月后查询慢得像蜗牛爬。今天咱们就聊聊，不同数据库在处理时序数据时，到底谁行谁不行。

核心观点：没有银弹，只有最适合场景的数据库。金融时序数据有三大特征——写多读少、按时间窗口查询、数据量大。选型必须围绕这三点展开。

关系型数据库的痛点：MySQL/PostgreSQL

先说关系型数据库。MySQL和PostgreSQL，说白了是为OLTP场景设计的。你想想看，银行交易系统、用户注册登录，这些场景它们很擅长。但拿来存时序数据？嗯，问题就来了。

痛点一：写入性能瓶颈

金融时序数据每秒可能产生几万甚至几十万条记录。MySQL的B+树索引，每次写入都要更新索引。我在项目中遇到过，单机MySQL每秒写入超过5000条就开始报警了。PostgreSQL好一些，但也好不到哪去。

-- 典型的时序数据表结构
CREATE TABLE trade_ticks (
    symbol VARCHAR(10),
    trade_time TIMESTAMP,
    price DECIMAL(10,4),
    volume BIGINT,
    PRIMARY KEY (symbol, trade_time)
);

-- 插入100万条数据后，查询开始变慢
SELECT * FROM trade_ticks 
WHERE symbol = 'AAPL' 
  AND trade_time BETWEEN '2024-01-01' AND '2024-01-02'
ORDER BY trade_time;

痛点二：数据膨胀严重

关系型数据库的行式存储，对时序数据很不友好。每条记录都存完整的时间戳、标签、字段名。我算过一笔账：同样100GB的原始数据，MySQL存下来要300GB。为什么？因为每行都有额外的元数据开销。

痛点三：时间窗口查询效率低

金融分析经常要查「过去5分钟的最高价」、「今天每分钟的成交量」。这种滑动窗口查询，在关系型数据库里写SQL特别别扭。你试试用窗口函数？性能直接崩掉。

我的建议：如果数据量小于100万条/天，PostgreSQL勉强能用。超过这个量，别犹豫，换方案。

NoSQL数据库的适用性：MongoDB/Cassandra

NoSQL数据库，说白了就是放弃了ACID中的某些特性，换来了扩展性。MongoDB和Cassandra，我都在金融场景里试过。

MongoDB：文档型，灵活但不够专

MongoDB的文档模型，存时序数据确实灵活。你可以把一天的数据塞进一个文档里，查询时一次拉出来。但问题也很明显：

时间范围查询需要建复合索引，否则全表扫描
数据更新频繁时，文档碎片化严重
没有内置的降采样、插值功能

我记得有个项目，用MongoDB存股票行情数据。刚开始还行，数据量到10亿条后，聚合查询动不动就超时。后来我们不得不自己写MapReduce，那叫一个痛苦。

Cassandra：列式存储，写性能强悍

Cassandra的写性能确实牛。它的LSM-Tree结构，写入就是追加日志，理论上可以线性扩展。我测试过，10节点集群每秒能写50万条。

-- Cassandra的时序数据模型
CREATE TABLE stock_ticks (
    symbol text,
    trade_time timestamp,
    price double,
    volume bigint,
    PRIMARY KEY (symbol, trade_time)
) WITH CLUSTERING ORDER BY (trade_time DESC);

但Cassandra有个致命伤：范围查询效率低。它的分区键设计，决定了你只能按symbol查。想查「所有股票在某个时间段的行情」？对不起，得全表扫描。

避坑指南：我曾经用Cassandra做跨品种分析，结果查询延迟从毫秒级变成了秒级。后来才明白，Cassandra适合「已知key查value」的场景，不适合「按时间范围聚合」的场景。

专用时序数据库的优势：InfluxDB/TDengine/ClickHouse

终于说到正主了。专用时序数据库，就是为时序数据量身定做的。它们解决了上面所有痛点。

InfluxDB：老牌时序数据库

InfluxDB的TSM存储引擎，专门优化了时序数据的写入和查询。它的特点：

自动管理数据保留策略（Retention Policy）
内置连续查询（Continuous Query）做降采样
类SQL查询语言，学习成本低

但InfluxDB有个坑：单机版性能有限。我测试过，单机InfluxDB写入峰值大概在10万条/秒。集群版？嗯，开源版不支持，企业版又贵得离谱。

TDengine：国产之光，针对物联网和金融优化

TDengine是我最近两年用得最多的。它的设计理念很直接：一个数据采集点一张表。什么意思？就是每只股票、每个交易品种，单独建一张子表。

-- TDengine的超级表设计
CREATE STABLE trades (
    ts TIMESTAMP,
    price DOUBLE,
    volume BIGINT
) TAGS (symbol VARCHAR(10), exchange VARCHAR(4));

-- 自动创建子表
INSERT INTO trade_aapl USING trades TAGS('AAPL', 'NASDAQ') 
VALUES (now, 150.25, 10000);

这种设计的好处：

写入性能极高，单机轻松破百万条/秒
时间窗口查询快，因为数据按时间有序存储
内置降采样、插值、窗口计算函数

ClickHouse：列式存储，分析型查询的王者

ClickHouse严格来说不是纯粹的时序数据库，但它在时序分析场景表现极好。它的列式存储和向量化执行引擎，让聚合查询快得离谱。

-- ClickHouse的时序数据表
CREATE TABLE trades (
    symbol String,
    trade_time DateTime,
    price Float64,
    volume UInt64
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(trade_time)
ORDER BY (symbol, trade_time);

-- 分钟级聚合查询，10亿条数据秒级返回
SELECT 
    symbol,
    toStartOfMinute(trade_time) AS minute,
    max(price) AS high,
    min(price) AS low,
    sum(volume) AS total_volume
FROM trades
WHERE trade_time >= now() - INTERVAL 1 DAY
GROUP BY symbol, minute;

ClickHouse的缺点：

写入不是强实时，适合批量导入
单条记录更新成本高
对高并发查询支持一般

我的选型建议：

实时行情写入 + 简单查询 → TDengine
复杂分析 + 历史数据 → ClickHouse
中小规模 + 快速部署 → InfluxDB
别用关系型数据库存时序数据，除非数据量极小

知识体系总览

下面这张图，是我梳理的数据库选型决策流程。你可以把它当作一个快速参考。

总结一下

数据库选型没有标准答案。我个人的经验是：先搞清楚你的数据特征和查询模式。是写多读少？还是读多写少？是点查多？还是范围聚合多？

如果你刚开始做时序数据库选型，我建议从TDengine或ClickHouse入手。它们的学习曲线不算陡，社区也活跃。等踩过一些坑，再根据实际场景做调整。

嗯，这一章就聊到这儿。记住一点：别为了省事选关系型数据库存时序数据，后面维护的成本会让你后悔的。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

数据库选型对比：关系型、NoSQL与专用时序数据库

关系型数据库的痛点：MySQL/PostgreSQL

NoSQL数据库的适用性：MongoDB/Cassandra

专用时序数据库的优势：InfluxDB/TDengine/ClickHouse

知识体系总览

总结一下