Datomic信息模型 - 面向对象网,数据库,基础,原理,学习,对象 - 面向对象技术开发

面向对象技术开发

会员投稿 投稿指南 站长资讯通告:
您的位置: 首页 > 数据库 > 其它数据库 > 正文

Datomic信息模型

来源: www.bianceng.cn 阅读:

Datomic是一种新型数据库,它被设计为一系列简单服务的组合。它力求在传 统的关系型数据库管理系统的能力,以及新一代冗余分布式存储系统的灵活的可 伸缩性之间建立一种平衡。

动机

Datomic力图完成以下几个目标:

提供可靠的信息模型,而避免原地更新(update-in-place)

充分利用冗余的可伸缩存储系统

提供ACID事务和一致性

在应用中支持声明性数据编程

Datomic将数据库视为一个信息系统,每个信息都是一组事实,而事实就是指 已经发生的事。由于人类不能够改变过去,因此它意味着数据库将累积事实,而 不是原地更新结果。虽然过去可以遗忘,但却是不能改变的。因此,如果某些人 “修改了”他们的地址,Datomic会存储他们拥有新地址这个事实,而 非替换掉老的事实(它只是在这个时间点被简单的回收了)。这个不变性 (immutability)带来了很多重要的架构优势和机会。在上一篇文章中,我介绍 了Datomic的架构。这篇文章将会专注于信息模型与一些编程经验。

传统数据库(也包括许多新来者)专注于“现在”—— 即当前正确的事实集,但是由于这种做法造成它们丢失了信息。所有的业务都是 在历史信息中寻找增长的价值,没有什么理由不去保留这些信息。这不仅仅是保 留相关的历史数据,例如采用备份与日志方法的问题,而是保留它将能够支持各 种决策流程。对于某个业务实体来说,了解你当前的地址以将某将些东西寄送给 你确实是必需的,但是类似于“哪些客户经常性的搬家,他们通常来处哪里 ?”这样的问题对他们的市场或者产品开发团队来说也非常有趣。类似的还 有供应商的产品价格历史等等,他们可不愿意为了查找数据而被迫去恢复备份文 件,或者重新将每条日志都扫描一遍。

为什么是否保留活动的历史记录会成为一道是非题呢,考虑一下这个问题会十 分有趣。毕竟,在计算机出现之前,人类就学会了保留各种累积数据。并且随着 时间推移,进一步产生了“会计绝不能使用橡皮檫”这样的见解。我 猜测早期的计算机系统只是单纯的不具有保留历史数据的能力(或者无法承受这 种数据量)。但这种猜测在如今需要重新思考一下了,毕竟在过去的25年间计算 机的存储能力得到了百万倍的提升。开发者们还会因为无法将他们的代码库保存 在一张软盘上,而拒绝使用类似Git这样的版本控制系统吗?

数据库之所以称为数据库,主要原因是来自于它所对数据的处理能力。否则的 话它就只不过是个存储系统而已。这种能力通常是来自于数据组织(比如通过索 引)以及利用该组织的查询系统的一个综合体。开发者们对这样的能力非常感兴 趣。随后容量更大的分布式冗余存储系统也开始得到应用,但这些系统的功能性 则有所削弱。Datomic的目标是建立于这些存储系统之上,以利用它们的可伸缩性 ,将组织化的信息存储其中,并且将那些失去的功能重新交还给开发人员使用。

结构与展现

每个数据库在其模型的底部都有一个基础单元,例如关系、行或者文档。对 Datomic来说,这个单元就是具有原子性的事实,我们将其称为一个Datom。

一个Datom包含以下组件:

实体

属性

事务(数据库时间)

新增/回收

这种展现形式与RDF命题的“主题/谓词/对象”数据模型非常相似 ,但由于RDF命题缺少了回收这一概念以及适当的展现形式,它的功能并不足以展 现历史信息。而Datomic是面向商业信息系统的,它采用了封闭世界假定(closed world assumption)理论,以避免了语义网(semantic web)所面临的全局统一 命名、开放世界(open world)以及共享语义等方面的挑战。一个Datom是对一个 事实的最小化而充分的展现。

将一个具有原子性的单元放置在模型的最下方确保了对新内容(novelty)( 例如事务)的展现的大小和新事实本身的大小一样。否则,每次修改新内容的部 分信息都必须重新提交整个文档,或者是为了避免重新提交而导致使用脆弱的增 量结构(delta scheme)。

Datom构成了一种单一的、平滑的、全局的关系,除此之外Datomic就没有别的 结构化组件了。这一点非常重要,因为你的模型中结构化组件越多,你的应用程 序就会显得越僵硬。比方说,在一个典型的关系型数据库中,每个关系都必须被 命名,并且为了查找数据必须了解这些名称。更糟的是,为了创建类似于多对多 这样的关系模型,必须人为地建立联合表(join table),而这些联合表的名称 也必须为应用程序所了解。为了将应用程序与物理结构的决策进行分离,必须投 入极大的精力去创建一系列的逻辑视图,但这些视图不仅数量众多并且用途单一 。而文档存储的结构就更加僵硬,因为它已经硬编码在你的应用程序中的每个角 落里了,只有极少数(如果有的话)类似于视图的工具可以为该结构稍稍提供一 些间接抽象。

Schema

所有的数据库都有schema,唯一的区别就是它们在多大程度上支持(或者要求 )schema的明确性。在Datomic中,必须在使用schema前预先定义属性。

属性本身就是实体,只是包含了以下一些特定的属性:

名称

值的数据类型

基数(属性可以为多值)

一致性

索引的特性

自然组件(你的双足可以认为是你的组件,但你的母亲就不是了)

Tags:
相关文章列表: