论分布式化验数据库系统的设计与实现
论分布式化验数据库系统的设计与实现
摘要:
在国外恶劣的网络环境基础下,我所在的国外矿业企业需要自行定制一个化验数据库系统,该系统需要完成公司在海外工厂三个矿山和一个冶炼厂的化验室各自各个生产阶段和各个环节矿物质及其他化学元素化验数据录入,审核,报出,分析,各级别报表等功能,同时还要完成海外事业部和国内总部接收各种报表的功能。作为系统总设计师,我采用了分布式数据库的设计和开发思想,并指导完成了数据库的设计和实现,本文通过论述我主持设计开发该系统的过程,阐明分布式数据库系统如何将系统数据分布在不同地点的多个服务器,并完成不同据点间的化验数据同步、互联和共享。并最终证明在不稳定网络环境下,分布式数据库系统是比较可行而且有效的。
正文:
2016年,我所在的矿业公司已经初步完成了在海外两个矿山和一个冶炼厂基础设施的,并从2016年1月份开始试车运行,并预计2018年正式投产,两个矿山到海边的冶炼厂之间分别通过将近50公里的矿桥管线输送矿浆,该海外国家属于非常贫穷落后的国家,根本无法使用当地的网络资源实现矿山、冶炼厂、当地办事处、北京总办事处之间的Internet互联,所以公司在建设矿桥管线的同时,也一同沿着矿桥管线建立了光纤网络通道。来实现矿山、冶炼厂之间的网络互联,而当地办事处和北京总办事处通过卫星网络实现与三个现场互联,但是由于当地人文环境极差以及地理环境的问题,光纤通道经常被自然环境拉伤或者被人为破坏,加上检修的复杂和困难性所以内部局域网也存在不稳定的因素,而卫星网络资源的稀缺与真个海外据点共享仅仅4M的宽带资源,所以整个网络环境异常差。在此环境下,公司高层为了更好的把握矿浆的质量以及冶炼的效果,并以此调整各个环节机器的技术参数及生产机能,要求IT部需要在正式投产后需要准备好配套的化验数据库系统,然而目前并没有可参考的类似系统,加上公司在基础建设上的成本太高,以至于无法请国内的或者国外的专业团队来进行开发实现,而且专业团队开发的周期也很长,最终IT内部决定采用自行开发的策略,考虑到恶劣的网络环境下,我们决定采用分布式数据库方式来开发该套系统。
一、需求分析
以公司总战略为基础,以公司利益为核心,我们组成了以公司技术副总为总指挥的分布式化验室系统开发团队,包含了管理组、软件组、硬件组三个主要分支,而作为管理组的实际负责人,根据实际网络现状,我们定义了现场三地在局域网联通的情况下,则优先通过快速的局域网直接互联传输,当局域网断开的情况下,与事业部和总部之间统一通过慢速的卫星网络定时传输。
需求分析之初我们就朝着分布式数据库方向考虑实现该系统,意味着在各地需要部署局部独立的服务器,现场可以独立的直接存储单个据点需要的相关的化验数据,然后通过网络进行定时的传输其他据点需要的数据,在此前提下我主要通过联合需求计划和实地考察(现场三地)的两种方式,我们通过逐步的整理和分析得出初步的各地数据库信息要求、处理要求、安全性和完整性要求。并依据公司战略目标,经过可行性分析,得到比较完整的数据模型,并从而得出相应的数据实体输入输出,最终形成数据字典,并形成需求文档提交上级部门审批,并顺利得到通过。
二、数据库设计
虽然SQL数据库具备了分布式存储功能,该功能可以通过在网络环境优良的情况下可以使多地的服务器可以实现自动复制功能而达到真正的物理位置透明性,并能很好的进行互联共享,但是各个据点的网络环境并不具备该条件,同时因为有些数据只有本据点需要使用,而对于其他据点没有任何意义,因此我们采用的各地自治加必要信息共享模式来完成各地之间的互联和共享,当然,我们需要额外开发数据传输中间件来进行各地数据定时传输,具体设计过程如下:
- 通过对需求分析进行相应的数据库字段解析,得出共同数据信息,如账户信息,部门信息,设备基础资料。
- 确认各地之间的共享和私有字段,基本原则为数据录入地为原始数据产生地,其他据点按照需求设定共享字段,其中现场三地流通的数据不需要审批,但是流入事业部及总部一定要经过审批的数据。并最终决定以现场主要领导驻点的冶炼厂为中心,同时作为重要数据集中管理点,矿山和冶炼厂数据互相共享,事业部及总部统一由冶炼厂经分析和审核后传输。
- 确定具体共通数据库字段以及私有字段以及关联约束等信息。
- 消除冗余,优化数据结构。
5. 确定共享信息传输规则,包括传输优先级,传输方式,传输频率等,原则上共同的数据信息系统默认设定传输,而其他相关的实际业务数据由用户自行定义传输规则。
考虑到各个据点之间接收其他据点的共享数据方便转换,所以我们同时决定提供通过应用程序进行字段释义功能,即很容易将其他据点接收到数据转变成自己可理解的字段含义。
同时我们也制定了详细的数据库设计文档,以便后续实际应用程序开发参考和检阅。
三、系统实现
根据数据库设计文档,我们软件开发组先建立实体数据库,并建立相关索引,然后开发相应的应用程序,因为考虑到各地数据库具有独特性,必然前台界面显示也会随之不完全一致,因此我们采用的是基于构件的开发方法,开发出的构件通过配置接口可以适应各地数据库的独特性,最后我们开发出了数据传输中间件,用户可以自行定制服务器地址,端口,传输字段,接收模式,接收频率,优先级等, 具备了传输,接收,验证和可审计功能。同时我们硬件组也申请购买了各地相应的服务器及相关网络设备。并于投产日,2018年8月30日前完成了正式使用前的各项功能性和非功能性测试。
系统实施后基本完成了既定的需求目标,但是同时也暴露出不少问题,主要的问题包含以下3点。
1,数据字段释义的正确性,因为我们当初为了方便用户设定,开发了释义功能,所以需求分析的时候并没有专门对特有字段进行详细的注释,但是实际上线后,各据点并不能完全了解其他地点的具体检测项字段的含义,造成个据点之间数据、汇总报表和分析报表难以融合和理解,后来我们又专门组织相关专业人员针对各地的自定义字段进行统一的释义和解答。
2.在现场局域网断开的情况下,网路切换出现了问题,正好上线之后的第3天有一个矿山到冶炼厂的光纤被拉伤不能传输数据,但是并没有自动切换用卫星网络传输,网络组针对此做了相应的优化,使得服务器自动切换网络,同时软件组也对应的做了网络故障感知程序和自动检测网络并重新传输。
3.各据点因为网络传输等问题,造成传输和接收数据不一致的时候没有人性化的通知,最终我们优化了传输检测功能,即各地添加一个数据表专门记录传输情况表,对方接受到数据后,返回接收情况,发送放通过时间戳对比确认是否完全接收,如果没有接收完全或者错误将以邮件的方式通知相关人,并由他手动再传送。
总体来说,该项目给了我在网络非常不稳定或者很差的环境下分布式数据库设计的一种思路,并通过该项目证实了其可行性和有效性。

浙公网安备 33010602011771号