金融市场高频数据的有效管理

测试代码如下：

＃读取Level 1数据集一天的数据
timer t1 = select * from loadTable("dfs://TAQ", "quotes") where TradeDate = 2007.08.23

＃读取Level 2数据集一天的数据
timer t2 = select * from loadTable("dfs://DataYesDB", "tick") where TradeDate = 2019.09.10

测试步骤如下：

（1）使用Linux命令sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"清理操作系统缓存，可能需要在root用户下执行。

（2）执行pnodeRun(clearAllCache)清理DolphinDB的数据库缓存。

（3）执行查询脚本，此时为无操作系统缓存时的结果。

（4）再次执行pnodeRun(clearAllCache)清理DolphinDB的数据库缓存。

（5）再次执行查询脚本，此时为有操作系统缓存时的结果。

测试代码如下：

import dolphindb as ddb
import pandas as pd
import time

s = ddb.session()
s.connect("192.168.1.13",22172, "admin", "123456")

＃读取Level 1数据集一天的数据
st1 = time.time()
quotes =s.run('''
select * from loadTable("dfs://TAQ", "quotes") where TradeDate = 2007.08.23
''')
et1 = time.time()
print(et1 - st1)

＃读取Level 2数据集一天的数据
st = time.time()
tick = s.run('''
select * from loadTable("dfs://DataYesDB", "tick") where TradeDate = 2019.09.10
''')
et = time.time()
print(et-st)

测试步骤如下：

（1）使用Linux命令sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"清理操作系统缓存，可能需要在root用户下执行。

（2）执行pnodeRun(clearAllCache)清理DolphinDB的数据库缓存。

（3）执行查询脚本，此时为无操作系统缓存时的结果。

（4）再次执行pnodeRun(clearAllCache)清理DolphinDB的数据库缓存。

（5）再次执行查询脚本，此时为有操作系统缓存时的结果。

pickle测试代码如下：

import dolphindb as ddb
import pandas as pd
import time
import pickle

s = ddb.session()
s.connect("192.168.1.13", 22172, "admin", "123456")
tick = s.run('''
select * from loadTable("dfs://DataYesDB", "tick") where TradeDate = 2019.09.10
''')
quotes =s.run('''
select * from loadTable("dfs://TAQ", "quotes")
''')

#将数据集1的Level 1的数据转换为pkl文件
quotes.to_pickle("taq.pkl")

#将数据集2的Level 2一天的数据转换为pkl文件
tick.to_pickle("level2.pkl")

#使用pickle模块读取数据集1的Level 1一天的数据
st1 = time.time()
f = open('taq.pkl', 'rb')
c = pickle.load(f)
et1 = time.time()
print(et1 - st1)
f.close()

#使用pickle模块读取数据集2的Level 2一天的数据
f = open('level2.pkl', 'rb')
st = time.time()
c = pickle.load(f)
et = time.time()
print(et - st)
f.close()

测试步骤：

（1）第一次执行测试代码，此为pickle无操作系统缓存时的结果。

（2）第二次执行pickle模块读取数据的脚本，此时为pickle有操作系统缓存时的结果。

从测试结果看，直接从DolphinDB数据库查询，速度最快，超过pickle查询的10倍以上。在没有操作系统缓存的情况下（大部分的实际场景），DolphinDB Python API的查询速度明显优于pickle。在有缓存的情况下，两者相差无几。有无缓存，对DolphinDB Python API没有显著的影响，但是对pickle却有显著的影响。这些结果从DolphinDB Python API和pickle的耗时构成，可以得到进一步的解释。

pickle文件存储在单个HDD裸盘上，读取性能的极限速度在每秒150MB~200MB之间。读取一个12G大小的pickle文件，需要70秒左右的时间。可见在当前配置下，pickle文件读取的瓶颈在磁盘IO。因此当有操作系统缓存时（等价于从内存读取数据），性能会有大幅提升，耗时主要是pickle文件的反序列化。要提高读取pickle文件的性能，关键在于提升存储介质的吞吐量，譬如改用SSD或者磁盘阵列。

DolphinDB数据库与Python API客户端之间采用了改良的pickle协议。如第1章中所述，使用DolphinDB Python API进行查询可分为3个步骤，其中步骤2和3是可以同时进行的，即一边传输一边反序列化。因此使用Python API从DolphinDB数据库查询的总耗时约等于第1个步骤查询耗时与第2和3个步骤的较大值之和。在两个数据集的测试中，无论是否有缓存，DolphinDB数据库查询部分的耗时均在5~6秒左右。一天的数据量在DolphinDB数据库中约为8G，分三个节点存储，每个节点的数据量约为2.7G。从一个节点查询，需要传输的数据量约为5.4G（本地节点不需要网络传输），对万兆以太网而言，对应5~6秒的传输时间。因此当前的配置下，DolphinDB数据库查询的瓶颈在于网络，而不是磁盘IO。一天的数据量压缩之后约1.4G，分布于12个磁盘中，按照每个磁盘100mb/s的吞吐量，加载一天数据的磁盘时间约在1.2秒，远远低于网络需要的5~6秒。简而言之，DolphinDB时序数据库通过压缩技术和分布式技术，大大缩短了加载一天的金融市场数据的时间，使得磁盘IO不再成为数据查询的瓶颈。

如前所述，DolphinDB Python API的反序列化也采用了pickle协议，但是进行了改良，比原版的pickle协议节约了5~6秒时间，正好抵消了数据库查询消耗的5~6秒时间。所以在有缓存的情况下，pickle和DolphinDB Python API耗时几乎相等。如果要进一步提升DolphinDB Python API的查询性能，有两个方向：（1）采用更高速的网络，譬如从10G升级到100G，第一步查询的耗时可能从现在的5~6秒缩减到2秒。（2）继续改良pickle协议。

以数据集1为例，在没有缓存的情况下，DolphinDB Python API总共耗时38秒，但是数据库端的耗时仅5~6秒，80%的时间耗费在pickle反序列化上。通过进一步分析，我们发现字符串类型对pickle的反序列化有极大的影响。如果查询时，剔除两个字符串类型字段，数据集1的时间缩短到19秒，减少了一半。也就是说两个字符串字段，以20%的数据量，占了50%的耗时。数据集2总共78个字段，其中2个字段是字符串类型，如果不查询这两个字段，时间可从22秒缩减到20秒。

以下是读取美国股市Level 1（去除字符串字段）数据集的测试结果：

以下是读取中国股市Level 2（去除字符串字段）数据集的测试结果：

剔除字符串字段，对提升pickle的查询也有帮助。在数据集1有缓存的情况下，耗时缩短一半。但是在没有缓存的情况下，提升有限，原因是瓶颈在磁盘IO。

这两个数据集中的字符串类型数据分别是股票ID和交易所名称。股票ID和交易所名称的个数极其有限，重复度非常高。DolphinDB数据库专门提供了一个数据类型SYMBOL用于优化存储此类数据。SYMBOL类型为一个具体的Vector或Table配备一个字典，存储全部不重复的字符串，Vector内部只存储字符串在字典中的索引。在前面的测试中，字符串类型数据已经启用了SYMBOL类型。如果改用STRING类型，DolphinDB的性能会降低。尽管通过SYMBOL类型的优化，为DolphinDB服务端的查询以及pickle的序列化节约了不少时间，但是pickle的反序列化这个步骤并没有充分利用SYMBOL带来的优势，存在大量的python对象多次copy，这是进一步优化的方向之一。

在实际工作中，经常会多个用户同时提交多个查询。为此我们进一步测试了DolphinDB Python API和pickle在并发查询下的性能。测试采用了数据集2。对于DolphinDB Python API，我们分别测试了连接本地服务器的数据节点进行并发查询，以及连接不同服务器的数据节点进行并发查询的性能。对于pickle，我们并发查询了同一个节点同一个磁盘的不同文件。由于全局锁的限制，测试时，开启多个Python进程从pickle文件或DolphinDB数据库加载数据。下表是三个连接并发查询数据集2中不同日期的Level 2数据的耗时。

pickle的耗时线性的从70秒增加了到了220秒。由于磁盘IO是pickle的瓶颈，在不增加磁盘吞吐量的情况下，读任务从1个增加到3个，耗时自然也增加到原先的3倍。当同一个客户端节点的三个连接连到不同的服务器数据节点时，耗时增加了50%（10s左右），主要原因是客户端节点的网络达到了瓶颈。当同一个客户端节点的三个连接接入到同一个服务器数据节点时，耗时增加了100%（22s左右），主要原因是客户端节点和接入的数据节点的网络同时达到了瓶颈。

如果要进一步提升DolphinDB并发的多任务查询性能，最直接的办法就是升级网络，譬如将万兆以太网升级成10万兆以太网。另一个方法是在数据节点之间以及数据节点和客户端之间传输数据时引入压缩技术，通过额外的CPU开销提升网络传输的效率，推迟瓶颈的到来。