如何构建回测系统(六)

如何构建回测系统(六)

数据量问题

  1. 粗略估算,从2000年到目前,若完全采用逐笔构建高精度交易数据,至少需要31TB的存储空间
  2. 内存不可能满足
  3. 采用文件存储搜索不方便,时间复杂度过高

解决方向

  1. 抛弃原有的完全将数据放置于内存中的想法
    1. 引入数据库
    2. 分表存储和读取
    3. 应用层做聚合
  2. 将原来由回测系统每次构建高精度数据,变更为ETL系统做数据的计算和存储,回测系统仅读取,分离其功能

难点

  1. 为提升开发效率使用的是jpa/hibernate,但是jpa的层级过高,不方便做分表分库聚合,需要使用其底层的接口针对需要分表的对象重新构建应用层数据库接口
  2. 剥离了项目之后的依赖关系,及接口关系梳理

一点小感悟

从JPA和MyBatis的开发过程来看其设计思路区别就有点大了

MyBatis的工具主要都是面向现有表结构,然后才有对象的设计方式,其最佳实践环境应是在有专门的DBA帮助完成表设计,然后依据表设计来构建业务代码

而JPA的思路是,我先有对象,然后仅仅是分析对象之间的关系,并持久化对象,其两者的思路不一致

二者都可以应用DDD做设计,但因为分工原因,会导致其DBA的设计思路是按着最少冗余设计,而开发时候只能迁就其设计思路

而对象设计者很可能是对象的实现者,这时候,将持久化的过程交给一套方法或者规则来完成,能最大化匹配其实现业务代码的思路

MYSQL性能测试

其实还有更新的结论是,在新的MYSQL版本中BLOB字段并不是性能损失的原因。更具体的原因,下次将我理解的MYSQL索引的过程写下来

 

———————————-2015-11-19以上—————————————

最近公司项目中遇到了性能问题,是关于BLOB字段带来的性能损失。

首先在数据库中创建了这么两个表

 

继续阅读“MYSQL性能测试”

常用MYSQL指令

数值型:

 

TINYINT 1 ,SMALLINT 2,MEDIUMINT 3 ,INT 4,BIGINT 8,DECIMAL,FLOAT 4,DOUBLE 8,BIT

 

 

字符串型

 

CHAR,VARCHAR,BINARY,VBINARY,TINYBLOB,BLOB,MEDIUMBLOB,LONGBLOG,TINYTEXT,TEXT,MEDIUMTEXT,LONGTEXT,EMUM,SET

 

日期时间型

 

date,time,datetime,timestamp

 

数据限定修饰:

 

NOT NULL,NULL,DEFAULT,AUTO_INCREMENT,UNSIGNED,PRIMARY KEY,UNIQUE KEY,FOREIGN KEY

 

CHARACTER SET #ps:SHOW CHARACTER SET 显示当前数据库所支持的所有字符集

COLLATION #ps:SHOW COLLATION 显示所支持的所有排序规则

 

继续阅读“常用MYSQL指令”