首页 理论教育 数据库系统的设计方案

数据库系统的设计方案

时间:2023-06-26 理论教育 版权反馈
【摘要】:后台数据库是系统架构的重要组成部分,决定了系统数据的安全性和系统长期运行的稳定性。它是在数据库领域一直处于领先地位的产品。相比于大型的数据库系统,MySQL功能略显单薄。

数据库系统的设计方案

后台数据库是系统架构的重要组成部分,决定了系统数据的安全性和系统长期运行的稳定性。当前可选的数据库系统很多,这些系统的功能、运行平台、运行维护成本各有不同,下文将对其分别进行介绍,并总结归纳风电功率预测软件数据库系统的选取原则。

4.3.4.1 主流数据库系统的介绍

1.Oracle

Oracle Database,又名Oracle RDBMS,或简称Oracle,是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统,系统可移植性好、使用方便、功能强,适用于各类大、中、小、微机环境。它是一种高效率可靠性好、适应高吞吐量的数据库解决方案

Oracle数据库最新版本为Oracle Database 12c。Oracle数据库12c引入了一个新的多承租方架构,使用该架构可轻松部署和管理数据库云。此外,一些创新特性可最大限度地提高资源使用率和灵活性,如Oracle Multitenant可快速整合多个数据库,而Automatic Data Optimization和Heat Map能以更高的密度压缩数据和对数据分层。再加上在可用性、安全性和大数据支持方面的主要增强,使得Oracle数据库12c成为私有云和公有云部署的理想平台。

以Oracle数据库的架构而言,数据文件包括:控制文件、数据文件、重做日志文件、参数文件、归档文件、密码文件。这是根据文件功能行进行划分,并且所有文件都是二进制编码后的文件,对数据库算法效率有极大的提高。由于Oracle文件管理的统一性,就可以对SQL执行过程中的解析和优化,指定统一的标准:RBO (基于规则的优化器)、CBO (基于成本的优化器)。通过优化器的选择以及强大的HINT 规则,给予SQL 优化极大的自由,对CPU、内存、IO 资源进行方方面面的优化。

2.DB2

DB2是美国IBM 公司开发的一套关系型数据库管理系统,它主要的运行环境跨越UNIX (包括IBM 自家的AIX)、Linux、IBMi (旧称OS/400)、z/OS,以及Windows服务器版本。

DB2主要应用于大型应用系统,具有较好的可伸缩性,可支持从大型机到单用户环境,应用于所有常见的服务器操作系统平台下。DB2提供了高层次的数据利用性、完整性、安全性、可恢复性,以及小规模到大规模应用程序的执行能力,具有与平台无关的基本功能和SQL命令。DB2采用了数据分级技术,能够使大型机数据很方便地下载到LAN数据库服务器,使得客户机/服务器用户和基于LAN 的应用程序可以访问大型机数据,并使数据库本地化及远程连接透明化。DB2 以拥有一个非常完备的查询优化器而著称,其外部连接改善了查询性能,并支持多任务并行查询。DB2 具有很好的网络支持能力,每个子系统可以连接十几万个分布式用户,可同时激活上千个活动线程,对大型分布式应用系统尤为适用。

DB2除了可以提供主流的OS/390和VM 操作系统,以及中等规模的AS/400系统之外,IBM 还提供了跨平台 (包括基于UNIX 的LINUX,HP-UX,SunSolaris, 以及SCOUnixWare;还有用于个人电脑的OS/2操作系统,以及微软的Windows2000和其早期的系统)的DB2产品。DB2数据库可以通过使用微软的开放数据库连接 (ODBC)接口,Java数据库连接(JDBC)接口,或者CORBA 接口代理被任何的应用程序访问。

DB2在企业级的应用最为广泛,在全球的500 家最大的企业中,几乎50% 以上用DB2数据库服务器,目前广泛应用于金融电信保险等较为高端的领域,尤其是在金融系统备受青睐。软件的授权收费和服务费与Oracle相当。

3.SQL Server

SQL Server是Microsoft公司推出的关系型数据库管理系统,具有使用方便、可伸缩性好、与相关软件集成程度高等优点,但其使用平台仅限于Windows系统,相比于Oracle、DB2而言,使用范围颇为局限。

SQL Server的数据架构基本是纵向划分,分为:Protocol Layer (协议层),Relational Engine (关系引擎),Storage Engine (存储引擎),SQLOS。SQL 执行过程就是逐层解析的过程,其中Relational Engine中的优化器,是基于成本的 (CBO),其工作过程跟Oracle是非常相似的。在成本之上也是支持很丰富的HINT,包括连接提示、查询提示、表提示。

SQL Server的授权和服务费用相比于Oracle、DB2略微便宜一些。

4.My SQL(www.xing528.com)

MySQL是一个关系型数据库管理系统,由瑞典MySQL AB公司开发,目前属于Oracle公司,目前最流行的关系型数据库管理系统,在WEB 应用方面MySQL 是最好的关系数据库管理应用软件之一。

MySQL最大的一个特色,就是自由选择存储引擎。每个表都是一个文件,都可以选择合适的存储引擎。常见的引擎有InnoDB、MyISAM、NDBCluster等。但由于这种开放插件式的存储引擎,比如要求数据库与引擎之间的松耦合关系。从而导致文件的一致性大大降低。在SQL执行优化方面,也就有着一些不可避免的瓶颈。在多表关联、子查询优化、统计函数等方面是软肋,而且只支持极简单的HINT。

相比于大型的数据库系统,MySQL功能略显单薄。但该系统是基于互联网数据应用开发的,其应用实例也大都集中于互联网方向,MySQL 的高并发存取能力并不比大型数据库差,同时价格便宜,安装使用简便快捷,深受广大互联网公司的喜爱。并且由于MySQL的开源特性,针对一些对数据库有特别要求的应用,可以通过修改代码来实现定向优化,例如SNS、LBS等互联网业务。

5.PostgreSQL

PostgreSQL是以加州大学伯克利分校计算机系以POSTGRES为基础开发的一个开源的数据库管理系统。PostgreSQL基本包括了目前世界上最丰富的数据类型的支持,其中有些数据类型连商业数据库都不具备,比如IP类型和几何类型等;其次,PostgreSQL是全功能的自由软件数据库,很长时间以来,PostgreSQL 是唯一支持事务、子查询、多版本并行控制系统 (MVCC)、数据完整性检查等特性的唯一的自由软件的数据库管理系统。最后,PostgreSQL拥有一支非常活跃的开发队伍,而且在许多黑客的努力下,PostgreSQL的质量日益提高。

从技术角度来讲,PostgreSQL采用的是比较经典的C/S (client/server)结构,也就是一个客户端对应一个服务器端守护进程的模式,这个守护进程分析客户端来的查询请求,生成规划树,进行数据检索并最终把结果格式化输出后返回给客户端。为了便于客户端程序的编写,由数据库服务器提供了统一的客户端C 接口。而不同的客户端接口都是源自这个C 接口,比如ODBC、JDBC、Python、Perl、Tcl、C/C++、ESQL 等,同时也要指出的是,PostgreSQL对接口的支持也是非常丰富的,几乎支持所有类型的数据库客户端接口。这一点也是PostgreSQL一大优点。

当然PostgreSQL也存在一些缺陷,由于其初级版本是高校开发,产品的学院派风格较为明显,而系统运行的稳定性长期以来没有得到充分的重视。此外,还欠缺一些比较高端的数据库管理系统需要的特性,比如数据库集群,更优良的管理工具和更加自动化的系统优化功能等提高数据库性能的机制等。

4.3.4.2 风电功率预测软件数据库系统选取的原则

风电功率预测软件数据库系统的选取应依据的因素有数据总量、实时数据吞吐量、数据关联复杂程度、数据可靠性要求、软件成本等。

假设某风电场共有100台风力发电机,2座测风塔,每座测风塔分为3层,每层装设风速传感器和风向传感器,此外,每座测风塔均装设温度传感器、湿度传感器和气压传感器。须存储数据包括各台风力发电机出力数据,测风塔温度、湿度、气压数据和各层风速风向数据,气象局NWP数据,包括风速、风向、温度、湿度、气压等预测数据。设每个数据在数据库中占据2个字段,每个字段占8个字节,即一个数据占16个字节,每个数据的采集间隔为15min,每日共采集96个数据。依据规范要求,数据存储的有效时间为10年。依据以上设定,该风电场在10年中,总的发电数据占存储空间535GB左右,总的气象数据占存储空间75GB 左右。再加上风电机组信息和风电场运行状态记录信息,10年间总的数据量不超过700GB,达到中等数据库的规模。依据估测的数据总量,以上介绍的几种数据库均可胜任。

在软件运行过程中,数据的查询和风电功率预测都涉及数据库的吞吐能力。数据查询设计数据量较小,对数据库吞吐能力的要求可以忽略不计;而风电功率预测的数据吞吐量则相对较大。《风电功率预测系统功能规范》(NB/T 31046—2013)中规定,风电功率预测单次计算时间应在5min以内,要满足该要求,不但要求较快的算法处理速度,同时也要求数据库有较好的数据吞吐能力。以超短期风电功率预测为例,要求预测未来4h的风电场发电功率,按照15min采样间隔计算,共需预测16个值。超短期风电功率预测一般依据预测日前1~2个月历史发电功率数据和气象数据,以及未来4h的NWP数据,总数据量为数十兆字节,以上主流数据库均可以满足以上要求。而对于短期风功率预报为例,要求预测未来1~3天的风电场发电功率,按照15min采样间隔计算,共需预测96~288个值。短期风电功率预测所需历史数据较长,通过优化预测算法,大概的数据吞吐量为数百兆字节,但是由于短期预测一天只需预测一次,时效性要求不高,因此以上主流数据库也都可以满足设计要求。

风电功率预报软件的数据包括各个风电机组发电功率、测风塔测量的气象数据和NWP气象数据,数据间没有复杂的交互关系,因此建库比较简单,使用主流数据库系统均可轻松胜任。

作为一个工业系统,风电功率预测软件数据的可靠性要求较高,采用Oracle、DB2、SQL Server等数据库系统的安全性保障当然更高;但是在国内市场,一套风电功率预测软件的报价在数十万元左右,甚至有风电机组主机厂采用买主机、送功率预测系统等销售方式。如果采用Oracle、DB2、SQL Server等数据库系统,则开发软件无利可图,因此国内软件厂商通常都使用My SQL、PostgreSQL 等廉价的开源数据库系统,同时采用双机备份的方式确保数据的可靠存储。这种开发方式节约了开发成本,也降低了用户的使用成本,但由于数据库缺乏后期维护,可能造成系统后期运行速度逐步下降。

综上所述,开发单一风电场的风电功率预测系统, 限于成本原因, 建议采用My SQL、PostgreSQL等开源数据库,但在软件生命周期的中后期应定期对数据库进行维护和整理,提高软件的运行效率和可靠性。而如果开发大范围风电场的综合管理系统,由于数据量巨大、数据吞吐能力要求高、数据可靠性要求等因素,更推荐使用Oracle、DB2、SQL Server等数据库系统。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈