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 查询能力更为重要。”

1. 算法复杂性：量化交易算法通常涉及复杂的统计模型、信号处理和机器学习技术。这些逻辑如果用标准 SQL 表达，不仅极其困难，往往也效率低下。

   案例：计算全市场 5000 只股票的“动量因子”并按波动率归一化排名。在 SQL 中，这需要极高消耗的窗口函数和多层嵌套；而在 pandas 中，仅需 df.pct_change().rolling().std() 等几行向量化代码即可完成。更不用说像 GARCH 模型或 LSTM 输入预处理这种根本无法用 SQL 完成的任务。

2. 工具生态：现代量化技术栈高度依赖 Python 的数据科学生态。pandas and polars 提供了向量化操作和极其丰富的 API，在回测和策略研究方面远胜于 SQL。

   案例：使用 scikit-learn 进行市场状态聚类，或使用 Ta-Lib 计算复杂技术指标。这些标准化的量化库在 Python 中触手可及，但在数据库内部完全缺失。

3. 瓶颈所在：量化研究中的主要瓶颈往往不在于 查找 数据，而在于将数据从数据库 移动 到应用程序内存中。通用数据库往往为了支持并发 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)，模拟真实量化研究员的日常使用场景。

操作	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)

1. 存储与持久化 (Storage & Durability)：

   • MSD 后端基于调优过的 RocksDB。
   • 采用 Chunk 存储策略：RocksDB 中的一个 Key 对应多个时间点的记录块 (Chunk)。
   • 高吞吐写入：8.7M rows/s 的写入速度得益于这种分块设计——数据首先在内存中聚合，只有当 Chunk 满或触发 flush 策略时才会落盘。这在保证了极高吞吐量的同时也通过 WAL 提供了标准的数据持久化保证。

2. 协议与零拷贝 (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，这是一个云原生开发环境，提供了一致的运行环境以确保结果的可复现性。

您可以按照以下步骤亲自运行测试：

0. 准备工作：

   • 注册并登录 CNB.cool。
   • 在 CNB 上创建一个新的云端开发环境 (Cloud Native DevEnv) 并克隆本项目。

1. 启动开发环境： 在 CNB 上打开本项目，启动云端开发环境 (Cloud Native DevEnv)。

2. 部署数据库服务： 使用 docker compose 启动 MSD 和 TaosDB 服务。(可能已自动启动， 通过 docker ps 来确认, 同时运行 uv run main.py 时，会自动重启服务以保持环境干净)

   docker compose up -d
   

   该命令将启动 msd (端口 50510) 和 tsdb (端口 6030-6060) 两个容器。

3. 运行基准测试脚本： 执行 main.py，该脚本会自动完成数据生成、入库和查询测试。使用 uv run 可自动安装相关的依赖。

   uv run main.py
   

   脚本流程说明：

   • 交互式选择：脚本会询问您是否执行 TaosDB 基准测试、MSD Binary (DataFrame Direct) 基准测试以及 MSD Text (CSV Import) 基准测试。
   • 自动流程：
     1. TaosDB Bench: 自动配置驱动、生成数据、重启服务并运行测试。
     2. MSD Binary Bench: 重启服务，直接生成 DataFrame 并写入数据库。
     3. MSD Text Bench: 生成 CSV 数据 (如需)，重启服务并执行 CSV 导入测试。
   • 最终输出详细的耗时统计日志。

MSD 验证了这样一个前提：对于金融量化，数据库应当是通往分析工具的高速管道，而不是瓶颈。通过剥离不必要的 SQL 开销并针对原始 IO 吞吐量进行优化，MSD 实现了“数据即时可用”的工作流，让您专注于算法本身，而非漫长的等待。