Java架构-数据建模 NoSQL 数据库的概念和对象建模符号

在最近的2018数据架构峰会上,Ted Hills主持了一个研讨会,该研讨会的主题是关系数据库和 NoSQL 数据库的数据建模。

他表示,NoSQL 运动帮助了数据库社区明白了两件事。首先,并非每个应用程序都需要 ACID,并且,放宽 ACID 以能扩展到互联网规模。其次,表格数据组织很适合大量的数据,但未必适合所有的数据集。但是,随着时间的流逝,SQL/NoSQL 的显著区别将会消失,DBMS 用户则会因为有了更多选择而获得收益。

实体关系(entity-relationship,简称 ER)建模技术已经在 SQL 数据库上应用很长时间了,但是,对于 NoSQL 数据库来说,它们的工作方式是不一样的。在研讨会上,Hills 讨论了概念和对象建模符号(the Concept and Object Modeling Notation,简称 COMN,发“common”的音)。COMN 用于表示新的数据库结构,不同的 NoSQL 数据库均支持该数据库结构。

他谈到了对以 COMN 符号表示新的多模型 NoSQL 数据库的承诺。无论是数据建模人员,还是程序开发人员都可以使用它,开发人员能够在 COMN 中用数据对软件建模。Hills 也讨论了建模无模式(schema-less)数据库的方法。

InfoQ 与 Hills 进行了对话,讨论了与 NoSQL 中的数据建模和 COMN 符号有关的话题。

InfoQ:您能否对概念和对象建模符号(COMN)下个定义?

  • Ted Hills:概念和对象建模符号(COMN)是一种数据建模符号,其能用一种熟悉的图形符号(框和线)来表示需求、图形和本体性谓词、逻辑数据、软件类结构和 NoSQL 及 SQL 的物理实现,该图形符号能对这些非传统实现中层之间的重要映射进行建模。

InfoQ:您能否谈谈 NoSQL 数据库背景中的概念和对象建模符号(COMN)?以及数据建模和关系数据库建模之间的不同之处在哪里?

Hills:实体关系(Entity-relationship,简称 E-R)和其他符号假设数据将最终存储于表格中。随着 NoSQL 数据库的出现,现在我们可以把数据存于图形和文档中,也可以存储于其他表格结构中,如宽列表(wide-column table)、面向列的表格和键 / 值对。我们不再假设从逻辑数据设计到物理实现的映射接近 1:1。此外,物理实现建模,包括非表结构(non-tabular structure)建模,甚至查询建模,都变得比以往更为重要。COMN 使各种各样的物理结构和所代表的数据的重要映射得以表达。

InfoQ:对于每种 NoSQL 数据库,数据建模方法是不同的吗?比如,像 Cassandra 这样的宽列数据库(wide-column database)?以及像 Neo4j 这样的图形数据库?

Hills:是的, 对大多数 NoSQL 数据库类型来说,数据建模的重点是不同的。属性图形数据模型关注于关系,而后用数据属性来注释节点和关系。知识图形数据模型也关注关系,但添加子 / 超类型关系。文档(XML 和 JSON)数据模型把层次关系放在首位。因此,尽管物理数据模型的焦点随每个 NoSQL 数据库的类型而改变,但 COMN 可以用于每种数据库。此外,它可以代表所有这些非传统数据结构和表(还没消失),并把物理模型和逻辑数据模型相关联,理想情况下,逻辑数据模型不会受物理表示选择的影响。

InfoQ:您能谈谈多模型 NoSQL 数据库吗?还有,它们如何能有助于不同数据结构的数据管理?

Hills:在 NoSQL 的世界里,必须为你的数据选择一个物理表示,而且这些数据必须是最适合你的应用程序的。是否需要随机写入或只在日志的末尾写入?是否需要围绕分层文档结构来组织数据?或是围绕关系来组织数据?很多 NoSQL DBMS 只提供一种方法来组织数据。如果需要改变数据组织,或需要更多的方式来组织数据,那么就不得不改变整个 DBMS。这涉及到处理不同的供应商、不同的支持需求、不同的编程语言和 API 等等。它可不是个平凡的数据库。如果相反,使用支持多个数据组织的混合 DBMS,那么使用多种方法来组织你的数据就变得更容易了,并且如果要改变主意也不是件难事。

InofQ:一般而言,微服务如何有助于数据建模?

Hills:我不会说微服务本身有助于数据建模任务,但是,对数据架构,它们的确有显著的积极影响。微服务必须设计成自给自足的:它始终必须持有本地所需的所有数据。这涉及两种类型的数据:微服务创建和维护的数据,以及微服务必须从外部源获取的数据。对微服务来讲,数据如何存储在微服务外部的物理模型不重要,但是,数据如何到达微服务的模型却很重要。那可以是 XML 或 JSON 文档。数据模型需要表示文档结构及微服务将如何存储数据,并需要表达它们之间的映射关系,这种关系可能具有重要意义。COMN 能够同时表达模型和它们的映射关系。

InofQ:您在会议演示中谈到了状态和陈述。您能否讨论一下如何在数据库中建模这些概念?

Hills:每个 DBMS,无论是 NoSQL 还是 SQL,最终,都是把无意义的物理状态(高电压和低电压,或者开和关)和有意义的事物建立映射关系,从而表示数据。我们把这个映射称为物理表示。在更高的层次上,我们使用表、图形和文档等结构来表示关系。理解的关键是逻辑数据模型应该完全忽略这些物理映射问题。逻辑数据模型应该把重点完全放在数据的含义上以及数据如何按照逻辑表示问题域内的数据。但是,在从逻辑模型转移到物理模型时,保留从物理模型到逻辑模型的映射关系以及物理表示设计都变得至关重要了。

InfoQ:NoSQL 数据库领域的新兴趋势是什么?

Hills:主流趋势是,NoSQL 和 SQL 之间的差别变得越来越少。对于初学者来说,术语“NoSQL”开始意味着“no SQL(没有 SQL)”,也即不支持表数格据库的标准结构化查询语言。然而现在,它意味着“not only SQL(不只是 SQL)”,这意味着越来越多的“NoSQL”DBMS 开始支持 SQL。在早期,NoSQL 不提供 ACID 强度交易,而这对金融应用程序是至关重要的。现在,很多 NoSQL DBMS 实现了 ACID。同时,一些 SQL DBMS 正允许放宽 ACID,使它们能够扩展到和一些 NoSQL DBMS 几乎相同的水平。有些混合 DBMS 支持表格和非表格数据组织。最终可能会出现,每个 DBMS 都支持各种物理数据组织,以及 ACID 和非 ACID(“BASE”),所有这些都由用户选择。SQL 诞生于表格时代,目前还没有替代者,而这个事实将会阻碍这一完整的转型。但是,COMN 可以适用于所有这些数据组织。

Ted 还表示,传统建模工具供应商对基于每次三层和一个应用的数据模型的观点很有局限,NoSQL 建模工具专注于物理建模以排除逻辑数据模型和真实世界模型。像 COMN 这样的工具能有助于数据建模,COMN 的承诺是代表数据管理的新多模型世界。

关于 COMN 的更多信息,包括完整规范、白皮书和 Visio 模板,可以从DATAVERITY 网站免费获取。

希望此文能帮到大家的同时,也听听大家的观点。欢迎留言讨论,加关注,分享你的高见!持续更新

我本人邀约各大BATJ架构大牛共创Spring Cloud构建微服务架构的交流社区。 (群号:547793198)欢迎各路架构师、开发者,学习与交流使用Spring Cloud诸多强大组件的实战经验。

为什么某些人会一直比你优秀,是因为他本身就很优秀还一直在持续努力变得更优秀,而你是不是还在满足于现状内心在窃喜!

合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代

  • To-陌霖Java架构

分享互联网最新文章 关注互联网最新发展

关系型数据库NoSQL数据库 什么是NoSQL 大家有没有听说过“NoSQL”呢?近年,这个词极受关注。看到“NoSQL”这个词,大家可能会误以为是“No!SQL”的缩写,并深感愤怒:“SQL怎么会没有必要了呢?”但实际上,它是“Not Only SQL”的缩写。它的意义是:适用关系型数据库的时候就使用关系型数据库,不适用的时候也没有必要非使用关系型数据库不可,可以考虑使用更加合适的数据存储。 为弥补关系型数据库的不足,各种各样的NoSQL数据库应运而生。 为了更好地了解本书所介绍的NoSQL数据库,对关系型数据库的理解是必不可少的。那么,就让我们先来看一看关系型数据库的历史、分类特征吧。 关系型数据库简史 1969年,埃德加•弗兰克•科德(Edgar Frank Codd)发表了划时代的论文,首次提出了关系数据模型的概念。但可惜的是,刊登论文的《IBM Research Report》只是IBM公司的内部刊物,因此论文反响平平。1970年,他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”(大型共享数据库的关系模型)的论文,终于引起了大家的关注。 科德所提出的关系数据模型的概念成为了现今关系型数据库的基础。当时的关系型数据库由于硬件性能低劣、处理速度过慢而迟迟没有得到实际应用。但之后随着硬件性能的提升,加之使用简单、性能优越等优点,关系型数据库得到了广泛的应用。 通用性及高性能 虽然本书是讲解NoSQL数据库的,但有一个重要的大前提,请大家一定不要误解。这个大前提就是“关系型数据库的性能绝对不低,它具有非常好的通用性非常高的性能”。毫无疑问,对于绝大多数的应用来说它都是最有效的解决方案。 突出的优势 关系型数据库作为应用广泛的通用型数据库,它的突出优势主要有以下几点: 保持数据的一致性(事务处理) 由于以标准化为前提,数据更新的开销很小(相同的字段基本上都只有一处) 可以进行JOIN等复杂查询 存在很多实际成果专业技术信息(成熟的技术) 这其中,能够保持数据的一致性是关系型数据库的最大优势。在需要严格保证数据一致性处理完整性的情况下,用关系型数据库是肯定没有错的。但是有些情况不需要JOIN,对上述关系型数据库的优点也没有什么特别需要,这时似乎也就没有必要拘泥于关系型数据库了。 关系型数据库的不足 不擅长的处理 就像之前提到的那样,关系型数据库的性能非常高。但是它毕竟是一个通用型的数据库,并不能完全适应所有的用途。具体来说它并不擅长以下处理: 大量数据的写入处理 为有数据更新的表做索引或表结构(schema)变更 字段不固定时应用 对简单查询需要快速返回结果的处理 。。。。。。 NoSQL数据库 为了弥补关系型数据库的不足(特别是最近几年),NoSQL数据库出现了。关系型数据库应用广泛,能进行事务处理JOIN等复杂处理。相对地,NoSQL数据库只应用在特定领域,基本上不进行复杂的处理,但它恰恰弥补了之前所列举的关系型数据库的不足之处。 易于数据的分散 如前所述,关系型数据库并不擅长大量数据的写入处理。原本关系型数据库就是以JOIN为前提的,就是说,各个数据之间存在关联是关系型数据库得名的主要原因。为了进行JOIN处理,关系型数据库不得不把数据存储在同一个服务器内,这不利于数据的分散。相反,NoSQL数据库原本就不支持JOIN处理,各个数据都是独立设计的,很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上,减少了每个服务器上的数据量,即使要进行大量数据的写入操作,处理起来也更加容易。同理,数据的读入操作当然也同样容易。 提升性能增大规模 下面说一点题外话,如果想要使服务器能够轻松地处理更大量的数据,那么只有两个选择:一是提升性能,二是增大规模。下面我们来整理一下这两者的不同。 首先,提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。这是非常简单的方法,程序方面也不需要进行变更,但需要一些费用。若要购买性能翻倍的服务器,需要花费的资金往往不只是原来的2倍,可能需要多达5到10倍。这种方法虽然简单,但是成本较高。 另一方面,增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更,但由于使用廉价的服务器,可以控制成本。另外,以后只要依葫芦画瓢增加廉价服务器的数量就可以了。 不对大量数据进行处理的话就没有使用的必要吗? NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但如果不是对大量数据进行操作的话,NoSQ
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值