求助：如何高效存储和查询大规模加密货币 K 线数据？

[Noah1984]

最近折腾了一个小项目 https://cryptopricedata.com/ ，主要是提供加密货币的历史 K 线数据（ OHLCV ），供做交易策略、回测或者研究用。目前数据量已经有点上来了，遇到了一些存储和查询性能的问题，想请教下大家的经验。

目前的技术方案： 数据源：从多个交易所拉取 K 线数据，按交易对、时间粒度存储 存储：最开始是用 MySQL ，后来数据量上来后改成了 PostgreSQL + TimescaleDB API 提供：FastAPI + Redis 缓存 目前遇到的问题： 查询性能：对于大量历史数据（比如拉取某个币对过去几年的分钟级 K 线），查询速度不够理想，即使加了索引和分区，某些查询还是会比较慢。 数据更新：K 线数据是不断增量更新的，插入新数据的效率也是个问题。特别是有些交易所有时会补充历史数据，导致需要做去重和合并处理。 存储优化：TimescaleDB 的压缩功能用过，但效果一般。想知道有没有更好的存储结构或者方案？ V 站里做量化或者大规模时序数据存储的朋友，有没有类似的经验？有没有推荐的架构或者数据库方案？欢迎讨论，也欢迎拍砖！ 😃

[simazilinVV]

试试 csv 或者时间序列的数据库

[bfjm]

index file+ data file

[llsquaer]

没研究过数据库。
不过这 k 线图是时间相关的。可不可以直接自己定义文件，1 秒一个数组（行），顺序写进去。
实际查的时候其实只是找到文件的偏移量去读取。 比如 1741407203 这个时刻的 k 线 实际就是 1741407203 行。

[rust]

你多少数据量?
我们有将近 1B 的数据在 MongoDB 跑着,也是从 CEX 下载的数据包存进去的, 用时间范围都是秒查,是不是你的数据库的磁盘性能不够了.

[Norsl]

上 ClickHouse 试下呢？

[metmit]

写多、更新多的情况，用底层是 lsm-tree 的 db 更合适吧？比如 leveldb rocksdb tidb oceanbase ；
查询上，有名的几个关系型 db 应该差距都不太大，除了 mysql （并行查询 join 支持的都不行）