VeighNa量化社区
你的开源社区量化交易平台
Member
avatar
加入于:
帖子: 32
声望: 0

我使用2.0版本,把1.9版本的DataRecording搬过来,订阅了4个品种的行情数据写入sqlite,同时生成5分钟数据和小时数据也写入sqlite,测试了一天,发现丢数据的现象比较严重,比如同一时刻5分钟的bar只能生成三个,还有一个丢失(严重的时候丢失三个,只生成一个),这还是在没有加载策略的情况下.
请教一下有没有vnpy用于实盘的, 实盘负载如何? 如何优化?

Member
avatar
加入于:
帖子: 11
声望: 0

好问题。
对于这些高频率的, sqlite不知道能不能扛得住。
或者最终还是只能采用 redis

Member
avatar
加入于:
帖子: 32
声望: 0

大希一忆 wrote:

好问题。
对于这些高频率的, sqlite不知道能不能扛得住。
或者最终还是只能采用 redis

我觉得瓶颈不在sqlite, tick数据写db的时候我已经做了优化, 采用缓存式的每1000条tick批量插入, 耗时最多几十毫秒.
问题点可能出在: 1. 原DataRecorder好像只是为了把数据记录从核心进程分离,把run.py拷贝出来随意改写了一下,没有考虑到使用与run.py同样的架构同样的CTP网关, 会不会造成VT界面和DataRecorder同时接受tick数据时混乱导致丢数据

2. 生成bar数据是由tick触发的, 500毫秒一个tick, 一旦订阅合约数量多了, BarGenerator不一定能在500毫秒内把所有合约的bar数据都更新一遍, 因此BarGenerator要考虑异步执行, 原架构有待改进.
Administrator
avatar
加入于:
帖子: 4500
声望: 320
  1. 2.0架构和之前的v1.9.2发生了一些变化,所以模块的简单移植不见得直接能用
  2. Sqlite的写入速度还是很高的,这点数量的tick不至于产生问题
  3. BarGenerator的K线合成是基于tick时间而不是本地时间
Member
avatar
加入于:
帖子: 32
声望: 0

用Python的交易员 wrote:

  1. 2.0架构和之前的v1.9.2发生了一些变化,所以模块的简单移植不见得直接能用
  2. Sqlite的写入速度还是很高的,这点数量的tick不至于产生问题
  3. BarGenerator的K线合成是基于tick时间而不是本地时间

大神来解答了, 我也觉得可能是架构匹配的问题, 可能原来在v1.9.2跑的很好, 简单移到2.0不一定能行.
sqlite写入速度不是问题, 我之前曾经想把v1.9.2数据引擎改到sqlite, 改动太大没法动手, 2.0的变化正合我意.

关于BarGenerator的使用问题,我想请教的是一旦我全部主力合约都要订阅落地到数据库,BarGenerator的K线合成一个tick周期内肯定跑不完,如何改进?我现在的做法是把tick_event的触发频率做了人为的限制,期望2.0以后的版本里能有BarGenerator的使用改进的范例,比如使用进程池什么的.

Administrator
avatar
加入于:
帖子: 4500
声望: 320

BarGenerator的K线生成效率很高的(其实就是个时间戳的检查而已),真不用担心这个...

如果有瓶颈,也是在数据库对于硬盘的写入上,这块要么换SSD,要么做个队列慢慢写

© 2015-2022 上海韦纳软件科技有限公司
备案服务号:沪ICP备18006526号

沪公网安备 31011502017034号

【用户协议】
【隐私政策】
【免责条款】