随着信息化技术的快速发展，云计算、大数据、物联网、移动互联网、人工智能等技术已经融入到我们工作和生活的方方面面，带来了前所未有的便利。电力行业作为我国重要的基础性产业，积累了大量的设计、建造、运营的数据，对这些数据进行组织管理，形成基础数据库，建立电力工程大数据中心，是电力企业数字化转型的关键所在^[1]。

为了实现从电力工程设计到运维的“全产业链”数据赋能，不断把我们企业在电力能源领域积累的认知规律通过“数据+算力+算法”的模式嵌入到物理世界，实现“全面可观、精确可测、高度可控”，助力构建清洁、低碳、安全、高效的能源体系，为实现“双碳”目标贡献力量。以自主可控为原则，采用“大数据+物联网”的新一代数字化技术，围绕电力工程的规划、设计、建造、运营环节，对电力工程项目的共性需求进行抽象，打造电力行业的工程大数据中心。然而，工程项目全生命周期的数据不仅仅是复杂多样的，数据类型从结构化、半结构化到非结构化，数据来源不一、形式不一、标准不一，而且还是海量的，特别是运维阶段的数据。

面对工程中各种复杂多样且海量数据时，系统设计时需要以大数据技术和数据管理理论为基础，通过深入探索分析，采用多种数据库相融合，进而提升多类型复杂数据的管理和使用效率^[2]。本文主要介绍在电力工程行业的某些重要场景下，说明关系型数据库的不适用性，介绍基于MongoDB数据库进行设计建模的优势。

在工程设计中，各专业使用不同的设计软件，如：PDMS、Revit、CAD等，每个软件都有自己的元件库或族库，相同类型的元件有大部分相同的属性，少部分不同的属性，如手动蝶阀和电动蝶阀，它们的相同属性有通径、外径、高度、长度等，电动蝶阀多了一个侧向长度的属性。不同类型的元件的属性差异非常大，有些类型的元件属性只有几个，而有些类型的元件属性甚至有十几个，甚至更多，如蝶阀属性只有五六个，而弯头的属性却有十二三个。并且在不同的设计软件中，相同类型的同一种元件，属性也有可能不同。同理，在运维期的设备也跟元件类似，不同的设备的属性不同，且属性的数量也不同。在MongoDB等NoSQL数据库还没出现之前，数据存储传统的方案一般都是采用基于关系型数据库进行设计，而采用关系数据库进行存储一般有两种较为常用的方案。

方案一：预先定义1张大宽表，也就是非常多列的数据表，这张表预留了多个字符串、整型、浮点型来存储不同的属性，预留列的数量等于设备或元件中最多属性的个数。每个属性单独存储在一列，由于不同设备或元件属性个数差别很大，导致该数据表是一个稀疏表，存储效率低，如图1所示，预留的字段很多是空的。最为关键的是难以保证不同设备或元件的同一类型的属性存储在同一列，如图1，元件A的材料类型（类型：铝合金）存储在str3这一列，而元件B的材料类型（类型：钢）则存储在str4这一列，将无法实现根据材料类型对元件进行过滤查询和统计查询，更无法对预留列建立索引加快查询效率，只能通过全表扫描，在应用层面对数据进行查询和统计，导致效率低，复杂度高。

图  1  稀疏大宽表

Figure 1.  Sparse large wide table

方案二：定义2张数据表，1张为设备或元件基础表（只存储设备或元件的基础通用的共有属性），而另1张扩展数据表，采用按行存储方式存储每个设备或元件的其他属性，即一个属性存储在该表一行，每个设备或文件需要占用多行进行存储，如图2所示。该方案的缺点是扩展数据表的数据量很大，导致查询性能低，如一个电厂的精细化模型，假设构件的数量能达到500万个，一个构件（设备或元件）的属性平均为20个，则扩展数据表的需要1亿行。并且采用该方案无法通过SQL语言查询属性等于某个条件的设备或者元件，如需要查询材料类型为铝合金的元件有哪些，与方案一类似，也只能通过全表扫描，上层应用进行过滤，性能非常低。

图  2  按行存储的表

Figure 2.  Row-stores table

随着数字化相关技术的不断发展，数字孪生电厂或者变电站的三维模型越来越精细化，三维模型的构件数量有些甚至能达到千万个，平均属性个数能达到40~50个，在这种级别数据量，关系型数据库难以支撑，或者需要花费很高的成本和牺牲性能，才能勉强实现，所以需要一种新型数据库来解决这个问题。

在电力工程造价管理的过程中，也会使用到大量的复杂多样的数据，并且需要分布式数据库，才能提升工程造价管理中数据分析、处理等方面工作的高效和准确^[3-5]。而关系型数据库的分布式方案成本较高，因为关系型数据库出现的比较早，当时需要处理的数据量很小，所以在设计之初并没有考虑分布式的情况，需要引入一些组件和中间件才能实现分布式部署，且复杂度大，所以同样也需要一种新型数据库来降低分布式部署成本。

MongoDB是NoSQL类型的文档数据库，是一个基于分布式文件存储的开源文档型数据库系统，是一个介于关系数据库和非关系数据库之间的产品，专为可扩展性、高性能以及高可用性而设计的数据库，是非关系型数据库中功能最丰富且最像关系型数据库的，它支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型^[6-8]。它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引，并提供了聚合、分片和负载均衡等功能，能够通过简单地横向扩展来提高读写性能和大规模数据批处理^[9]。

MongoDB数据库的层次结构跟关系型数据库类似，其层次关系为：一套数据库管理软件可以包括多个数据库，而每个数据库下又可以包含多个集合，每个集合中又可以包含多个文档^[10-11]，如图3所示。集合对应关系型数据库的表，一个文档对应关系型数据库的一行数据，如表1所示。

图  3  MongoDB层次结构

Figure 3.  MongoDB hierarchy

MongoDB数据库具有如下几个主要优点：

1）高性能。存储引擎能够高效使用内存，减少IO次数，提供高性能的数据持久性，索引支持更快的查询^[12]。

2）高可用性。提供了副本集架构，通过类似主从（备）模式，提供自动故障转移和数据冗余。

3）高扩展性。通过数据分片实现方便实现水平扩展，突破单机的存储能力，提升数据的读写效率。

4）强大的查询功能。不仅支持关系型数据库的单表查询功能，还支持强大的聚合计算^[13]。

5）灵活的数据结构。不需要预先定义数据结构和数据类型，支持动态增加文档的字段^[14]。

当然MongoDB数据库也有一些局限性，不适合事务一致性很高的场景，如银行核心交易数据，以及其他涉及财务等相关场景，也不适合涉及多表复杂联查的场景^[15]。

MongoDB数据库不需要像关系型数据库那样必须先定义表结构才能进行数据的存储，并且MongoDB数据库同一个集合里面的每一文档都可以有不同的字段，所以MongoDB非常适合存储拥有不同属性的数据，如，不同的设备或元件只有部分属性相同，大部分属性是不同的，如图4、图5所示。图中以“etattr_”开头是独有属性，它们有不同属性且属性个数相差很大，图4所示元件的是一个窗（一种元件），它拥有的属性只有11个，图5所示元件的是一个钢管（一种元件），它拥有属性却有40个，但它们都属于元件这个集合。图中其他不是以”etattr_”开头属性，是管理这个元件集合的管理属性或固有属性。

图  4  一个集合（窗）

Figure 4.  A set (window)

图  5  一个集合（钢管）

Figure 5.  A set (steel tube)

虽然MongoDB数据库不需要预先定义集合的数据结构，但是直接使用、或者随意使用将会导致数据混乱，如：同一种类型设备或元件的相同属性用不同的数据类型表示，或者采用不同的属性名，将会导致数据标准不统一、后期无法很好地对设备或元件进行查询分析。

为了解决这个问题，系统设计的时候必须为这些设备或元件关联到一个自定义的数据模板，模板定义了相同类型的设备或元件的属性名、属性的数据类型，以保证数据标准统一，当然不同的设备或元件有不同的模板。这个模板其实就是元数据，定义数据的数据，如图6所示，是管接头（一种元件）的部分自定义属性。

图  6  元数据

Figure 6.  Metadata

系统设计的时候可以采用树结构模型对数据进行组织管理，树结构是多层次的组织结构，易于理解、容易管理、扩展。实体数据（是客观存在并可相互区别的事物，对现实世界中事物的抽象，可以是元件，可以是设备，也可以是其他东西，取决使用者对它定义）内置了一些固定属性用于维护基本信息，包括：内部唯一标识、外部唯一标识、数据模板标识、编码、父子关系、层级结构，这些属性的作用如表2所示。其中topicName是较为特殊的属性，记录了当前实体数据在树结构从根节点到该节点的位置信息，也就是这个实体在树结构中的层级信息，它由各个节点的_id组成，以“/”分隔，并对该属性建立索引。它的作用是在查询分析时，能够快速地只匹配实体树上的某个节点下的实体数据。如需要统计某个节点下的各种设备或元件的数量，就可以使用如下的SQL语句进行查询：

SELECT class_id,count(*) FROM entity WHERE topicName like '178/463/%' GROUP BY class_id

除了上面固定属性外，其他属性都属于数据模板中自定义的属性，这些属性存储在MongoDB中时以固定“etattr_”作为前缀，如图4或图5中以“etattr_”前缀的都属于自定义的属性，这个前缀是系统自动加上的，对于使用者是不可见的。系统可以通过开放接口的方式，给其他的应用通过数据模板来自定义具体的实体数据的不同属性，通过数据模板维护实体数据的属性，保证相同设备或元件具有相同的属性名、相同属性类型，避免数据不统一的问题。

相较于关系型数据库，自定义属性除了支持基本数据类型（字符串、整型、浮点型、布尔型、时间类型）之外，还支持基本数据类型数组（Array）、复合数据类型、复合数据类型数组。这些复杂属性的支持在设备树管理中非常有用的，如可以对设备进行分组管理，特别一个设备可以属于多个组的场景，如图7所示，分组属性etattr_tags是一个字符串数组，这个设备有多个组的标签，对“red”组或者“green”组的设备进行个数统计时，可以使用如下语句：

图  7  一个集合（风机）

Figure 7.  A set (WTG)

SELECT count(*) FROM entity WHERE etattr_tags = "red"

SELECT count(*) FROM entity WHERE etattr_tags = "green"

有些读者可能好奇为什么可以通过SQL语句对MongoDB数据库进行查询，因为开发人员或者数据分析人员对SQL语言比较熟悉，系统设计的时候可以提供通过SQL语句查询的功能，它能够将常用的单表查询的SQL语句解析转换为MongoDB数据库的查询语言，便于相关人员对实体数据的统计分析。

基于MongoDB的数据模型虽然有很大的灵活性，但容易引起数据不统一，系统设计的时候可以采用自定义模板对其属性进行约束，既保证了在使用过程中的灵活性，也保证了数据统一，为使用者提供灵活的实体建模功能。

MongoDB数据库作为NoSQL类型的文档型数据库，跟其他类型NoSQL数据库在互联网行业中应用非常广泛，其中包括电商、游戏、社交、物流等行业，但在一些传统行业技术栈的使用相对滞后，通过对MongoDB数据库的学习和研究，结合电力工程行业的数据特点，引入MongoDB数据库作为系统的核心数据库是一个非常好的选择，特别适合解决部分场景下关系型数据库的存储效率低、无法灵活建模、数据量大查询效率低、分布式成本高的问题。