ITSM-CMDB数据库设计-四种方案任你选

   最近在做CMDB的数据库设计方案，有4种方案，各有利弊，我选方案3，大家可以讨论下，或者有什么更好的方案，请指教！ 
  

 

术语	英文全称	说明
配置管理数据库(CMDB)	Configuration Management Database	它是一种包含每一个配置项全部关联细节以及配置项之间重要关联细节的数据库
配置项(CI)	Configuration Item	配置项信息覆盖了企业网络中的应用、操作系统、补丁、硬件设备、生命周期成本以及用户链接
配置项分类	Configuration item category	配置项所属分类，如数据库，主机

 

设计难点：每个配置项分类的属性会不一样。如数据库有管理员名称和管理员密码属性，显示器有分辨率和尺寸属性。 数据库是配置项分类，分辨率是配置项属性。

 

 

1：方案一：动态字段数据库设计

 

 

 

 

 

方案说明：

CMDB由三个实体组成，即配置项，配置项分类，配置项属性定义。

每增加一个配置项属性，会动态的在配置项表里增加一个扩展字段，扩展字段以EP作为前缀。

没删除一个配置项属性，会动态的在配置项表里删除这个扩展字段。

所有扩展字段必须可空。

方案优点：

灵活，且方便查询。

方案缺点：

1：需要建立表分区：当配置项达到上千万的数据的时候，为了提高性能，必须在配置项表的配置类型字段上建立表分区，而不是所有的数据库都支持表分区。但当数据量在百万左右的时候，可以通过建立索引来挺高查询性能。

2：配置项表扩展字段太多：因为每增加一个配置项属性，就会在配置项表增加一个可空字段，所以配置项表的字段会非常多，预计最多在1000左右。所有的数据库对单列的长度都有限制，如MySql单列字段长度为65535。

 

 

 

2：方案二：动态表数据库设计

 

方案说明：

CMDB由三个实体组成，即配置项，配置项分类，配置项属性定义。表结构类似方案1。

为每一个配置项分类（叶子分类）建立一张表。如为数据库，路由器，防火墙单独建立一张表

方案优点：

性能高：数据按照配置项分类存在不同的表里插入和查询效率高。

方案缺点：

1.         需要创建的表非常多。如果管理粒度非常细，需要创建几百张表。如到windows操作系统，锐捷路由器这一层。当配置项的数据达到千万级的时候，有的配置项表也会达到百万级。

2.         需要动态创建表，随着管理粒度的细化，需要动态创建表。如项目一期的分类为三层，即硬件-设备-路由器，然后到项目三期的时候分类变为四层，即硬件-设备-路由器-Ruijie路由器（cisico,juniper,huawei）

 

 

3：方案三：固定冗余字段数据库设计

 

方案说明：

CMDB由三个实体组成，即配置项，配置项分类，配置项属性定义。

在配置项表里增加200个固定的冗余字段，并在”配置项类型和属性关系表”里增加一个字段，建立属性和扩展字段之间的关系，据实际情况表明一个配置项分类的扩展属性不会大于200。

冗余字段里以FS作为前缀的字段表示字符串型，FN表示数字型，FD表示日期型。

冗余字段的分配比率为FS>FN>FD 5:4:1。

相对于全部使用字符串存储的优势在于整个表的体积会缩小。缺点在于分配时比较麻烦，有可能出现某个类型不够的情况，如date类型不够用就得用String字段。

冗余字段的长度：原则为定义为各个数据库能够容纳的最大值，将FS定义为varchar2000 ( 各数据库最大长度为 SQLserver的varchar  8000，mysql的 varchar  65535，Oracle的varchar最大2000，varchar2最大是4000)。

在存储上不会受影响，因为varchar是可变长存储的。查询和插入上的效率取决于存储数据的大小。

各控件的数据存储：

文本框是数字型的存在FI里。

文本框(input)，复选框（checkbox），单选框（radio），下拉框（select），文本域(textarea)全部存储在FS里。如果出现数据字典的键值对，直接存值，如1=上海，2=北京，3=福州，直接存上海，北京，福州。

日期控件(date)，存在FD里。

 

删除某个属性时，需先删除属性和F_N的关系，再删除F_N列的数据，F_N列都是可空列。

方案优点：

方便查询。

且规避了方案一的配置项表扩展字段太多的缺点。

方案缺点：

没有方案一灵活

 

 

 

4：方案四：固定表和字段数据库设计

 

 

方案说明：

CMDB由两个个实体组成，即配置项（含配置项分类），配置项属性定义。

配置项属性的值存在“配置项类型和属性关系表”里。

方案优点：

简化了设计。

配置项也可以动态增加扩展属性。

方案缺点：

1.         配置项和配置分类放在一张表里，频繁的查询配置项分类存在性能问题。建立索引能够解决性能问题，但是配置项的表是千万级数据量，在多个字段处建立索引，会导致索引文件非常大，并且影响数据查询性能。

2.         使用列存储配置的属性和值，当出现统计查询的时候，查询语句非常难写。

 

评论

3 楼 fantasy 2013-12-05  

leonevo 写道

hi, 我也在设计cmdb. 我觉得基于传统关系数据库有很大的局限性，如果引入nosql, 如neo4j这样的图形数据库，它天生就是处理节点可扩展属性，以及节点间的关系的，则可以跨过很多关系数据库所难以实现的问题。如果你还对cmdb设计有兴趣，能不能一起交流一下？

leonxinyu####gmail`com

不好意思，现在不研究这个了

2 楼 leonevo 2013-11-30  

hi, 我也在设计cmdb. 我觉得基于传统关系数据库有很大的局限性，如果引入nosql, 如neo4j这样的图形数据库，它天生就是处理节点可扩展属性，以及节点间的关系的，则可以跨过很多关系数据库所难以实现的问题。如果你还对cmdb设计有兴趣，能不能一起交流一下？

leonxinyu####gmail`com

1 楼 fantasy 2010-10-20  

有其他方案的同学，请阐述方案的优缺点。谢谢