计算PI的存储大小
wmrjll 提供的资料里是这么计算的
对于一个10,000个Tag点的PI系统，则建议客户准备26GB的磁盘空间来保存5年的在线
数据。
因此，为了满足100,000个Tag点的5年在线访问，PI服务器的数据档案库的硬盘
容量估计就需要如下的大小：
[100,000 Tags x 1.5 Kbyte/Tag/天 x 365天/年 x 5年]/ (1024 x 1024) =
26 GB
每年的数据才5.2G
三嘉园 给出的osi经验数据是
1万点，一年6G  看起来，这个差不多。
在OSI 的文档里，我看见过2个计算方法，数据就很大了。
一个是简单的把PI存储一个数据要4个字节
另外一个是 Float 16, Int16 and Digital: 3 bytes/value 3字节/值
Float32 and Int32: 5 bytes/value 5字节/值
Float64: 9 bytes/value 9字节/值
按20%是digital 80%是analog 计算
10000 * (0.2*3/2 + 0.8*5/2) * 1440 * 365 / 1E9 =  11.2 GB/Year
数据相差几乎一倍
我们认为上面的公式应该是最大量，它没有考虑压缩。
而压缩量是动态的
从一个客户来看 1.3w点 11个月2.2G 那么1万点 2.2/11*12*1/1.3 =1.8G
这个压缩 应该是默认的压缩量
这个应用可以算典型应用，远小于给出的经验公式和上面的计算公式
可能是该客户的 digital数据量比较大的缘故。
这个计算有什么意思呢
我记得以前客户问我要准备多大的硬盘
float几个字节多少位
我按4字节一算  吓我一跳 按150k点计算 他们要买磁盘柜
而之前做的项目 50k 一年也就10G
呵呵 他们还真有磁盘柜  不过后来我想明白了 就是压缩的事情
所以 PI 在中国电力系统实施 磁盘计算的经验数据
10k点  一年  2G 即便状态量和模拟量 比例不一样  2.5G 也可以对付了
核查了一下 digital和模拟量的比例　
电力一般是　６０：４０　这样会进一步减小大小
收藏此信息 推荐给好友 2009-2-17 来源：未知
各个实时数据库厂家，都会在自己产品的宣传手册或说明书中，标明自己的压缩率能达到多少多少，或是“10:1”或是“20:1”，这些数字是怎么算出来的呢？
标准答案是：没法算出来。
压缩率的表示方法“N:1”，隐含了两个概念：参照物和测试环境。也就是说，在某种测试环境下，保存同样的数据，实时数据库可以达到参照产品的1/N。
这里的参照物有两种可能性，可以是压缩之前的原始数据，也可以是另一种典型的存贮系统，比如关系数据库。这里的测试环境，应该是某种人为约定的标准输入。关键的问题是，我们能到一种能近似模拟工控设备数据源的标准输入吗？如果不能到合适的测试数据，那些测试结果又有多大的价值呢？
实时数据库应用在过程控制及相关行业，在这个领域中，数据具有如下特征：
最常见的数据是模拟量，也
有一部分开关量；
数据中只有一小部分值经常发生改变，很多开关量常期不变化；
数据的变化具有一定波形规律；
很多数值都具有慢变化的特征； 
数值变化与时间变化具有共同变化特性； 
用户在一定范围内，能够允许数据的精度损失；
我们能到一组模拟以上特性的测试数据吗？聪明的观众肯定会自然地想到，可以用正弦曲线来模拟。只要测得针对正弦曲线的数据压缩率，就能定性（但不能定量）地判断出某实时数据库的大体数据压缩性能。
可是，即便采用正弦曲线来模拟，还需要考虑很多其它因素。
A、取样密度
对于同一条正弦曲线，比如1分钟变化一个周波，如果取样密度不一样，所得到的取样点数是不一样的。如果每秒钟取一个点，可以取得60个点，如果每0.1秒取一个点，可以取得600个点，再极端一点，
如果1毫秒取一个点，可以取得60000个点。我们假定可以用一些特征点来描述该曲线，则取样密度越大，数据冗余度越高，数据压缩率就越高。如果某实时数据库产品宣称自己的数据压缩率为1000:1，你也不要认为他在吹牛，他也许就是对以毫秒为单位取样的1分钟变化一个周波的数据进行压缩呢。
B、数据精度
保存一个双精度数比保存一个单精度数所需要的空间肯定要大。但在很多过程控制应用中，单精度数完全足够了。
C、数据范围
数据范围可能影响数据精度。
C、数据失真率
如果用户不允许任何失真，那就是无损压缩。但事实上，工控行业就是一个不可能完全不失真的行业（详见我的博文《关于变位压缩的讨论》）。
聪明的观众看到这儿，肯定就会说，那好办，制定一个统一的标准，以1秒钟作为取样密度，取单精度数，以1分钟变化一个周波，数据范围为-100至100，失真率设为0.5%，将各个实时数据库产品都运行起来，看看各个实时数据库厂家的数据压缩率到底是一个什么样的值。
这个方法确实可行，可是，会有一些实时数据库厂家站出来说，只有这些还不够，还要考虑以下因素：
A、时间精度
大家部实时数据库支持精确到毫秒，但部分厂家在这上面打起了节省空间的算盘，只精确到5毫秒，或只精确到100毫秒，并很严正地宣告，在常规实时数据库应用中，精确到毫秒完全没有意义。
B、测点数
有一些实时数据库对多个测点的数据压缩与对单个测点的数据压缩，效果是有区别的（这个地方我卖个关子，有谁能猜得出来吗？）
C、测试时间
大部分实时数据库为了减少磁盘读写时间，对磁盘空间都是预分配的，系统初始化后，就预先申请了一大块磁盘空间，你怎么测试它保存数据花了多少空
间呢？
聪明的观众会继续聪明地说，再加约束条件，所有的时间精确到1毫秒，统一测试1万点，统一运行一个月，现在总可以了吧。
差不多了（还有一些其它因素，就不再罗列，否则有人会说我是唐僧），如果按照这个标准来测，呵呵，大家会发现，每一家实时数据库的测试结果都比他们的宣传要低几倍。
但这些实时数据库厂家也有理由，这种测试本来就不能完全模拟工控现实情况呀，工控现场有开关量，有整型量，还有个别字符串量，还存在很多大部分时间不变化的量，这些因素，是要考虑进去呀。
OK，这么多理由，那你告诉我你的数字怎么来的吧。他们会这么答复：我们是从多个典型工程的多年对比数据中统计而来的，这些数据，如果用关系数据库来存贮，需要比实时数据库30倍的空间（PI是这么回答的）。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。