1.最开始,我们使用用组态软件方案,但发现需保存的历史点数量太多;小于2000点,使用组态软件即可!!!
2.后来,又使用实时数据库方案,但发现不能很好地记录每次充电实验的开始时间和结束时间;()
3.再后来,又使用纯关系数据库方案,但又发现保存一年的历史数据需要的磁盘空间根本不够;(没有RTDB的压缩算法)
4.最后选用了实时数据库和关系数据库的混合方案,当选择了实时数据库和关系数据库的混合方案后,才发现,这个方案是多么的简洁和美妙。
---> 实时数据库在国内的应用,是在工业企业信息化过程中,随着关系数据库应用的局限性不断被发现的过程中,逐步使用和被用户认可的。与关系数据库相比,在工业企业中,生产数据的描述相对简单,但其点数非常多,对实时和历史数据的处理远远超过了关系数据库的处理能力。
---> 而实时数据库在快速处理简单生产数据及其产生的海量历史数据等方面,具有极大的优势。
关系数据库不能很好的处理海量数据; 对海量数据的存储有困难,没有RTDB的压缩算法;但RTDB不能很好体现数据项之间的关系!!!
实时数据库为什么能实现关系数据库不能实现的功能和性能呢?主要原因是,实时数据库将数据库的应用领域缩少了,针对这个缩少的应用领域,它可以将数据库理论中的部分功能弱化而将部分功能强化。例如,它弱化了表之间的关系描述;弱化了ACID原则,ACID是 Atomicity(原子性)、Consistency(一致性)、Isolation(隔离性)和 Durability(持久性)的简称;弱化了数据库理论中的事务处理逻辑;它可以允许在一定精度范围内的数据失真。等等。实时数据库弱化这些功能,用以实现高效的数据插入和查询功能,以及较高的压缩比。
实时数据库的产生,其目标是为了解决关系数据库不能解决的问题,但是,实际的应用,并不那么单纯。比如,企业信息化领域中,需要打通现场生产数据与企业经营管理之间的鸿沟,现在管控一体化的思想和MES(制造执行系统)大行其道,其目的即是如此。但是,不管是管控一体化,还是MES,都在监控和数据平台这些基本功能之上,增加了管理相关的功能,这些需求是真实存在的,也是实时数据库产品开发商不能回避的问题。最终的权衡的结果,是关系数据库和实时数据库并存,各自完成自身特定的功能,并且彼此进行数据交换,这是关系数据库与实时数据库混合使用存在的原因。
作为实时数据库产品开发者,需要考虑:能不能提供一种与关系数据库并存的解决方案,将实时数据库集成到整个企业信息化领域中;能不能提供一个能很方便地共同使用关系数据库和实时数据库的应用软件;能不能提供一个提供整体数据的数据平台。
这是问题的所在,也是商机的所在!可以给用户提供一个工业企业的数据平台,不管这些数据是从关系数据库中来,还是从实时数据库中来。这个工作,实时数据库提供商可以做,有一定开发经验的系统集成商也可以做(想好了,明天给我原来呆的湖南那家公司打电话,建议他们考虑在他们的电厂信息化产品套件中使用我们的实时数据库,他们可以向用户提供电厂生产数据平台,这是一个新的可以卖钱的产品呀。)
关于第4个问题,我有这样一些想法:
实时数据库不能满足用户项目的需求,这本身说明,我们所设计的实时数据库在功能上有可能进行某些扩展,如果扩展后,我们即能保持实时数据库的特点,又能满足某具体行业的需求,这不就是行业实时数据库吗?如果我们再扩展一点,可不可以发展一个新的数据库系统呢?
关系数据库是经典的数据库,现在,新的数据库越来越多,详见《实时数据库理论与技术演讲PPT》,如果某些行业的应用具有通用性,为什么不能设计一个新的数据库系统呢?
当然,新的数据库系统的应用领域肯定比标准实时数据库的应用领域要小,但是,随便哪个一个行业,不足够我们发展好一阵了?电力、交通、仿真、优化控制......呵呵,越想口水越多。
这些想法有点远了,但有一个现实的问题:现在的实时数据库,一般都是指流程行业历史型实时数据库,这是由于流程行业历史型实时数据库有其具体特点,也见《实时数据库理论与技术演讲PPT》,但是,我想到了一个新的应用领域,它所使用的实时数据库与我们的实时数据库有功能上有区别,有其特定的问题域和功能域,是一个非常大的市场,我们完全可以做这样的产品,先不说,卖个关子,聪明的你,知道我想说什么吗?