算法交易系统的数据库之路

所有软件系统中都必须包含一项关键组件，那就是用于存储、检索和分析数据的数据库。本文中，我们将和大家一起探讨适用于算法交易平台的数据库都会有哪些特性？有哪些可选择的数据库？

从广义层面来看，数据库提供了记录和管理数据（OLTP）和分析数据（OLAP）的能力。大多数数据库会擅长其中一种能力，同时在某些指标具备优势，而在另一些方面则有所欠缺。举例来说，擅长一致和持久事务的关系型数据库可能在性能方面表现不是很好，因为它需要锁定其数据结构并刷新所有磁盘写入。相反，优先考虑性能的数据库可能需要使用宽松的一致性模型。

根据特定功能和特性的优先级划分，不同种类的数据库适用于不同的场景。

1算法交易系统的数据存储

如果我们想追求完美，即持久、一致地存储大量数据并快速进行实时分析，这能做到吗？尽管计算机科学理论警告我们不要太贪心，但是有一些工程思想值得参考。

主要设计目标包括：

• 快速将大量事件提取到持久存储中（每天工作数小时，约 250K-1M 个事件 / 秒；我们预期每个事件约为 100-200 字节，并具有 10-30 个字段）

• 实时分析，包括汇总

• 能够处理大量模式和趋势历史数据

基于以上的设计目标，我们可以构建几种解决方案，不过基本上都需要对数据存储进行分层，以提供多种附加能力。

其中的一种解决方案为：

1. 将交易系统中的所有事件存储到一个快速数据存储中，例如仅附加文件日志（可能在高可用性系统的多个节点上复制或重新创建）。该文件提供持久存储，但没有真正的查询功能。

2. 将该日志文件的内容顺序提取到一个内存数据库 / 缓存中。这个步骤可以很快，甚至是实时的，因为在这一层没有一致性检查、复制或持久性要求。该层应提供实时聚合和分析。

3. 定期将内存数据库的内容持久存储到磁盘（每小时或一天结束时等）。这里使用可以对磁盘上存储的大量数据进行操作的数据库。本质而言，对存储的这些数据进行的操作被视为脱机或批处理模式，并且不期望瞬时响应时间。

4. （可选）仅将日志文件的相关部分提取到一个关系型数据库中，以提交每日 / 每月报告。例如，只有订单和执行会被加载到关系型数据库中，而市场报价会被跳过。

另外，这个解决方案也是可以简化的，例如可以将步骤 2、3 和 4 组合起来，使用一个提供多种存储和分析数据模式的工具。

接下来，我们就来一起讨论一下细分需求下的数据库工作。

2我们对数据库的要求

我们对数据库的要求可分为非技术需求和技术需求两部分。

非技术需求列表：

成本：作为一家注重成本的初创企业，我们正在寻找免费或相对便宜的产品。鉴于当今有许多 FOSS 方案，我们认为这不是什么疯狂的要求。这也意味着 Oracle 和 MS SQL Server 等标准付费数据库被排除在外了。

良好的文档和社区支持：如果我们不支付许可和支持费用，就需要良好的文档和另一种解答问题的途径。可行途径可以是邮件列表、活跃的在线社区，也可能只需 StackOverflow 即可。

运营工具：我们更喜欢相对成熟的产品，自带用于设置、管理和监视部署（包括可能的多节点集群）的工具。

技术需求：

快速提取：我们需要数据库能够以每秒 250K 次插入的速度提取，越高越好。如果我们需要批量插入，那是可以接受的；如果我们需要使用多个线程或连接也可以。

快速聚合：我们打算在系统中使用事件源模式。按照这一架构模式的规定，我们会将系统中的所有状态