在WLD插件项目开发中，碰到一个技术问题，想和大家探讨一下。一般证券分析软件的日线数据没有数量限制（是否实际上分析家的保存期限也是有限的，约在6000个左右？），但高频数据，如TICK、1MIN等则有实际上的限制，这样长期的高频历史数据难以从现有的股票数据软件中直接获得，需要使用一种可以保存较长期限的文件格式。问题如下： 1、有哪些现成的文件格式，如金卡绣球，可以保存长时间的高频数据记录，包括K线数据和盘口数据记录； 2、长期保存的数据文件应具备怎样的设计特点，是否应该采用整型数据而不是浮点数据，是否应该采用压缩技术，是使用定长记录（规范化的字段定义）还是实现SERIALIZATION的特定类，是使用单一的大文件还是使用分立的小文件，做分立文件时是按时间分还是按代码分； 3、是否需要划分可归档数据与程序直接控制数据，前者是可以无限制长度归档，但不便为程序直接控制和使用的数据，后者是程序可以直接访问和控制的数据，但可能存在长度限制的数据。在宏汇NSD中，每天可以下载一个当日的数据文件（这个文件可以无长度限制地归档保存），然后把这个下载文件中的有关数据导入宏汇NSD的历史数据文件（有保存长度限制），这种设计是否必要，是否采用单一的无限制长度数据文件更为合理； 4、如果高频交易历史数据文件有长度限制，如何确定这个长度应该为多少，是根据个人的经验（股票可能若干年就足够，因为股性会变异，97年的深科技与今天的深科技完全不是一回事；而期货、外汇具有相对稳定的变动特性，20年分钟数据也不过分）、数理统计分析（用包括回归分析在内的方法确定时间序列的统计特征具有时间划断窗口）、测试需要（分析家6000个左右的记录限制对绝大部分测试和系统设计已经足够？）还是计算机实际处理能力（一般P4机器内存最大为2G，全市场高频数据总量不应超出这个范围）？ 5、历史盘口数据（MARKET DEPTH/LIMIT ORDER BOOK）的存放格式有什么特殊之处（例如，每一笔五档买卖盘价格和数量不会全部变化的特点是否应该被考虑）。
哇赛，问题好多啊，呵呵； 得仔细看了： 目前分析家所有版本得日线都Max6400根，看它怎样更新软件了； 》1.问的太好了，正设置NNNN年的数据问题，来，大家探讨一下啊； 1.有个UTC时间问题，看用什么数据好（以后要处理任意时间），打算另加一个Long在前面，给UTC时间分段，0就是现在用的，负的是以前的，比方有人问过要看1900年的股票咋办，现在的fh，fxj都不行； 我们主要用的数据，日线、Min1、五档分笔盘口数据； 单文件、无长度限制、精确型（到交易所最细致数据）； 用来看任意时候的情况； 真正实用的是最近几年的数据；
2.觉得还是浮点好了，要处理很多市场的数据，不容易谐调； （象同花顺，一大堆整型，wu wu ～～） 前面可以、3年内数据还是不雅了，处理速度会跟不上的； 喜欢单文件，不然一点呼啦，就可以把那个N G大的day.* 给泡汤了； 定长；但要解决我前面说的Time 问题，精确到秒；
3.单一文件； 前面是呀的数据，后面一个段是一段时间的最新数据，后段超标太长，合并呀到前面，前面一般都不动的，数据头可以指出最新开始地； 专门补充数据的数据，就一个大文件ok了，象fxj等；扩充一下，可以补任何数据；
4.同3； 但可以分开呀的和最新的； 例如一个呀的几百兆数据（分时间段呀了），和一个最新数据； 5.对的，这个要斟酌一下； 但不想象fxj、fh那种，数据都搞得不对的，只是近似数据； 我要精确到交易所最细致的数据；
高频数据格式适合取相应交易所或数据源的原始数据格式，以每个品种为一个数据文件为好。可以是数据库文件或文本格式文件。高频数据以准确、完整为目的，不亦过多考虑文件大小，可能以固定长度简洁。现在国内已经有部分高频数据库了（清华、北大和交易所），可以借鉴它们的。
最近考虑了一下，觉得可以参照Global Server，高频原始数据还是以一个品种一个文件为好。而作为综合分析系统的基础数据库按相对统一的市场品种为单文件形式为好。如果飞狐、分析家能将它们的现有产品中的数据库部分独立出来成为产品就好了。参看这里的建议。 http://www.hylt.net/club/viewtopic.php?t=6568
关于数据存贮格式，似乎股票软件都不太敢直接用嵌入式的SQL数据库，实际上现代的嵌入式的SQL数据库在处理巨量数据时都会考虑数据在磁盘上的分段存储，因此把高频数据交给数据库引擎来考虑可能要比自己重新去考虑这个问题要好。 我开发的一个系统中，最大的一张表有1亿条数据，但还是能在不到30秒内把满足一大堆条件的2万条查出并通过网络传过来。
目前来说，Java的这类嵌入式数据库比较多，比如，hsqldb和derby，都不需要Server端，BlogTrader Platform就是用的这种，性能如何等他的系统测试模块出来就知道了。derby是IBM资助的项目，可以保证大量数据的存储。BlogTrader的下个版本换成了它，估计是为大量数据的测试作准备。 至于Access软件，应该可以在网上找到直接调用它的数据文件的接口，但不知道能否应付大批量的数据。
如果是日线数据，单市场，用单个文件存储问题不大，就像分析家。但如果是高频数据（如包括大量的1分钟数据），整个全球市场，那这个问题交给数据库引擎来处理可能比较合适。不同的数据库引擎针对各自的查询实现都会尽量优化大批量数据时的数据存贮格式，有的用单一数据文件+单独的索引文件，有的用分段文件+索引文件。这些问题是数据库设计的重点之一，所以我认为应该交给他们来考虑。 至于市场测试，是要将数据全部读出来，但鉴于计算机系统内存的限制，仍然需要考虑缓存等机制，这些与其自己来设计，也同样不仿交给数据库自己来处理。