现如今, NoSQL数据库 与关系型数据库往往并存于企业的数据架构中。但是在NoSQL的数据管理方面,还缺乏像管理关系型数据那样成熟的方法与工具。
当前流行的NoSQL数据库在设计时更多地考虑了应用程序的性能,而较少考虑到高层业务模型、数据的集成以及数据的标准化。对于NoSQL数据库来说,其数据建模与物理数据之间存在着一条明显的鸿沟。
在本文中,我将介绍一种利用统一数据建模技术管理NoSQL与关系型数据库的方案。统一数据建模支持多种特性,例如为NoSQL数据库的模式生成文档,以及对现有数据库中的数据进行反向工程。它同时也支持对现有数据库的可视化表现。
随着数据在4个方面的增长(数据量、多样性、速度以及值),数据的管理方式也发生了转变,从纵向扩展变为横向扩展,通过几十万台小型的服务器创建分布式计算应用,以取代单一的强大机器。为了支持分布式计算的需求,数据也必须转换为一种不同的模型。
当前的关系型数据库都支持第3范式。对于ACID(原子性、一致性、隔离性与持久性)事务模型,如果一份数据在数据库中只拥有一个拷贝,那么更适合使用关系型数据库。这意味着任一时间内只有一份拷贝会更新。但对于来自多个不同应用的查询,数据必须进行聚合。因此,为了满足业务需求,数据必须进行分布式处理,而数据模式也必须进行反范式化。在设计模式时,必须允许进行分布式的查询,这就需要处于不同数据节点上的每个数据集必须包含足够的信息,能够独立地执行查询。
基于以上特征可知,创建NoSQL数据库时的基本要点在于通过逻辑模型描述业务需求,并通过反范式化的模式对应实际的数据模型。而不是在没有数据建模的情况下直接从程序向NoSQL数据库中写入数据。
此外,由于数据的多样性将进一步提高,因此在灵活性方面要能够匹配数据的原生格式,使其能够保存在 文档 、 图形 或 键值 数据库中。在敏捷的业务场景中,数据的结构也将产生改变。但预定义的强模式将受到这种业务场景的限制。在关系型数据库中,对现有数据列的更改或是新建数据列操作将造成数据表的重建,但对于NoSQL数据库来说,添加新的属性或组合对象操作都非常灵活。
另一方面,在NoSQL中写入数据前也无需强制使用预定义的模式。而在读取数据时,模式的应用表现为用户以原始形态加载数据,在读取后就可以按需求随意变换。对于数据的读取与理解来说,模式是必需的,但这对于使用Map Reduce程序,而又并非开发人员的使用者来说是一个不小的挑战,因为模式在Map Reduce程序中是隐含的,因此大多数DBA与数据分析师无法访问与理解这些模式。正因为如此,数据建模就成为了更好地理解企业数据的关键因素。
此外,与传统的批量数据集相比,流数据的处理又提出了不同的要求(实时性,只增性等等)。为了支持多个并发式数据处理系统的需求,数据本身或许还要进行某种形式的转换。在数据分析过程中,数据模型能够帮助用户理解数据,并调整数据结构。根据数据模型的设计,数据集成系统能够从原始的流数据中萃取出维度数据,并导入数据仓库中。
因此,为了让基于RDBMS与NoSQL数据库的数据架构满足业务上的需求,数据模型扮演了关键的角色。
RDBMS中的ACID(原子性、一致性、隔离性和持久性)特性是数据库方面最重要的一种需求,这种重要性在今后也将继续。而在未来,RDBMS与NoSQL的混合使用将成为企业架构中的一种典型场景。Unified Modelset(统一模型)将用于描述RDBMS与NoSQL数据库的数据模式。
以下是RDBMS与NoSQL数据库之间区别的简单总结。
要在不同的业务场景中管理关系型与NoSQL数据库的区别,并充分利用他们的功能,这是一个极大的挑战。因此,我们需要一种统一的方式以管理这些数据库。
CA ERwin Unified Data Modeler支持对RDBMS与两种主流的NoSQL数据类型(文档数据库及列族数据库)进行数据建模。它还支持数据发现以及RDBMS与NoSQL数据库之间的数据迁移。
Unified Modelset为业务需求及实际数据模式的文档化提供了一个良好的方案,并且能够管理RDBMS与NoSQL数据库中的数据。
逻辑、RDBMS与NoSQL数据模型基本概念的对照
概念 / 逻辑 | RDBMS | NoSQL |
---|---|---|
实体 | 表 | 集合或列族 |
实体的实例 | 行 | 文档或行 |
属性 | 列 | 键或列 |
某个实体实例的属性 | 单元格的值 | 字段值 |
领域 | 数据类型 | 数据类型(某些NoSQL数据库没有定义数据类型,所有的值都是纯文本。) |
关系 | 约束 | 引用、嵌入或附加表 / 跨多个行的列族。 |
键 | 索引 | 索引、附加表或引用 |
唯一标识符 | 主键 | 行键 |
业务概念与需求可以由逻辑模型进行描述,而后者又可以转换为目标物理模型。转换过程取决于在逻辑模型中描述的查询模式和数据生成模式。转换规则已预定义为模式转换策略,具体会影响到哪种策略决定于描述查询模式和数据生成模式的标签。这些标签与规则都可以由用户进行修改和自定义。在该过程的最后,原始数据将按照所设计的物理模型进行格式化,并以正向工程的方式迁移至数据库中。
使用Unified Modelset的业务场景:
以下是为某个电影资料库所设计的数据库示例,业务需求如下所示:
在概念/逻辑模型中,可以辨别出以下实体及关系:
图3是一个由ER图所描述的电影资料系统的逻辑模型图,而图4则是由ER图所描述的物理RDBMS模型图。
不过,现有的ER图并不足以对NoSQL数据进行描述。因此,我们创建了Unified Modelset,以支持对于RDBMS与NoSQL的数据建模工作。它能够对业务模型、查询模式与数据生成模式进行描述。该模型由一个逻辑模型及多个物理模型组成。
图6是上文所述的电影资料库这一示例的逻辑模型,在实体与属性中还附加了一些标签,以描述数据的查询模式与生成模式。
在 MongoDB 或 Couchbase 这种文档型数据库中,与数据库对象相关的一切都被封装为一个文档对象。
图7是文档型数据库的物理模型图。它的表示法表现出了真实的数据结构(文档与嵌套文档)。图8展现了对应MongoDB所设计的模型中的真实数据,例如Actor和Category文档就嵌套在Film文档中。
列族数据库也是NoSQL数据库中的一种,它以列的形式描述了相关的数据。可以理解为在一个元组(对)中包含了一个键值对,其中每个键都映射到一个值,而这个值是由列的集合所组成的。
典型的列族数据库包括 HBase 和 Cassandra
图9是上文所述的电影资料库这一示例的物理模型图。
查询模式对于NoSQL数据建模来说至关重要。如何将逻辑模型反范式化为物理模型取决于数据的查询方式。因此必须在数据模型中描述查询模式,而在数据模型中经常对多个实体一起进行查询。这些实体需要在NoSQL物理数据存储引擎中进行聚合。
生产数据模式是用于描述数据库在生产环境中的物理特征的一种方式。
由于NoSQL数据库不支持模式,因此数据模式必须从原始数据中进行推断,而不是直接从RDBMS等数据库中直接抽取出来。模式推断的方法有以下几种:
我们现在已经可以用Unified Modelset描述企业数据架构,包括逻辑模型中的业务需求以及物理模型中的数据模式了,现在我们要进一步扩展其能力,基于数据模型实现数据发现。UDBC(统一数据库连接)为我们提供了一种接口,以描述基于Unified Modeler的外部企业数据。
王峥 (Allen Wang)是来自CA technologies公司ERwin研发团队的总监,负责ERwin在全球范围内的研发以及ERwin Unified Modeler产品的管理。他领导团队成功地发布了自8.0开始的8个重要版本。他还是工业标准委员会OMG与DAMA的成员。他策划和建立了CA与清华大学合作的大数据研究项目,致力于帮助产品进入新兴市场,专注于企业中复杂的大数据环境,通过统一模型与数据挖掘等技术管理数据。他还提交了5个关于数据建模与NoSQL方面的专利。此外,他还是复旦大学的客座教授,开办了大数据方面的硕士研究生课程。本文的顺利发布还要感谢ERwin开发团队的贡献与Xiaoyuan Yuan的编辑。
查看英文原文: Unified Data Modeling for Relational and NoSQL Databases