最近在做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. 使用列存储配置的属性和值,当出现统计查询的时候,查询语句非常难写。
|
- 大小: 128.6 KB
- 描述: 方案4
- 大小: 69.8 KB
- 大小: 104.5 KB
分享到:
相关推荐
ITSM-系统建设经验谈,软考之系统规划与管理师可参阅,仅供参考!
ITSM-3-SoA-000信息安全适用性声明[收集].pdf
ITSM-ITIL,相关流程建立过程的文档和工作
教材-ITSM流程流程之CMDB IBMIT服务管理最新 策略及CCMDB发布
ServiceNow-Data-Model-v3.4 ServiceNow 数据模型CMDB,ITSM 数据模型,ITOM数据模型
推荐-ITSM-IT服务目录、服务请求管理、事件分类及变更管理汇总,共4份。 1、IT运维服务目录-组织级.docx 2、IT运维事件分类.xlsx 3、SRM服务请求管理的定义V1.0.xlsx 4、运维变更管理分类.xlsx
IT服务管理,ITIL v4 翻译版,资源来源网络,Share 给大家共同学习...
敏捷 ITSM | 敏捷 ITSM - 基于最佳实践和敏捷文化的用于敏捷... 数据库:虽然重构了敏捷 ITSM,但将仅支持 PostgreSQL 应用服务器:敏捷 ITSM 将独立于 AS/Servlet 容器。 但是,它还依赖于 JBoss AS。 别担心,Agil
IT 运营门户:一个完整的开源、ITIL、基于 Web 的服务管理工具,包括一个完全可定制的 CMDB、一个帮助台系统和一个文档管理工具。 iTop 还提供大量导入工具和 Web 服务以与您的 IT 项目源代码集成已移至 ...
ITSM 运维平台-项目实施方案建议书.doc
ITSM系统-ITSM系统需求规格说明书借鉴.pdf
里面主要包含了一些ITSM的概念和模块功能介绍. 需要了解一下ITSM构成的可以参考一下.
i-doit是一个基于Web的IT文档和CMDB。 i-doit记录IT系统及其变更,定义应急计划,显示重要信息并有助于确保IT工作的稳定和有效:技术文档:这意味着可以组织(详细调整,灵活地)所有信息,存储和维护在一个地方。 ...
remedy组件Asset、change、helpdesk、SLA、AR System的简单介绍
ITSM Enablement-2016-SharingITSM Enablement-2016-SharingITSM Enablement-2016-SharingITSM Enablement-2016-SharingITSM Enablement-2016-SharingITSM Enablement-2016-SharingITSM Enablement-2016-SharingITSM...
商业银行ITSM解决方案.pdf商业银行ITSM解决方案.pdf商业银行ITSM解决方案.pdf商业银行ITSM解决方案.pdf商业银行ITSM解决方案.pdf商业银行ITSM解决方案.pdf商业银行ITSM解决方案.pdf商业银行ITSM解决方案.pdf
CMDB,英文名ConfigurationManagementDatabase,即配置管理数据库,常常被认为是构建其他ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功建立CMDB有非常大的关系。从2000年开始,CMDB开始在国内企业慢慢推广...
U-Center 性能及CMDB U-Center 设备配置管理及BSM U-Center 部署方案及授权 U-Center告警及UEM U-Center增加NTA流量分析任务配置演示课程-2020Q1选修 U-Center增加资源配置演示课程-2019Q4选修 U-Center安装...
i-doit 是一个基于 Web 的 IT 文档和 CMDB。 i-doit 记录 IT 系统及其变化,定义应急计划,显示重要信息并帮助确保稳定和高效的 IT 运行: 技术文档:这意味着所有信息都可以组织(灵活调整细节)、存储和维护在一个...