我一直在使用关系数据库,但直到最近我才意识到必须有其他类型的非关系数据库。
有哪些非关系数据库的例子,它们在现实世界中的哪些地方/如何使用?为什么你会选择使用非关系数据库而不是关系数据库?
编辑:答案中还提到了另外两个类似的问题:
我一直在使用关系数据库,但直到最近我才意识到必须有其他类型的非关系数据库。
有哪些非关系数据库的例子,它们在现实世界中的哪些地方/如何使用?为什么你会选择使用非关系数据库而不是关系数据库?
编辑:答案中还提到了另外两个类似的问题:
这里提到的数据库类型的一个公认的晦涩但有趣的替代方案是关联数据库,例如来自LazySoft Technology的 Sentences 。有一个免费的个人版本,您可以下载并自行尝试。企业版也是免费的,但需要向公司提出要求。
从本质上讲,关联数据库允许您以与我们的大脑几乎相同的方式存储信息:作为事物和这些事物之间的关联。“句子”这个名字来自于这种信息可以用主-动词-宾语语法表示的方式:
一个句子可以是另一个句子的主语或宾语:
所以,一切都可以归结为实体和关联。
当然,Sentences 比这里可以表达的要多得多。我建议您花一些时间在LazySoft的白皮书中阅读有关它的更多信息。
“数据的关联模型”是 Sentences 的创建者之一 Simon Williams 以 PDF 格式提供的一本书。
我们一直在研究的面向非关系文档的数据库是Apache CouchDB。
Apache CouchDB 是一个分布式、容错和无模式的面向文档的数据库,可通过 RESTful HTTP/JSON API 访问。除其他功能外,它还提供具有双向冲突检测和解决功能的健壮、增量复制,并且可以使用面向表的视图引擎(以 JavaScript 作为默认视图定义语言)进行查询和索引。
我们的兴趣是提供一个分布式访问用户首选项存储,该存储不受形状变化的影响,我们可以从 Java 序列化首选项对象,并使用基于 XULRunner 的客户端应用程序的 Javascript 轻松访问这些对象。
任何声称是“伯克利风格数据库”或“键/值”数据库的数据库都不是关系型的。
这些数据库通常基于复杂的散列算法并提供基于键的非常快速的查找 O(1),但将任何形式的关系优势留给最终用户。
例如,在关系数据库中,您将规范化您的结构并将许多表连接在一起以创建单个结果集。
在键/值数据库中,您将尽可能地进行非规范化,然后使用唯一键来查找数据。
如果您需要从两个源中提取数据,则必须手动将结果集连接在一起。
所有数据库最初都是非关系型的,直到 1980 年代中期 DB2 和 Oracle 的到来,它们才变得普遍。在此之前,大多数数据库要么是平面文件,要么是分层文件。
平面文件本来就很无聊,但分层数据库就不那么无聊了,尤其是 DB2 实际上是在第一个实例的分层实现(即 VSAM)之上实现的。我相信 VSAM 仍然存在于大型机系统中,并且具有相当重要的意义。
DB/1(现在太模糊了,我什至找不到维基百科链接)是 IBM 的前身黄金时间数据库到 DB2(因此得名)。这是分层的——基本上你有一个由任意数量或“根”记录组成的文件,通常可以通过一个键直接访问。然后每个根记录可以有任意数量的子记录,每个子记录又可以有它自己的子记录。最终效果是一个索引文件或根记录,每个根都是潜在树状结构的顶部。访问子记录可能很棘手 - 直接访问存在限制,因此通常您最终会遍历树以查找所需的记录。“数据库”中可以包含任意数量的这些文件,通常通过键关联。
这有很大的缺点——尤其是实际上做任何事情都需要编写完整的程序——基本上相当于我们现在可以在几分钟内用 SQL 完成的工作。然而它确实在执行速度上得分,在那些日子里,大型机的处理能力与你的 iPhone 差不多(尽管针对数据 I/O 进行了优化),而糟糕的 DB2 查询可能会导致数百万美元的安装死亡。这在 DB/1 中从来都不是问题,在程序员比 CPU 时间更便宜的世界里,这是有道理的。
App Engine 数据存储区不是关系数据库。虽然数据存储接口具有许多与传统数据库相同的功能,但数据存储的独特特性意味着设计和管理数据的方式不同,以利用自动扩展的能力。
OSIsoft 的 PI 历史数据库是非关系型的。它仅用于存档带时间戳的数据。它在行业中被大量使用,特别是作为所有这些“仪表板”的后端数据库。
因为没有连接,所以不需要关系。
尚未出现的另外两种类型的数据库:
内容存储库是为内容(即文件、文档、图像等)设计的数据库。它们通常具有附加结构,例如浏览内容的分层方式、搜索、不同格式之间的转换、版本控制和许多其他事情。示例 - Alfresco、Documentum、JackRabbit、Day、OpenText、许多其他 ECM 供应商。
目录,即 Active Directory 或 LDAP 目录。这些数据库专为低写入/高读取场景而设计,并且高度分布在高地理距离/高延迟连接中。虽然主要用于身份验证/授权,但如果您的用例符合要求,则不必如此。
维度数据库是非关系数据库的绝佳示例。它们非常常用于 KPI 和其他类型的聚合或统计数据的“业务仪表板”/“商业智能”。它们通常由关系数据库填充,在某些情况下可以提供更好的性能。
非关系型数据库就是不符合 Codd 的要求。Intersystems Caché 对旧 Pick 操作系统的数据库进行了全面重写/重新设计。从我对 Caché 的一点了解来看,它似乎是一个做得很好的重新设计。它允许 .net 程序像访问 SQL 一样访问数据库。Caché 运行 Pick OS 程序,无需任何更改。通过将 Pick 文件导入 Caché,您仍然可以使用它运行旧的绿屏应用程序,还可以使用 .net 编写新程序,这样您就可以迁移到 Windows 应用程序,而不会放弃您已经投入多年的数据设计。这里是Pick DB 模型的一些背景知识。Pick 数据库使用完全可变长度的记录和字段。所有表都由一个唯一键作为键,并且无需读取索引即可访问。Pick 将系统设计为使用散列算法,该算法通常在第一次物理读取时从磁盘读取项目(假设系统维护已正确执行)。Pick 中的字段是非类型化的。所有数据都存储为字符串,而 Casting 由程序员决定。Null 存储为空字符串,因此 null 不会像在 SQL 中那样占用磁盘空间。不需要外键。在“关系世界”中,DBA 必须创建 Order Header 表和 Order Line Item 表。在“选择模型”中有一个表。例如,“订单日期”是一个字段,它将存储自“1967 年 12 月 13 日”以来的天数(数据 Pick OS 首次打开)。挑选程序员没有千年虫问题。第二列是客户编号。最大的不同是当您进入产品编号列时,这将是“多值”(Codd 不合格)。换句话说,数据库可以处理该列中的 1-32000 个产品#。其他列(如 Quantity Ordered)将与产品编号处于控制/依赖关系,并且也将是多值的。当您到达已发货数量时,Pick 将转到第三个维度并具有 Sub-Multi-Valued 字段。您将有一个货件编号列,它将按行项目进行多值化,并且包含该货件编号的该行的货件数量的子多值化。不需要内部连接。该订单的所有数据都存储在一个表和一条记录中。从来没有孤行!其次,数据定义有点不同。我们的字典可以包含不在此表中或正在被操作的数据的定义。几个例子是,顾客姓名。它将被定义为“使用客户编号列并从客户表中返回名称字段。另一个示例是 Line Item Extension 将定义为 Quantity*Price/PricePer 的计算。我相信我在某处读到 Caché 声称拥有超过 100,000 个安装。
我认为 Excel 中的平面文件数据库是非关系型的,并且被很多人使用。
它实际上只是一个无法与其他表连接的数据库表。
面向对象的数据库是一种有趣的非关系型数据库。
贸易部门有时会使用 OO 数据库,因为每个交易/合同可能看起来有点像该类别中的其他交易/合同,但也具有独特的属性。很难用关系来表示它。
eXist-db是一个已经存在很长时间的 xml 数据库。它对于处理大量 xml 文档的xquery特别有用。
任何包含数据但不表达该数据内关系的文件或文件组都是非关系数据库。
对于基于图形的 dbms,你有 neo4j
对于分层 dbms,您有任何标准文件系统或“模式”支持任何 LDAP 实现。
有很多答案,但它们最终都属于两个主要类别之一:
导航。包括树/层次数据库和图形数据库。
打破第一范式(多个值)的数据库。包括 Pick 数据库和 Lotus Notes 及其后代,如 CouchDB。
编辑:当然,像 BDB 这样的键/值存储不是关系型的,但这不言而喻不是吗?我的意思是,它们只是键/值存储。
dBase。虽然它是这样销售的,但它不符合要求。
作为一个 OO 数据库,我们想到了 Intersystems Caché。一些医学和图书馆系统建立在此之上。
在我的公司 www.smartsgroup.com 中,我们有一个专有的数据库引擎,我们称之为“事务日志数据库”。它建立在平面文件之上,每个文件都包含一系列二进制格式的“事件”或“消息”,以及该数据的各种索引和用于重现证券交易所订单簿状态的算法。它针对顺序更新和顺序访问进行了高度优化。
在科学应用程序中,使用专有数据库引擎而不是 RDBMS 也很常见。我还曾在一家拥有世界上最大的脑电图脑记录数据库的公司工作:www.brainresource.com。我们在那里使用了一个平面文件数据库,它对我们很有效。
SmartsGroup 还使用时态数据库,它类似于非关系数据库表,不同之处在于我们存储了所有字段的所有更改的历史记录,因此我们可以重现特定行在特定日期的状态。
上面链接的维度数据库的 Wiki 页面似乎已经消失了。
一些OLAP系统得到了多维数据库 (MOLAP) 的支持,这些数据库经常用于财务分析。他们提供交互式客户端,允许人们浏览不同聚合级别的数据。
在我的大学里有一个研究演绎数据库的小组。