design 数据存储

介绍

所有的order , 和 execution report 都要存储于数据库中，用于

1. 历史数据分析
2. audit
3. 当日节点启动恢复状态（或者事后清理）

目前只是一些初步的想法

表结构

order

• only insert(with order id assigned by our exchange)
• 对于mod/cancel, insert too. They have same order id with new. 这样做的目的是为了简化设计。

execution_report

• 所有订单状态变化以单独一条记录保存。即：一个order（以order id为key）可以有多个execution_report records
• TODO : 定义execution report的所有状态（这不单是数据库设计的一部分，更是exchange 状态转换的一部分)

数据库扩展 - 周末系统关闭的系统

一般交易所都将在周末关闭。利用这个时间，将历史交易数据从当前表中导出到数据仓库中（供客户查询历史订单状态等）。 这个方法简单实用。

• 注意：仅适用于单个数据库可以满足当前业务(不是瓶颈)
• 注意：如果你的业务支持一个订单跨越很长时间，例如1个2个月的外汇期权。那么你不能将其默认归档。必须单独考虑这样的需求。
• 注意：如果是7×24的交易系统，则无法采用这样的方式。

数据库扩展 - 7×24交易系统

7×24系统，如大众点评， 比特币交易。由于不存在周末关闭维护的window，无法关闭交易系统进行数据直接arcive. 所以，我们需要考虑其他的方式 注意：其实有些系统是可以在深夜有很少客户的时候，进行archive。不过需要保证这个过程非常快才行(几分钟？），以尽量减少对可能客户的影响。

常见的分库分表方式有水平/垂直切分。 很多出色的文章，如 https://zhuanlan.zhihu.com/p/24036067 大众点评订单系统分库分表实践 by 美团点评技术团队 https://www.jianshu.com/p/32b3e91aa22c 分库分表需要考虑的问题及方案 by jackcooper at 2017.02.08 https://blog.csdn.net/bluishglc/article/details/6274841 数据库分库分表(sharding)系列 by bluishglc at 2011年03月24日