最近折腾了一个小项目 https://cryptopricedata.com/ ，主要是提供加密货币的历史 K 线数据（ OHLCV ），供做交易策略、回测或者研究用。目前数据量已经有点上来了，遇到了一些存储和查询性能的问题，想请教下大家的经验。
目前的技术方案： 数据源：从多个交易所拉取 K 线数据，按交易对、时间粒度存储 存储：最开始是用 MySQL ，后来数据量上来后改成了 PostgreSQL + TimescaleDB API 提供：FastAPI + Redis 缓存 目前遇到的问题： 查询性能：对于大量历史数据（比如拉取某个币对过去几年的分钟级 K 线），查询速度不够理想，即使加了索引和分区，某些查询还是会比较慢。 数据更新：K 线数据是不断增量更新的，插入新数据的效率也是个问题。特别是有些交易所有时会补充历史数据，导致需要做去重和合并处理。 存储优化：TimescaleDB 的压缩功能用过，但效果一般。想知道有没有更好的存储结构或者方案？ V 站里做量化或者大规模时序数据存储的朋友，有没有类似的经验？有没有推荐的架构或者数据库方案？欢迎讨论，也欢迎拍砖！ 😃
 |
1
simazilinVV 1 天前
试试 csv 或者时间序列的数据库
|
 |
2
bfjm 1 天前 via iPhone
index file+ data file
|
 |
3
llsquaer 1 天前
没研究过数据库。
不过这 k 线图是时间相关的。可不可以直接自己定义文件，1 秒一个数组（行），顺序写进去。 实际查的时候其实只是找到文件的偏移量去读取。 比如 1741407203 这个时刻的 k 线 实际就是 1741407203 行。 |
 |
4
rust 23 小时 45 分钟前
你多少数据量?
我们有将近 1B 的数据在 MongoDB 跑着,也是从 CEX 下载的数据包存进去的, 用时间范围都是秒查,是不是你的数据库的磁盘性能不够了. |
 |
5
Norsl 22 小时 46 分钟前
上 ClickHouse 试下呢？
|
Select Language