配置管理数据库(CMDB)是一种存储配置记录，并贯穿其整个生命周期的数据库，构建一个包含IT基础设施和IT服务逻辑模型的CMDB是进行有效的IT服务管理(ITSM)的基础。CMDB从2方面来体现它在生产环境中的配置信息，一方面是具体配置项，另一方面是具体配置项间的关系。在运维过程中，例如问题管理或者变更管理，都需要从某个具体配置项出发，通过其上的关系，找到所有和它有直接或间接关联的其它具体配置项，从而评估问题的严重程度，或者是变更的涉及范围。关系也就是CMDB能够支持实现关系分析业务功能的关键基础，因此具体配置项间的关联查询应是CMDB为ITSM提供的基础能力之一。

使用关系型数据库作为CMDB的底层存储。使得关联查询在分析具体配置项之间的关联时，需要构造查询语句。查询的条件及关联的层次越复杂，需要构造的查询分析语句也就越复杂，从而导致语句的执行效率越低。最终在大规模环境下，会导致用户在界面上使用关联查询时，经常性得到查询超时的错误，无法正常使用该功能。

本文使用图数据库来实现关联查询的方法。相比关系型数据库，它通过利用配置项间的关系与图数据结构的一致性的特点，将具体配置项及关系映射为图数据库结构，把复杂查询分析语句转换成相对简单的图查询语句，提高了语句的执行效率，同时利用图数据库本身对图数据结构的存储、查询的优化，最终实现了性能提升，缩短了关联查询的执行时间，避免出现用户查询超时的错误。

本文采用Neo4)图数据库，对关联查询模块进行实现。Neo4)是一个用Java实现，完全兼容ACID的图形数据库，它的内核是一种极快的图形引擎，具有数据库产品期望的所有特性，如恢复、两阶段提交、符合XA等。实验结果表明，相比关系型数据库，图数据库能有效解决大规模CMDB关联查询的性能问题。

1 关系型数据库对关联查询的性能影响

在CMDB项目或产品中，对配置项及其关系的持久化保存，使用的是关系型数据库时，以“动态表”的设计方式为例，设计内容简述如下:

在设计中，将配置项称为CI项，简称CI，将具体配置项称为CI项实例，简称CI实例。

首先通过建立CI表(用于定义CI),CI属性表(定义CI上的各种属性),CI关系表(定义CI与CI间的关联)这3者来表达CI及CI关系的结构化建模，如图1所示。

然后，数据库中每新增一个CI，除在CI表、CI属性表中会新增相关记录外，系统还会动态在数据库中创建一个CI实例表，该表的结构由系统根据该CI在CI表、CI属性表2表中的内容动态构造而成。而CI实例间的关系，则由不同的CI实例表间相互的外键关系表达，或是存于单独的CI实例关系表中。

在大规模配置管理库(CI实例个数在百万至千万的数据级上)上，这种基于关系型数据库建模对CMDB的关联查询带来较明显的性能问题，直接体现就是用户在使用关联查询功能时，总是遇到超时错误。

性能问题的原因主要来自以下2方面:

1)数据查询性能低。

关系型数据库一般是面向行集合存储的，它产生了以下问题:

①由于CI上每个属性都可能是查询的条件之一，因此无法对特定的属性进行索引，查询最终会是进行全表扫描，数据查询性能较低。

②数据读取的最小单位为行，因此当查询条件越少，而CI属性越多时，查询条件涉及的有效数据量占整个读取数据量的比重就越少。表中数据量越大，因此而造成对数据查询性能的影响也就越大。

2)CI实例间的关系运算，量大且复杂。

在关系型数据库中，CI实例间的关系是需要通过同表之间，或是表与表之间的数据连接运算计算得出的，它造成以下情况的产生:

①需要依靠程序动态拼接不同CI实例间的关联查询语句，当关联的层级越多时，所需构造的查询分析语句就越复杂，查询性能越低，最终有可能产生关联查询支持不了这么多关联层级的情况。

②如图2所示，当关联的层级关系越复杂时，这种运算量也越大，而这种运算量的增长是可能呈指数关系增长的。当处于一个大规模配置管理库中时，这种运算量可能是无法承受的。

通过上述的性能影响分析，可以得出以下技术能力要求:需要找到一种非面向行集合存储，且关系不依赖计算得出的数据持久化方式，同时能简化查询分析的语句构造。

2 图数据库的引入

图数据库的定义为:以“图”这种数据结构来存储和查询数据，它不是存储图片的数据库。它的基本对象包括:节点、关系、属性、标签、索引。节点由属性的集合构成，节点与节点间通过关系进行连接，标签可以对节点进行分组，数据库可以在节点的属性上建立索引。图数据的存储，是以一种针对图形网络进行过优化的格式保存的。图数据的查询，是以适合图数据结构方式的图查询语言进行。

通过对关联查询与图数据库二者特点的对比，可以看到以下结果:

I)CI实例间关系的数据结构与图数据库所支持的数据结构是一致的。

CI实例间关系可以用图数据结构来建模，而图数据库是专门支持图数据结构的数据库。

2)图数据库满足关联查询的技术能力要求:

①图数据以一种针对图形网络进行过优化的格式保存，它不是行集合的形式，满足“非面向行集合存储”的要求。

②图数据结构上的关系，是被看作图数据中的一部分，以数据的形式直接被数据库进行数据持久化存储，从而使得将关系的运算转换为关系的查询，极大减少了关系的关联分析运算量，满足“关系不依赖计算得出的数据持久化方式”的要求。

③使用图查询语言来遍历关系，避免了CI实例间的查询分析语句的复杂构造，满足“简化查询分析语句构造”的要求。

通过上述的分析对比结果，引人图数据库来实现关联查询，就是一个比较自然的想法了。但图数据库并不是最终要取代关系型数据库，成为CMDB的唯一数据存储方式。图数据库只是在关联查询功能上对关系型数据库进行了有利的补充。

3 关联查询模块的实现 

3.1 关联查询模块的需求

以一个具体的CMDB项目为例，该项目为Web应用程序，使用关系型数据库MySQL来存储数据，采用“动态表”的设计方式建模。图数据库采用Neo4j2.0。需要在这个CMDB项目上松藕合地附加上关联查询模块，同时该模块又不影响CMDB本身的部署和使用。

关联查询模块的数据建模主要解决的是:如何将CI部分的数据建模，实现从关系型数据库到图数据库的映射。CMDB的CI及CI关系的数据建模如图3

对于Neo4)来说，它本身的图模型是较简单的，只有“节点”和“边”这2种，而两者之上可以附加“属性(Property)”和“标签(Lable)”这2类数据。

“属性”为键值对形式，用于描述“节点”、“边”上的属性名称及属性值，一个“节点”或“边”上可有多个属性。

“标签”为附加在“节点”的文字描述，1个“节点”可有多个“标签”。“标签”用于对“节点”进行分组管理，例如可利用对不同“节点”附加同样的“标签”，从达到将多个“节点”分到同一组的目的。

因此，从CMDB关系型数据库的数据模型到图数据库的数据模型的映射就成了“如何将CI及CI实例映射到节点”、“如何将CI间关系及CI实例间关系映射到边”这2个问题。

映射原则归纳如下:

1)"CI实例”与“节点”为一一对应映射，"CI实例”的属性全部作为“节点”属性的一部分，名称固定以“INS”开头。

2)"CI”映射作为“节点”属性的一部分，它的属性作为“节点”属性的一部分，名称固定以“CNG_"开头。

3)"CI实例间关系”与“边”进行映射，如“CI实例间关系”上有属性，则可映射为“边”的属性。

4)"CI间关系”映射为“CI实例间关系”所对应“边”的类型，如“CI间关系”上有属性，则可映射为“边”的属性。

5)“边”是单向的，而“CI实例间关系”允许存在双向，因此，双向的“CI实例间关系”会映射为2条互为相反方向的“边”，而2条“边”的类型、属性完全一样。

虽然Neo4)的编程接口允许在遍历边时，不指定边的方向，这和“双向关系”是贴近的，但和Neo4)的模型及浏览器展示模型中，对“边”的“有向性”的体验是不一致的，因此应强调边的“单向有向性”。

6)以“CI标识”作为“节点”的固定“标签”，以便索引使用，该标识是不会有重复的，名称固定以“CI_”开头。

7)基于查询为查询CMDB当前实际配置情况的业务要求，“节点”、“边”上的属性只会保存当前版本内容，历史数据应删除。

8)为进一步增强数据完整性控制，可在“(Label)CI标识:(属性)CI实例标识”上建立唯一性约束，这和一个CI项中，CI实例标识不可能重复的业务约束是一致的。

图数据索引维护及使用原则可归纳如下:

基于CI实例上属性的变化可能性较低，数据的更新引发的索引更新对性能影响不大，因此会尽可能优先建立索引，以提高大规模CI项实例下的属性查询性能。

1)以“标签[CI标识〕(属性)”的形式为图上的节点属性建立索引。

2)当“属性”的值要参与查询表达式的条件时，应先定位出该属性所对应的CI标识，以便充分利用索引。

3.2 关联查询模块的集成

关联查询模块与CMDB系统的集成方式如下:

1)模块间通过数据集成。

CMDB的配置管理库数据以单向形式，由关联查询模块负责，同步人Neo4)图数据库。这种单向同步形式，使得CMDB系统不需要了解关联查询模块是否存在。

2)用户界面通过页面嵌人集成。

关联查询的前端Web以独立工程存在，以虚拟口录的形式部署，页面链接人CMDB系统的菜单形式运行，使得开发、部署及运行上，关联查询模块都与CMDB模块隔离，但展示形式上，与CMDB模块集成在一起。

通过上述集成方式，使得关联查询模块对于CM-DB系统来说，以一种松藕合、增量添加功能的形式存在。

数据的单向同步方式包括以下3类:

1)定时触发，全量比较。

由关联查询模块的数据同步进程定时将模块中的CI相关数据与CMDB中的CI相关数据进行全量比较，将模块中的CI数据同步成与CMDB一致。

它的逻辑程序较简单，但在大规模配置库下，性能较低。

2)定时触发，定量比较。

由关联查询模块的数据同步进程定时调用CM-DB系统的接口或查询CMDB系统的数据，从而了解CMDB的CI相关数据变化情况，只根据变化的数据将模块中的CI数据同步成与CMDB一致。

它依赖CMDB系统提供的接口，或是需要了解CMDB的CI相关数据的更新逻辑，但由于避免了全量比较，因此在大规模配置库下，性能较好。

3)接口触发，精准同步。

由关联查询模块提供接口，供CMDB在变更CI相关数据时调用，以告知如增加了某一CI实例、修改了某一CI实例间关系等信息，以便关联查询模块即时、精确地了解CI相关数据变化情况，进行即时、准确的数据同步。

它需要CMDB系统的配合，但在大规模配置库下，性能最好。

同步的数据流如图6所示，将上述3种同步触发方式抽象为同类事件，由事件触发数据同步进程，在进程中，按映射原则，将CI,CI实例二者的实体数据映射为节点，将CI间关系、CI实例间关系二者的关联数据映射为边，同时根据索引原则来维护索引，最后更新人图数据库中。

关联查询的数据流如图7所示，用户输人查询条件，关联查询模块将查询条件对应的属性及属性值、节点遍历策略交由图数据库，它根据数据同步时创建的索引定位到节点，并依据遍历策略由边来遍历出所有相关的节点，将得到的节点集交由关联查询模块展示。

关联查询模块的运行架构如图8所示，它可以利用“CI标识”标签对节点的分组，当用户输人的查询条件针对多个CI时，将查询过程拆分成多个查询线程并发进行，每一个查询线程对应一个CI实例的分组，最后将查询结果进行合并展示，进一步提升大规模配置库下的查询性能。

4 实验

为了验证本文的基于图数据库的解决方案的有效性，本文对关系型数据库和图数据库在大规模数据量下CMDB关联查询的性能做了对比测试。

1)数据服务器配置:i7-4700MQ2.4GHz四核CPU,8GB内存，1TB5400硬盘。

2)关系型数据库:MySQL5.5

3)图数据库:Neo4j2.Oo

4)性能需求:对于配置实例数据，能够在用户不指定具体CI项、CI项实例的情况下，用户输人任意属性值，解决方案能够找出所有符合该属性值条件的CI项实例及该实例的相关项。

5)数据规模:CI规模预设为200万、800万这2个级别；CI关联级数预设为2一5级。

6)预期性能要求:800万规模下能在5s之内出结果，并比较与200万规模的性能差距，比较出规模对性能的影响。〕

性能测试结论:1)使用关系型数据库，依赖数据查询进行关联分析，所需时间与规模、关联级数成指数趋势的增长，无法支撑800万级的规模；2)使用Neo4)进行关联分析，测试结果在预期范围之内，能满足将来生产系统的功能和性能要求；3)Neo4)在人口CI实例确定、CI实例间的关系不变、分析范围一定的情况下，关联分析所需时间与CI实例的规模近似无关。

实验表明，图数据库能有效解决大规模环境下关系型数据库CMDB关联查询的性能问题。

5 结束语

本文基于图数据库来实现关联查询的方法，实现了一个大规模配置管理库下的关联查询模块功能。它通过对具体配置项及其关系的图数据建模，将关系型数据库下的结构化、多层次的复杂关联分析查询，转换为图数据库中相对简单的图查询语言中的关系遍历，避免了大规模的关系运算，同时利用图数据库的数据存储特性、属性索引优势，提高了数据查询性能。实验结果表明，本文的方法最终达成了缩短关联查询执行时间的效果，解决了CMDB以关系型数据库存储数据而产生的在大规模环境下的关联查询性能问题。