MSD (Micro Strategy Depot) 是一款专为金融量化分析优化的时序数据库。它放弃了传统数据库“重查询、轻传输”的架构，转而将 “数据检索带宽” 与 “分析工具集成度” 作为核心设计指标。
在金融量化研究中，研究员的时间往往浪费在等待数据从数据库加载到 Python 内存的过程中。
传统痛点：通用数据库（如 MySQL, InfluxDB）在 Python 侧的瓶颈在于 Binary -> Objects -> DataFrame 的转换。即使底层 C++ 引擎再快，逐行解析字节流并封装为 Python 对象的过程也会消耗大量 CPU 并产生频繁的内存分配。
MSD 的解法：“计算就绪”的整装配送。MSD 将数据以与 NumPy 内存布局完全一致的二进制格式存储与传输。查询结果直接映射为 numpy.ndarray，实现从磁盘到 DataFrame 的**零解析（Zero-Parsing）**加载。
“对于金融量化分析来说，快速将给定标的的数据获取到 numpy, pandas 或 polars 等库中，可能比复杂的 SQL 查询能力更为重要。”
- 算法复杂性：量化交易算法通常涉及复杂的统计模型、信号处理和机器学习技术。这些逻辑如果用标准 SQL 表达，不仅极其困难，往往也效率低下。
案例：计算全市场 5000 只股票的“动量因子”并按波动率归一化排名。在 SQL 中，这需要极高消耗的窗口函数和多层嵌套；而在 pandas 中，仅需
df.pct_change().rolling().std()等几行向量化代码即可完成。更不用说像 GARCH 模型或 LSTM 输入预处理这种根本无法用 SQL 完成的任务。 - 工具生态：现代量化技术栈高度依赖 Python 的数据科学生态。pandas and polars 提供了向量化操作和极其丰富的 API，在回测和策略研究方面远胜于 SQL。
案例：使用
scikit-learn进行市场状态聚类，或使用Ta-Lib计算复杂技术指标。这些标准化的量化库在 Python 中触手可及，但在数据库内部完全缺失。 - 瓶颈所在：量化研究中的主要瓶颈往往不在于 查找 数据，而在于将数据从数据库 移动 到应用程序内存中。通用数据库往往为了支持并发 SQL 查询而牺牲了原始吞吐量，其协议开销和解析逻辑对于量化应用来说大多是冗余的。
_案例：对全市场 10 年的分钟线数据进行多因子回测。如果从数据库读取数据需要 1 小时，而策略计算只需 10 分钟，那么 85% 的时间都浪费在等待数据上。强大的计算硬件很容易得到，数据获取的阻塞则浪费了这些算力。
MSD 通过将“数据检索带宽”作为一等公民来解决这个问题。
以下基准测试使用典型的金融数据集（日线数据），对比了 MSD 与一款领先的通用时序数据库（TDEngine）。
测试的核心目的并非证明“谁更快”，而是展示“通用架构”与“专用架构”在量化场景下的适用性差异。
- 通用 TSDB 的逻辑：为了保证通用性（IoT、监控等），TSDB 采用标准的 SQL 协议，客户端收到的是通用的字节流，必须在 Python 端进行繁重的解析和内存分配才能转为 DataFrame。
- MSD 的逻辑：专为量化设计，将“构建 DataFrame”视为数据库协议的一部分。数据在传输前就已经按“计算就绪”的格式组织，极大地缩短了从“收到数据”到“开始计算”的路径。
- 数据：100,000,000 行 OHLCV 数据（Ts, Open, High, Low, Close, Volume, Amount）。
- 格式：CSV, DataFrame。
- 硬件：CNB.cool 云端开发环境，8 vCPU, 16 GB RAM, 高性能 SSD。
- 基准脚本：
- MSD: 使用原生 Python 客户端 (
msd_client.py)，完整包含了DataFrame 直接写入、CSV 导入以及查询并构建 DataFrame 的全链路耗时。 - TDEngine:
- Native Tools: 使用官方 C 语言性能测试工具
taosBenchmark，可视为理论极限吞吐量。 - Python Driver: 使用官方 Python 驱动 (
tsdb_client.py)，模拟真实量化研究员的日常使用场景。
- Native Tools: 使用官方 C 语言性能测试工具
- MSD: 使用原生 Python 客户端 (
| 操作 | MSD 速度 (rows/sec) | TSDB 理论极限 (Native) | TSDB 真实体验 (Python Driver) |
|---|---|---|---|
| 写入 (Insert CSV) | ~5,234,812 | ~2,653,434 | - |
| 写入 (Insert DataFrame) | ~8,734,969 | - | - |
| 查询 (全量获取) | ~7,844,235 | ~4,395,874 | ~193,557 |
> [!NOTE]
> 基准数据来源：results/result.txt (2025-12-26)
-
存储与持久化 (Storage & Durability)：
- MSD 后端基于调优过的 RocksDB。
- 采用 Chunk 存储策略：RocksDB 中的一个 Key 对应多个时间点的记录块 (Chunk)。
- 高吞吐写入：8.7M rows/s 的写入速度得益于这种分块设计——数据首先在内存中聚合，只有当 Chunk 满或触发 flush 策略时才会落盘。这在保证了极高吞吐量的同时也通过 WAL 提供了标准的数据持久化保证。
-
协议与零拷贝 (Protocol & Zero-Copy)：
- MSD 的查询接口直接返回 numpy.ndarray。
- MSD 的二进制插入接口直可以从
pandas.DataFrame或polars.DataFrame转换为numpy.ndarray后直接写入，几乎不涉及内存分配与拷贝。 - 得益于内存布局的对齐，从
numpy.ndarray转换为pandas.DataFrame或polars.DataFrame几乎是 零解析（Zero-Parsing/Zero-Deserialization） 的。 - 相比之下，传统数据库驱动通常需要经过
Binary Socket -> Python Objects (List/Dict) -> Pandas的多次内存分配与拷贝，这是主要的性能杀手。
结论与定位： 我们承认，在需要复杂流计算或生产级风控的场景下，支持 SQL 和流式引擎的数据库（TDengine 等）具有不可替代的优势。
但在 量化研究与回测 (Quant Research & Backtesting) 这一特定环节，核心痛点是如何最快地把历史数据送入 Python 进行建模。MSD 在此场景下通过“协议级 DataFrame 支持”消除了 Python 解析数据的瓶颈，从而带来了的效率提升。
本测试代码库托管于 CNB.cool，这是一个云原生开发环境，提供了一致的运行环境以确保结果的可复现性。
您可以按照以下步骤亲自运行测试：
-
准备工作：
- 注册并登录 CNB.cool。
- 在 CNB 上创建一个新的云端开发环境 (Cloud Native DevEnv) 并克隆本项目。
-
启动开发环境： 在 CNB 上打开本项目，启动云端开发环境 (Cloud Native DevEnv)。
-
部署数据库服务： 使用
docker compose启动 MSD 和 TaosDB 服务。(可能已自动启动， 通过docker ps来确认, 同时运行uv run main.py时，会自动重启服务以保持环境干净)docker compose up -d该命令将启动
msd(端口 50510) 和tsdb(端口 6030-6060) 两个容器。 -
运行基准测试脚本： 执行
main.py，该脚本会自动完成数据生成、入库和查询测试。使用uv run可自动安装相关的依赖。uv run main.py脚本流程说明：
- 交互式选择：脚本会询问您是否执行 TaosDB 基准测试、MSD Binary (DataFrame Direct) 基准测试以及 MSD Text (CSV Import) 基准测试。
- 自动流程：
- TaosDB Bench: 自动配置驱动、生成数据、重启服务并运行测试。
- MSD Binary Bench: 重启服务，直接生成 DataFrame 并写入数据库。
- MSD Text Bench: 生成 CSV 数据 (如需)，重启服务并执行 CSV 导入测试。
- 最终输出详细的耗时统计日志。
MSD 验证了这样一个前提：对于金融量化，数据库应当是通往分析工具的高速管道，而不是瓶颈。通过剥离不必要的 SQL 开销并针对原始 IO 吞吐量进行优化，MSD 实现了“数据即时可用”的工作流，让您专注于算法本身，而非漫长的等待。
