非关系型数据库系统

非关系型数据库系统

Database system that is not relational

还有哪些其他类型的数据库系统。我最近遇到了以非关系方式处理数据的 couchDB。这让我想到了其他人正在使用的其他模型。

所以,我想知道还有哪些其他类型的数据模型。 (我不是在寻找任何细节,只是想看看其他人是如何处理数据存储的,我的兴趣纯粹是学术性的)

我已经知道的是:

  • 关系型数据库(mysql、postgres 等)
  • 基于文档的方法(couchDB、lotus notes)
  • 键/值对 (BerkeleyDB)

  • db4o

    引自"关于"页面:

    db4o is the open source object database that enables Java and .NET developers to store and retrieve any application object with only one line of code, eliminating the need to predefine or maintain a separate, rigid data model.


    较旧的非关系型数据库:

    网络数据库

    分层数据库

    当关系变得可行时,两者大多都过时了。


    语义网也是一种非关系数据存储范式。没有关系,所有元数据都以与数据相同的方式存储,每个实体都可能有自己独特的属性集。实现 RDF(语义 Web 标准)的开源项目包括 Jena 和 Sesame。


    面向列的数据库也有点不同。他们中的许多确实支持标准的关系数据库 SQL。这些通常用于数据仓库类型的应用程序。


    我想详细了解 Bill Karwin 关于语义网和三元存储的回答,因为这是我目前正在研究的内容,对此我有话要说。

    三元存储背后的想法是存储基于图的数据库,其数据模型源于 RDF。使用 RDF,您可以描述节点和节点之间的关联(换句话说,边)。数据按三元组组织:

    1
    start node ----relation---- end node

    (在 RDF 语音中:主语--谓语-- 宾语)。有了这个非常简单的数据模型,任何数据网络都可以通过添加越来越多的三元组来表示,只要你给节点和关系赋予意义。

    RDF 非常通用,它是一个基于图形的数据模型,非常适合用于搜索具有特定主语、谓语或宾语组合的所有三元组的搜索条件。最终,通过一种称为 SPARQL 的查询语言,您还可以执行更复杂的查询,该操作归结为在图上进行图同构搜索,无论是在拓扑方面还是在节点边缘含义方面(我们将看到一会儿)。 SPARQL 只允许您选择(和类似的)查询。没有删除,没有插入,没有更新。您查询的信息(例如您感兴趣的特定节点)被映射到一个表中,这是您查询的结果。

    现在,拓扑本身并不意味着什么。为此,发明了一种模式语言。实际上,不止一种,在某些情况下,称它们为模式语言是非常有限的。今天最著名和使用的是 RDF-Schema、OWL(Lite 和 Full),它们早于过时的 DAML OIL。这些语言的重点是,简化东西,为节点(通过授予它们一种类型,也称为三元组)和关系(边)赋予意义。此外,您可以定义这些关系的"范围"和"域",或者说不同的类型是起始节点和结束节点的类型:例如,可以说属性 "numberOfWheels " 只能用于将 Vehicle 类型的节点连接到非零整数值。

    1
    2
     ns:MyFiat --rdf:type-- ns:Vehicle
     ns:MyFiat --ns:numberOfWheels- 4

    现在,您可以在两个方向使用这些本体:验证和推理。今天的验证并不那么花哨,但我已经看到了使用实例。推理是今天很酷的东西,因为它允许推理。推理基本上采用包含一组三元组的 RDF 图,采用本体,将它们混合到包含"推理引擎"的三元组数据库中,并且推理引擎根据您的本体描述发明三元组。示例:假设您只是将此信息存储在数据库

    1
    ns:MyFiat --ns:numberOfWheels-- 4

    没有别的。该节点没有指定类型,但推理引擎会自动添加一个三元组,表示

    1
    ns:MyFiat --rdf:type-- ns:Vehicle

    因为您在本体中说过,只有 Vehicle 类型的对象才能由属性 numberOfWheels 描述。

    相反,您可以使用推理引擎根据本体验证您的数据,从而拒绝不符合要求的数据(有点像 XML 架构的 XML)。在这种情况下,您需要两个三元组才能让三元组成功接受您的数据。

    三重存储的其他特征是公式和上下文感知存储。公式是描述假设事物的陈述(像往常一样,三元组主谓宾语)。我从来没有使用过公式,所以我不会详细介绍我不知道的东西。上下文感知基本上是子图:存储三元组的问题是您无法说明这些三元组的来源。假设您有两个经销商,他们描述了相同价格的组件。一个说价格是 5.99,另一个说是 4.99。如果您只是将这两个三元组都存储到数据库中,那么现在您将不知道是谁陈述了每个信息。有两种方法可以解决这个问题。

    一个是物化。具体化意味着您存储额外的三元组来描述另一个三元组。这很浪费,而且让生活变得地狱,因为你必须对你存储的每一个三元组进行具体化。另一种方法是上下文感知。拥有上下文感知存储就像能够将一堆三元组装入一个带有标签(上下文标识符)的容器中。您现在可以将此标识符用作附加语句的主题,从而在单个操作中描述一堆三元组。


    我们一直在研究的面向非关系文档的数据库是 Apache CouchDB。

    Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. Among other features, it provides robust, incremental replication with bi-directional conflict detection and resolution, and is queryable and indexable using a table-oriented view engine with JavaScript acting as the default view definition language.

    我们的兴趣在于提供一个分布式访问用户首选项存储,该存储不受形状变化的影响,我们可以从 Java 序列化首选项对象,并使用基于 XULRunner 的客户端应用程序的 Javascript 轻松访问这些对象。


    有基于对象的数据库(例如 Gemstore)。 Google\\'s Big-Table 和 Amason\\'s Simple Storage 我不确定你会如何分类,但两者都是基于 map-reduce。


    正如 Eric 所说,db4o 是一个面向对象的数据库管理系统 (OODBMS)。


    亚马逊的 SimpleDB 不是非关系型的吗?


    Illumination Correlation Database 是一种新的革命性非关系数据库。关联数据库管理系统 (CDBMS) 独立于数据模型,旨在有效处理分析系统环境中的计划外、即席查询。与关系数据库管理系统或面向列的数据库不同,相关数据库使用基于值的存储 (VBS) 架构,其中每个唯一数据值仅存储一次,并且自动生成的索引系统维护所有值的上下文(数据是100% 索引)。使用自然语言而不是 SQL (NoSQL) 执行查询。

    了解更多信息:www.datainnovationsgroup.com


    有 BASE 系统(基本可用、软状态、最终一致),它们可以很好地与包含大量数据的简单数据模型配合使用。 Google 的 BigTable、Dojo 的 Persevere、Amazon 的 Dynamo、Facebook 的 Cassandra 就是一些例子。

    见链接


    还有所谓的"倒排索引"或"倒排列表"数据库。 Software AG 的 Adabas 产品就是一个例子。与分层数据库一样,由于遗留问题或在某些情况下(通常是高端事务应用程序)的性能优势,这些数据库继续在大型企业或大学环境中使用。


    4. 导航。包括树/层次结构和图形/网络。

    文件系统、语义网、XML、对象数据库、CODASYL 和许多其他都属于这一类。

    这4个差不多了。


    推荐阅读