NoSQL数据建模

这是来自电子商务公司EBay的一篇博文。

良好有规律的关系数据库RDBMS数据建模已经存在很多年，从逻辑到物理的映射技术已经被广泛专业人士实践使用，然后，随着最近出现的NoSQL数据库，数据库建模面临相关挑战，一般来说，NoSQL实践者关注物理数据模型设计，而不像传统的概念/逻辑数据模型，原因如下：

第一. 以开发者为中心，使用NoSQL数据库支持的灵活的Schema(或者schema-free)，应用开发者通常负责数据模型的设计，他们有认识到数据库表结构Schema是应用逻辑的最主要部分。

第二.运行在大规模可扩展的分布式环境中对高性能查询的考虑，与传统集中式垂直伸缩的系统包括RDBMS层，现代应用是运行在一个分布式，水平伸缩的环境，为了完成水平扩展，应用开发者通过关注物理数据模型设计能够解决可扩展性和性能问题，因此，放弃了传统概念和逻辑设计以及传统物理数据模型设计的过程。

第三. 大型且非结构化数据，严格的固定的Schema(表结构)和有限的水平扩展能力，传统关系数据库因此一直被批评为却反对大型和非结构化数据的支持，相比而下，NoSQL数据库使用灵活的Schema在分布式水平扩展的环境中存储大量且非结构化数据是其特点。

开发敏捷 vs. 数据库可管理

在今天NoSQL的一个高度吹捧特性是应用程序开发的灵活性。这种灵活性是通过灵活Schema实现的，通过灵活的甚至很简单表结构，开发人员可以完全控制NoSQL数据库是如何存储和组织数据。开发人员可以不需要依靠DBA在应用程序代码中创建或修改数据库对象。结果导致了事实上,增加应用程序开发和部署的灵活性。

然后，灵活Schema并非没有挑战。例如，动态创建数据库对象会引起不可预见的数据库管理问题，因为缺乏DBA的监督。此外，无监督模式变化会增加DBA诊断相关问题的挑战性。经常发生的的故障诊断需要DBA审查编程语言编写的应用程序代码(如Java)，大多数dba不具备这个技能，他们一般只是使用RDBMS DDL(数据定义语言)。

NoSQL业务和数据模型设计过程

在传统的软件工程领域，好的业务和关系数据模型设计是中大型项目的关键，而作为NoSQL开发者是业务和数据模型设计者，这样一个难题就出现了：数据建模工具。传统关系数据库的逻辑和物理数据模型是由专业人士使用的商业工具，比如PowerDesigner或ER/Studio。

鉴于NOSQL是一个新兴的技术，当前并没有这样一个专业品质的数据建模工具，让主管者审核应用开发者的代码来获取数据模型代码也不是一个普遍办法，这对于非技术用户如企业主或产品经理是非常离谱的，其他方式如从产品数据库中抽样数据也是辛苦和乏味的。

很明显，需要大量投资必须的自动化工具，以帮助缓解这一挑战，我们建议使用NOSQL项目的业务和数据模型设计过程如下图，以MongoDB文档中心模型的数据库为例子：

• 业务需求 & 领域模型: 在这个高级层次，人们可以使用与数据库无关的方法，如 领域驱动设计domain-driven design,用来捕获和定义业务需求。
  
  
• 查询模式 & 应用对象模型: 当业务需求和领域模型已经产生后，人们能够迭代并行地分析用户访问模式和应用模型，这可以通过使用 UML类图或对象图实现. 对于关系数据库 RDMS, 应用程序可以通过声明式的查询如单个SQL表 join或一个导航方式(在应用逻辑中嵌入独立的表遍历方式)等实现. 后者需要一个对象-关系数据库映射 (ORM)层 来避免乏味的管道工似的琐碎工作。很自然，大多数NoSQL数据库属于后者，MongoDB能支持JSON文档模型和SQL-subset query两种.包括复杂的第二索引能力。
  
  
• JSON文档模型 & MongoDB 集合Collection / 文档Document: 这部分是原生物理数据模型所在，人们得懂得特定的 NoSQL产品的特长和弱点。这样才能产生有效的schema设计，实现高性能查询。举例，建模社交媒体实体模型如followed 和 followers是与在线博客应用建模非常不同的，一个社交媒体是使用图NoSQL数据库如Neo4j实现, 而在线博客应用最好使用其他风格NoSQL如MongoDB实现。
  

RDBM数据建模对NOSQL的影响

有趣的是,传统的RDBMS数据建模技术对于那些新的NoSQL仍然存在有意义的作用,。以使用文档为中心的MongoDB作为一个例子,下面的图表说明了如何将关系数据模型映射到一个类似MongoDB以文档为中心的数据模型:

NoSQL数据模型的变化

在关系数据库世界，逻辑数据模型可以兼容不同RDBMS产品。在物理数据模型中,设计规范,如存储条款或非标准的SQL扩展可能因供应商不同而不同。各种SQL标准,如SQL - 92和最新的SQL:2008年由行业组织如ANSI / ISO定义，它们使得在不同的数据库平台上保证应用程序的可移植性

然而,在NoSQL的世界里，不同的NoSQL数据库之间的物理数据模型显著不同;没有行业标准与RDBMS的sql - 92。因此,理解各种NoSQL数据库模型的差异变得很关键:

• Key-value存储 – 带有唯一key可以用1-n 有效值
• 列族 – 分布式数据存储在一个列中，该列由一个唯一key，以及该key的值组成，还有一个时间戳，用来区别新旧值。
• 文档数据库 – 系统以文档存储和管理和它们的元数据(类型type, 标题title, 作者author, 创建/修改/删除日期, etc.)
• 图库 – 系统使用图论来代表和存储数据，包括节点(people, business, accounts, 其他实体), 节点属性, 和边缘 (节点属性彼此连接的线性关系)
  

NoSQL复杂度:

值得一提的是,NoSQL数据模型的一个自然的从简单的键值存储到高度复杂的图形数据库进化路径,如下图所示:

NoSQL数据模型的虚拟化

对于概念数据模型，表示实体关系等图表技术可以继续被用于模型NoSQL的应用程序。然而,逻辑和物理NoSQL数据建模需要新的思维，因为每个NoSQL产品有不同的原生结构。可以直观地使用下列三种可视化方法，使用MongoDB这样的以文档为中心的数据模型为例：

（1）.带有嵌入子文档支持的原生MongoDB collection 虚拟可视化放，如Figure 2above)

优点：这自然地通过一个直观的可视化表示表达了一个复杂的文档模型。

缺点：没有专门的工具支持,可视化结果只能特别使用非均匀约定或符号。

（2）.使用JSON Designer 抽样文档进行反向工程，如下图

优点：–它很容易从现有的JSON文档存储在NoSQL数据库如MongoDB进行反向工程层次模型可视化表示

缺点：JSON Designer 目前只能在iPhone / iPad。此外,它不包括本机数据库对象,如MongoDB索引。

（3）,传统的RDBM数据建模工具如Powerdesigner。

　优点——商业工具支持。

　缺点——它需要繁琐的手工准备和图表安排用来代表复杂和深度嵌套文档结构。

新的NOSQL数据建模机会

像其他新兴技术,NoSQL将成熟成为主流。我们设想以下新的NoSQL数据建模的机会：

• 可复用的数据建模设计模式来帮助降低应用开发难度和消耗。
• 统一的NoSQL建模仓库支持各种NoSQL产品。
• 双向的,双向工程支持(数据)模型驱动的设计流程和工具
• 从应用程序源代码自动提取数据模型
• 自动化code到model-data一致性验证和一致性指标的衡量。
• 强有力的控制应用程序/数据模型的变更管理，主动跟踪和协调应用程序代码与数据模型，而实际的数据存在NoSQL数据库中。