S1000D研发文档详解第三章.docxVIP

第三章S1000D系统研发物理架构

导语

任何IT系统研发与具体业务系统架构设计，首先要对该系统对象的总体业务架构进行详细调研、用户需求分析和数据存储技术决策分析。S1000D标准中构建了一个公共资源数据库（CSDB）基础理论与概念，其核心要素主要体现在数据信息的存储与输入输出采用数据模块方式，存储对象与输入输出数据信息主要基于XML电子文档标准，数据处理机制为元素（参数）、属性（参数）和XMLSchema模式等作为系统研发的三大要素约束组成。

为了进一步理解S1000D标准中的公共（通用）资源数据库（CSDB）基本涵义，本章将简要介绍其他几种类型数据库基本架构。

一、分布式数据库一般介绍

A、简述

任何IT系统研发，在初始阶段，一定会面临这样一个问题，那就是如何满足构建高效、规范、安全、可靠、可控的计算机信息技术体系的管理要求。

纵观近年来各行各业相关海量数据快速增长，多用户、多频次、远程离线和在线查询等所带来主要挑战是数据掘取、快速处理与响应需求大幅提高。同时，有可能伴随着数十倍的数据交换高峰（浪涌式）压力，以及用户对数据需求复杂度分析、快速响应的诉求增加等。

通常，几十年来的传统数据库在处理此类应用场景时，就数据库技术的扩展性、运行性能、吞吐量和可靠性等方面已经遇到了明显瓶颈，目前采用的主流技术是通过业务拆分、硬件系统扩容、负载均衡技术或设备不断升级、软件体系不断重构等方式来应对，这样会造成企业在计算机设备上不断投入、系统维护和人力资源成本螺旋式不断攀升。

目前面对互联网大数据技术业态不断发展，各种数据信息交互和存储也呈现几何级数增长情况下，首先要针对S1000D标准和规范定义下的数据产生、维护，和IT系统如何去管理和应对，应该有个比较清新认识才行。

§、基于S1000D标准的数据产生与存放，所对应的基础数据模块（DM）生成，若是按照数据模块编码（DMC）所构成数据模块数量（简单数量）来看，文件个数的饱和容量可能为36位字符的17次方---36位字符的47次方之多，这仅是数据信息对应的文件名要素（编码资源），其中还要包括数据库系统本身运行的物理资源占有。由此类推到文件个数所对应的具体文件（XML）内容将作为同等重要信息数据保存下来，期间还要面临不断新增、修改等处理过程，可以预见到这样基于S1000D标准的数据量可能生成，无疑对用户而言无疑是个天文数字，也可以说是真正的大数据。如果有了这样清醒的认识，将来在系统预可研调查阶段、体系设计、架构部署和研发实施过程中，对系统项目研发团队的每个成员，都要做到对数据量产生和维护保持高度一致性数据信息控制和信息编码作为一种资源的控制。

§、由于S1000D标准制度下的数据量极为庞大，传统数据库（关系型）技术可能已完全无法应对，由此而影响到如何保证业务连续性，成为本文解决的关键回应。

在此形式下，采用分布式数据库就比较合理而且安全，因此在数据库的选型上，根据不同的业务场景和关键系统中选择不同的开源产品，通过对开源数据库的深入研究和应用，要求能够实现和基本满足了基于S1000D标准体系下的业务场景的事务处理和数据处理的要求。

§、S1000D标准针对数据存放、抽取和查询进行了详细定义，包括数据格式定义和标准、数据库构建例名、公共资源数据库（CSDB）、数据模块（DM）与数据模块编码（DMC）、数据存放格式等。其中数据存放格式包括XML、关联表（TAB）、主流多媒体文件、各种主流文档（Word、JPG、Excel、PPT、CAD等）等。但是，S1000D标准并没有就如何选择何种数据库来存放相关数据进行论述和提供建议，考虑到用户若是基于S1000D标准来研发系统，需要存放依据标准规则产生的海量信息编码和该编码串所关联的文件等，而这些文件生成和存放采用离散形式，同时S系列标准又有非常多基于关系型技术的关联字典。

B、传统数据库技术约束

一般而言，传统分布式数据库面对企业级应用，主要特点是该体系是运行在各种关联服务器上，面对采用互联网技术接入的用户会随着用户相应的数据量急剧增加，传统的关系型数据库在可扩展性的弊端日益显现，具体表现如下：

--软件支持系统随着用户业务增加、逻辑变更将面临系统需要不断重构的重大风险；

--单点运行风险高，容灾容错能力差；

--远程网络处理性能大幅下降，原因是单点数据库系统无法及时处理用户大规模并发请求和复杂数据信息计算；

--硬件设备投入不可预测，后期系统扩容难度极大；

--存储能力限制，一般只能纵向单域扩展，不能横向跨域扩充。

C、分布式数据库释义

通常就数据库技术本身而言，传统分布式数据库都会具有各自特色软/硬件集群解决策略。但若从纯技术角度切入来看，这些都不能被称之为具有真正技术意义上的分布式，只是仅为了解决了快速响应具体场景下数据库负载均衡问题。而这样负