高速采集与存储问题! 点击：1526 | 回复：16
发表于：2002-08-12 11:14:00
2楼
我不知道你作的是什么项目，要如此数据量。我不知道32M/s是如何算出来的，如果真是一秒钟向数据写入这么大的数据量就有点问题了。用什么存储都是问题，一天近3T的数据量，不是说着玩的，SQL Server实在不是个好东西，我想铁定不行，SQL Server在数据量很大以后会出现一些问题，我想你很快就会发现你的数据只能往数据库里写，而删不掉的。
要提高数据库的存储速度，我有点经验：
1）适当的数据压缩，高压缩率可能会加大系统负荷，也会使数据解压速度变慢，而且这种压缩并不一定要使用我们常见的那些压缩算法，你也许知道PCX图形格式，使用的是行程编码，这是最快的压缩算法，对有些数据你会有很高的压缩率。可以在些基础上开发出一种适用于你的数据类型的压缩算法。
2）最大限度减少你的数据库的IO操作量，其实一个数据库引擎可能影响其速度的地方不一定的数据量太大，而是IO量太，对32M/s的数据是，如果是一条记录的话，我想大部分的数据库在速度上都是可行的。但如果是1000条或上万条的话，那你就死定了，所以减少数据库的IO操作量可以大幅度的提高数据的存储速度。这方面的处理方法有两种，一种是将每秒钟所采集的数据压缩成一条或几条，这种方法节省内存，但如果在数据库检索时要按条检索高有可能会由于得到太多的多余数据而降低检索性能；另一种方法是将一段时间的数据当作一条记录来存储，例如对1000个点的数据，以1s为采样时间，那么你每秒要1000个IO操作，每分钟60000个IO操作，这会很慢，如果你设采样时间同样为1s，但采集的数据并不写入数据库中，而是缓冲在内存里，这些采样点的数据我们以一个点为一条记录，比如对各个数据以","符号来分割开来，在缓冲一分钟写一次，你让为会如果，原来每分钟60000个IO操作现在变成为每分钟1000个IO操作，性能上会大大提高的。
3）如果项目有足够的冗余资金的话，可以考虑买一个专业的工厂实时数据库，听说不错，像InSQL，不过不知道如何，我没用过，对些不作评论。
发表于：2002-08-13 10:31:00
5楼
我认为李侃兄关于存储成文件夹的作法不以为然，一个系统对数据的存储并不只能考虑如何存储可高效，最重要的是如何使用高效，直接在存成文件可能速度上要快上，但如果你想对数据进行分析时可能高有问题了，如果只是显示显示才可以，要是想对它进行复杂分析就很困难了，如此大的数据，没有索引，也没有SQL语法支持，很难的。如果cocolux兄也只是对数据作简单的显示的话，可以考虑使用这种方法。
关于double buf问题我认为应该根据数采的需要来分配缓冲区，比如从每一项数据的大小和采样频率来在系统初始化时算法出数据的最大缓冲需求；或仅初始化一个基本的缓冲区，而在数据采集时让该缓冲区的大小只增不减，这样它就会在一个点上到达最大值。对于如此重要和大型的系统是不可以突视对内存的管理的，我对于制作7*24小时连续运行的系统的内存分配上的观点是可以适当的浪费内存，但不能为了节省内存而过多的使用动态内存，这样会使系统的内存碎片太多而使得系统运行性能越来越差，最后可能死掉。
热门招聘
相关主题
- 数据采集卡dma方式是怎么回事...
[1218] - 准确地讲PAC 就是一概念[1177]
- 基于泓格Wincon PAC的远程控...[1988]
- 工业控制计算机的发展现状与...[9046]
- 用工控机代替PLC[1353]
- 使用双网卡能不能实现内网和...[2670]
- 几种流行的PAC的功能比较[8167]
- PLC与PAC，名称变化的背后[1382]
- ActiveX容器[2804]
- ActiveX控件[5215]
官方公众号
智造工程师
-
客服
-
小程序
-
公众号
工控网智造工程师好文精选
