-
Notifications
You must be signed in to change notification settings - Fork 6
design 数据存储
Baoying Wang edited this page Apr 9, 2018
·
3 revisions
所有的order , 和 execution report 都要存储于数据库中,用于
- 历史数据分析
- audit
- 当日节点启动恢复状态(或者事后清理)
目前只是一些初步的想法
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系统,如大众点评, 比特币交易。由于不存在周末关闭维护的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日