多任务驱动型数据库系统在梅钢热轧的应用

多任务驱动型数据库系统在梅钢热轧的应用

肖瑶 ,余金鹏

（上海梅山钢铁股份有限公司 设备部  江苏南京  210039）

摘要：本文结合梅钢热轧现阶段的数据存储需求，采用多任务驱动的设计思路，将数据根据服务对象进行重新整合，分库分表存放，形成业务驱动型数据库和数据驱动型数据库两类。本文从两类数据库的异同点出发，系统硬件架构设计差异、数据库负载平衡的实现方法、数据库智能监控和数据库索引优化等方面进行详细介绍。

关键词：逻辑处理；多任务驱动；负载平衡；SQL跟踪器

引言

随着梅钢热轧生产经营业务的不断扩展，以及对产品品质要求的逐步提升，2022年梅钢1422mm热轧产线进行了全面系统的升级改造，不仅新增了大量的数据采集设备，同时增加了数据采集密度，由原来的断点采集改为可连成线或面等趋势的存储。以长料为例，单卷钢的一项参数采集个数由200条增加为1000条，有些用于模型计算和板型控制的参数可多达3000~6000条。所以如果沿用原数据库一核心一归档的连锁式架构，虽然可以提供一定的数据支撑参与计算及数据分析，但持续剧增的业务数据，加上存储处理数据的同时还要完成实时事务复制，这将会给生产数据库服务器带来巨大的运行压力，系统响应滞后、数据备份时间长、恢复难度大、表空间需定时扩容等问题逐渐凸显。

为了能更好的保证生产数据的实时调用和参数的完整性，首先对数据分发模式进行升级，由数据库执行事务复制变更为由程序中的事件来实现数据的并行分发，业务驱动型数据库和数据驱动型数据库可按需选择数据，并且利用换辊间隙完成冗余数据的删除，这样可以降低生产数据库的查询数据基数，使数据的存储空间始终保存稳定状态，其次根据两类数据库在使用过程中遇到的系统瓶颈，在硬件选择和配置上进行区分，有效降低系统负荷，保证大数据的查询效率。

一、多任务驱动模式的数据管理

多任务驱动模式是一种提高系统运行效率的设计思想，将由原来单一计算机承担的系统负荷，根据功能、使用频率和时效，将数据进行多点分发，从而使各服务器间负载达到相对均衡，有效降低任务的响应时间，提高系统资源的利用率，使系统的性能得以提高。

          图一：原系统数据流                  图二：多任务驱动型系统数据流

原梅钢1422热轧过程控制数据库系统，采用一核心一归档的连锁式架构，由在线数据库服务器通过复制技术将数据实时同步至数据仓储中心，通过DELECT命令集过滤，确保轧钢数据同步递增，从而实现数据归档。虽然该项操作可以在调用离线数据时，平衡掉一些在线数据库负荷，将在线数据库的存储压力转移至归档服务器，可是触发器本身具备不确定性，执行时容易被外界的系统运行条件所影响，造成锁表或短时数据无响应的情况，为解决上述问题，避免一次转移数据量过大，我们将复制分发动作，上移至程序控制层，改为直接由程序中的logger和loggerwh两个进程节点的内部事件实现实时多数据库的分发。

由于业务驱动型数据库和数据驱动型数据库使用频率和时效性有较大差异，虽然分发初期数据内容相同，但业务驱动主打提取效率，数据驱动则需要通过收集和挖掘大量的数据，实现智能化的模型参数推荐和报表统计。由于生产节奏较快，数据采集量大，因此要严格监控个数据表的大小，数据增长量较快的表进行阈值监控，利用换辊间隙调用存储过程对各表的阈值进行检查，到达阈值时自动删除溢出部分，避免因表内数据饱合造成生产事故。相反，归档服务器和模型服务器，需要满足的是庞大数据基础下的模型调优和产品质量异议时提供有力的参考以及生产回放，为了解决大数据的存储，我们采用的是分段保存，形成一个独立时间段的数据库存储单元，查看数据只需要将软件的数据源修改到相应的数据库存储单元上，既可实现很久以前的数据查找，并且可以在多时间段内自由切换，减少了查询时间。

二、硬件架构设计

业务驱动类数据库和数据驱动类数据库的服务对象和范围有较大差异，统一的硬件配置可能无法最大限度的发挥硬件性能，造成资源浪费，甚至出现因硬件选型不合理，造成系统超负荷运行等情况，我们将数据库的任务内容进行分类整理，从CPU的任务类型区分，内存的缓存释放模式、磁盘使用寿命的提升等几个方面进行综合分析，有效实现硬件的低成本高效率。

2.1 CPU的选择

随着硬件的发展，目前多核CPU种类层出不穷，高主频的CPU技术也日趋完善，如何选择适合现场应用的CPU才是关键。首先要对自身的系统运行情况进行评估，确定数据库所在服务器是任务CPU密集型还是IO密集型。梅钢1422热轧过程控制二层架构数据库系统中每层的任务类型并不相同。

业务驱动型数据库为整个过程控制系统中的数据接收和转发的中枢节点，对现场多方数据请求的实时响应要求很高，需要处理来现场各生产单元的数据插入及提取请求，一个对象要在两个或者两个以上的终端服务器或程序间进行数据处理，此时CPU负载并不高，系统运行多是CPU在等I/O (硬盘/内存) 的读写操作，为解决CPU等待时无法处理其他事务，任务堵塞的问题，我们采用超线程数10%的多CPU并行数据处理模式，在某一CPU被长期占用，任务出现堵塞时，其他空闲CPU自动按序接管，任务处理完成后，继续加入接管等待队列。

数据驱动型数据库服务器包括归档服务器和模型开发服务器，通过对数据的存储、整合和输出，对数据进行集中分层次管理，在保证数据区间完整性的同时，还能够对数据完成不同程度的处理。其中归档服务器上建立内部精度统计分析系统，方便相关技术人员对精度指标进行细化、统计，另外其中还保留较为完整的报表数据、日志等，方便工艺人员进行分类查询，及特殊参数筛选。模型数据库在原系统中是没有的，模型数据没有独立保存，均以日志文件的形式进行记录，不利于数据比对和分析，为解决上述问题，模型数据库应运而生，它不仅实现了大量独立的数据分析处理作业，而且能够通过钢种、规格、轧制需求等进行筛选和自学习。这种计算密集型的任务虽然也可以使用多线程完成，但任务越多，花在任务切换的时间也会随之增加，执行效率也会降低，因此针对上述两种CPU密集型数据库我们选择选择与任务同时执行时相近的CPU核心数，并且运行能力较高的CPU。

2.2 内存管理

SQL数据库进行查询时，统计结果会缓存在内存中，不会马上释放为保证下次提取的效率，但也会因为数据的不断插入，造成内存使用量持续增加。由于业务驱动数据库趋向于时效性，实时数据的提取远远对大数据的查询，为降低内存过大，造成程序挂起的风险，采用控制表容量，通过程序中的特定事件调用存储过程的方式，进行阶段性数据清理，释放内存中所存在的数据缓存,将新的数据继续填充内存位置中,不会增加新的内存空间来存放新的数据,有效保证内存大小，避免溢出。数据驱动性数据库趋向叠加性查询。我们对服务器端除数据库外的占内存较大的服务进行统计，估算所需内存，然后对现有内存进行扩展，根据目前SQL server内存最大值时系统的内存使用情况对分配的最大值进行适当进行增加，根据实际热数据量的30%来规划内存。

2.3 磁盘读写速度的提升

磁盘读写速度分为顺序读写和随机读写，普通的机械硬盘随机读写仅能达到1MB/s而固态硬盘却能轻松突破100MB/s，所以为了硬件性能更好的提升，使用SSD硬盘代替传统机械硬盘是必然趋势，但是固态硬盘有一定缺陷，就是会有使用寿命，为解决此类问题，可以借助一些辅助软件进行物理内存转化，把物理内存虚拟成硬盘缓存用，用内存间接提升硬盘缓存，减少硬盘读取次数，这样就能极大提高硬盘的读写速度。

三、数据库性能优化及备份

3.1数据库智能监控

由于现场工艺需求及功能修改，会造成数据库服务器用户数量增加、用户访问和连接方法改变、数据库内容增加、查询变的更加复杂等情况。为了放在在功能投用前对新增脚本进行测试，我们选择了SQL Server Profile工具，监控可以在“事件选择”中根据需要进行挑选，我们一般采取多套模板，按需切换的模式。在生产过程中进行信息截取时，通常需要控制追踪事件的数量，避免数据库负荷的增加，一般只对数据文件显式增长和收缩，网络中其他主机的连接状态和上线下线时间，以及数据库底层阻塞报警、后台作业异常终止和CPU阈值报警进行。在功能测试环境下，需要关注系统性能和脚本运行状况和影响，为避免多余事件的干扰，一般选择停机时间，对单脚本功能进行测试，并同时在监控软件中对算法是否会造成死锁、事务执行过程中存在阻塞的事件、分布式查询运行和访问接口情况、修改脚本的触发结束时间和表格数据增减量等关键事件进行监控，并将生成的跟踪文件进行保存，对于运行时间超时或异常的事件进行整理，如果异常点不多，可以直接针对设计缺陷进行整改，确保数据库性能稳定，大幅度减少生产后的运行故障。

3.2数据库引擎优化

钢铁企业的过程控制系统，往往都时环环相扣的，一个功能的实现，需要很多区域联合进行修改，也就存在数据调用逻辑及查询模式不合理等情况，但也因为区域负责制的局限性，导致无法及时的发现问题，延长处理时间，为了降低排查难度，我们采用“SQL Server Profile”和数据库引擎优化顾问相结合的方式，将数据监控文档，导入引擎优化顾问中，对工作负荷文件进行系统分析。但由于有时选择的优化内容是针对文件或某一数据数据库表，优化并不涉及表与表之间之间的连接，所以尽量保证现有的物理设计结构PDS，避免出现不必要的卸载操作。优化完成后首先检查“进度”中是否包含警告项，结合警告提示在优化报告中找到对应的原因查找相关日志，将语句开销范围超过80%的语句进行修改，并将索引处理过程中表内数据量过大、查询行数较高的进行数据清理，提高查询性能，并根据软件提供的优化建议逐条确认，将必要项进行采用，从而提高SQL数据库的整体性能。

3.3数据库备份及数据清理

由于业务驱动数据库的大多数表内记录始终在定值的基础上进行更新，为保证异常时，尽可能保证减少手动修改数据，我们编制了数据库自动维护计划，实现每天定时对服务器上的关键数据库进行完整备份，并自动删除一个月前的备份记录。数据驱动数据库因为庞大的数据存储量，无法进行完整备份，应对特殊情况下造成的数据丢失，在增量和差异备份中，我们选择了停机时手动进行差异备份，可以通过原始备份记录比对后再进行备份，确保数据的一致性和完整性，差异备份有一定缺陷，随着时间的变化，差异数据也会越来越多，备份时间会延长，为解决上述问题，我们引入了数据拆分的概念，将数据库按时间段拆分成若干独立的数据库，将每个时间段的初始内容作为对比基数，在每个时间段上进行差异查询，有效控制了备份时长和数据库大小，恢复时也可以逐段还原，能够有效减少处理时间，针对时间过于久远的采用压缩保存，超出保存时效的内容进行删除。

四、结束语

随着大数据技术的普及，原单一数据库服务生产的模式，已经远远不能满足正常的需求，不仅维护成本高，也会出现顾此失彼的情况，为了提高系统稳定性，需要建立多任务驱动模式的多维数据库存储体系，使数据库中数据库的逻辑结构和应用程序相互独立，也包括数据物理结构的变化不影响数据的逻辑结构。实现在同一时间周期内，允许对数据实现多路存取，又能起到防止用户之间的不正常交互作用，保证数据的正确性、有效性和相容性。