股票数据本地化存储实战JSON、数据库与列式存储的方案对比如果你打算把股票数据存到本地第一件事就是选型。我在这条路上踩过不少坑从最初的纯JSON文件存储到后来的SQLite数据库再到现在用的列式数据库每一步都有故事。这篇文章我把三种方案在股票数据场景下的优劣做一个详细对比包括写入性能、查询性能、维护成本、适用场景等维度并用实际数据做基准测试帮你少走弯路。先明确股票数据的特点在讨论存储方案之前得先理解股票数据的独特性。它和普通的业务数据不一样有几个鲜明的特征一是数据量随时间线性增长。每只股票每个交易日产生一条日K线A股5000多只股票每年250个交易日一年就是125万条记录。如果加上分钟级别数据量会更大。二是写入模式以追加为主。K线数据基本只会增加很少修改。实时行情虽然是覆盖式更新但历史数据是追加写入。三是查询模式以聚合和扫描为主。分析时很少按单条记录查更多的是按时间范围、按行业、按指标做聚合运算求均值、求和、分组统计这时候列式存储的优势就体现出来了。四是时间序列特征明显。股票数据天然带有时间维度按日期分表或按日期分区是常见的做法。理解了这些特点再来看三种存储方案的对比。方案一JSON文件存储这是我最早用的方案。每只股票一个JSON文件存放在按日期组织的目录里。比如data/daily/20260810/600519.json文件内容是当天的行情数据。{dm:600519,mc:贵州茅台,cjsj:20260810,open:1680.00,high:1720.50,low:1675.00,cjjg:1715.80,cjl:3500000,amount:6005000000}JSON方案的优点是简单直观不需要任何数据库依赖读写用标准库的json模块就行。文件备份和迁移也很方便直接拷贝目录。我的第一版原型用的就是这个方案半天就搞定了。但很快就遇到了问题。第一个问题是查询。比如我想查贵州茅台2024年全年的收盘价需要遍历250个JSON文件每个文件都要打开、解析、提取字段跑一次要好几秒。如果要按行业统计所有白酒股的平均成交量那简直是灾难——要打开几千个文件做几千次JSON解析。第二个问题是数据一致性。JSON文件没有事务支持如果在写入过程中程序崩溃可能产生半写的文件。我遇到过这种情况某次批量更新跑到一半重启了导致部分股票当天的数据缺失排查起来很麻烦。第三个问题是空间效率。JSON的文本格式非常冗余比如字段名cjjg在每个文件里都要存一遍。我测了一下同样的数据量JSON占用的空间是二进制格式的3到5倍。方案二SQLite数据库从JSON切换到SQLite是一个自然的选择。SQLite是单文件数据库支持标准SQL零部署非常适合个人项目和小团队。CREATETABLEkline(dmTEXTNOTNULL,cjsjTEXTNOTNULL,cjjgREAL,cjlREAL,PRIMARYKEY(dm,cjsj));CREATEINDEXidx_kline_cjsjONkline(cjsj);SQLite的优势非常明显。首先是查询能力用SQL做聚合、排序、分组都很方便。比如查贵州茅台2024年全年收盘价一行SQL就搞定SELECTcjsj,cjjgFROMklineWHEREdm600519ANDcjsjBETWEEN20240101AND20241231ORDERBYcjsj;其次是事务支持批量写入时用BEGIN/COMMIT包裹要么全部写入要么全部回滚数据一致性有保障。第三是空间效率内部用二进制存储比JSON小很多。我测了同样5000只股票一年日K线的数据JSON约45MBSQLite约12MB压缩比接近4:1。但SQLite也有局限。最主要的是并发能力写入操作是串行的多个进程同时写入会锁库。对于我们这种场景每天定时批量写入问题不大但如果需要高频实时写入行情数据就会遇到瓶颈。另一个问题是分析性能。当数据量达到百万级后复杂的聚合查询会变慢。比如要计算全市场所有股票过去一年的平均换手率SQLite需要扫描全表耗时可能在秒级。方案三列式存储DuckDB为了解决分析性能的问题我开始调研列式存储。列式数据库的核心思想是数据按列存储而不是按行存储这样在做聚合查询时只读需要的列IO效率大幅提升。我选择了DuckDB它和SQLite一样是嵌入式数据库零部署但内部是列式架构。importduckdb connduckdb.connect(stock.duckdb)conn.execute( CREATE TABLE kline ( dm VARCHAR, cjsj VARCHAR, cjjg DOUBLE, cjl DOUBLE ) )conn.execute(CREATE INDEX idx_cjsj ON kline(cjsj))DuckDB的查询性能确实惊人。同样的全市场聚合查询SQLite要3秒DuckDB只需要0.2秒。而且DuckDB支持向量化计算在做因子计算比如对每只股票求过去20天的移动平均时速度比SQLite快一个数量级。DuckDB的另一个优点是和Python生态的集成非常好直接支持pandas DataFrame的读写做数据分析时可以无缝衔接。不过DuckDB也有不足。一是写入性能由于是列式存储单行写入效率较低适合批量写入。二是生态相对年轻文档和社区资源不如SQLite丰富。三是对于高频小更新的场景比如实时行情逐笔写入列式存储不是最优选择。基准测试三种方案的真实较量说了这么多不如直接上数据。我用全市场5000只股票、2023-2025共3年的日K线数据做了基准测试。数据总量约375万条记录5000股 × 250天/年 × 3年。测试环境是Windows 11Python 3.11SQLite 3.43DuckDB 1.1。JSON用的是标准json模块。测试一写入性能测试方法将375万条K线数据写入空库记录总耗时。JSON方案采用每个股票一个文件并行写入8线程耗时约180秒。SQLite采用批量INSERT用BEGIN/COMMIT包裹耗时约45秒。DuckDB采用批量INSERT耗时约30秒。方案写入耗时单条平均JSON并行180秒480μsSQLite45秒120μsDuckDB30秒80μs测试二单股时间范围查询测试方法查询贵州茅台3年的日K线约750条记录。JSON遍历750个文件逐个解析提取字段耗时约3.2秒。SQLite带索引的范围查询耗时约15ms。DuckDB同样的查询耗时约5ms。方案查询耗时JSON3200msSQLite15msDuckDB5ms测试三全市场聚合查询测试方法计算每个行业的平均收盘价、平均成交量。JSON需要遍历所有文件、解析、提取、分组、聚合耗时超过60秒实际上我没等完。SQLite用SQL的GROUP BY耗时约2.8秒。DuckDB同样的SQL耗时约0.15秒。SELECThy,AVG(cjjg),AVG(cjl)FROMklineJOINstock_infoONkline.dmstock_info.dmWHEREcjsjBETWEEN20230101AND20251231GROUPBYhy;方案聚合查询耗时JSON60秒SQLite2.8秒DuckDB0.15秒测试四存储空间同样375万条数据JSON文件约168MBSQLite约42MBDuckDB约38MB如果用Parquet格式存储压缩后约12MB选型建议综合以上测试结果给出我的选型建议如果你是纯新手或者只是做一些简单的单股票分析JSON方案可以先用起来快速验证想法。但要注意控制数据量建议按日期分目录避免单个目录文件过多。如果你是个人开发者或小团队需要做全市场的数据分析SQLite是最佳选择。它的性能在大部分场景下够用而且零运维成本。我的建议是按年分库比如stock_2023.db、stock_2024.db避免单库过大。如果你有更高的分析需求比如需要频繁做跨周期、跨行业的聚合运算或者需要做因子回测DuckDB是更好的选择。它的列式架构在分析型查询中优势明显而且和Python生态的集成非常顺畅。我的实际做法是混合使用历史K线用DuckDB存储方便做复杂分析实时行情用SQLite方便快速查询基础信息股票列表、行业分类用JSON文件方便配置管理。这样各取所长覆盖不同的使用场景。最后说一点存储方案不是一成不变的。我自己的路径是JSON → SQLite → DuckDB每一步都是因为需求推动的。不用一开始就追求最优解先用起来当现有方案遇到瓶颈时再升级。对于股票数据存储来说够用比完美更重要。接口说明接口路径用途核心参数核心返回字段base/gplist获取全市场股票列表-dm, mc, hy, ssrqtime/real/{dm}获取实时行情dm股票代码f43(现价), f47(成交量), f58(时间), f169(方向)time/history/trade/{dm}/{level}获取历史K线dm代码, level周期klines(时间,开,收,高,低,量)time/f10/fi/{dm}获取财务指标dm股票代码营收, 净利润, ROE等time/real/trace/l2sign/{dm}获取L2指标dm股票代码ddx, ddy, ddz, ddftime/real/trace/onebyone/{dm}获取逐笔交易dm股票代码cjsj, cjjg, cjl, jyzdtime/zijin/zlzjzs/{dm}获取资金走势dm股票代码zlJlr, zlJlb, shJlbtime/zijin/zjlrqs/{dm}获取资金趋势dm股票代码f5MinZlJe等time/data/longhubang获取龙虎榜数据日期营业部, 买入金额, 卖出金额time/data/bshgt获取北向资金数据日期沪股通, 深股通净流入资料参考ig50.com