哪种类型的 NoSQL 数据库最适合存储分层数据？答案

【问题标题】：What type of NoSQL database is best suited to store hierarchical data?哪种类型的 NoSQL 数据库最适合存储分层数据？
【发布时间】：2011-01-22 13:03:29
【问题描述】：

哪种类型的 NoSQL 数据库最适合存储分层数据？

例如，我想用树形结构存储论坛的帖子：

original post
 + re: original post
 + re: original post
   + re2: original post
     + re3: original post
   + re2: original post

【问题讨论】：

我的数据模型中有一个类似的问题。 Neo4j 工作得很好，但不会水平扩展。我认为 MongoDB 会更好，但由于您无法在不知道顶层架构的情况下检索嵌入的“原始帖子”元素，因此它实际上不如图形数据库。
@Sridhar-Sarnobat 也许未来属于混合数据库，如OrientDB 或ArrangoDB，它们结合了文档和图形数据库。如今，甚至 PostgreSQL 也支持 JSON 文档。
感谢您的建议。我会仔细看看那些
我在过去的一年中使用过 Neo4j 和 OrientDB，它们都为这里描述的问题类型提供了比 Mongo 或 Couch 更好的解决方案。问题真正出在遍历图表的地方。

标签： database tree nosql hierarchical-data

【解决方案1】：

MongoDB 和 CouchDB 提供解决方案，但没有内置功能。请参阅representing hierarchy in a relational database 上的这个 SO 问题，因为我见过的大多数其他 NoSQL 解决方案在这方面都是相似的；您必须编写自己的算法，以便在添加、删除和移动节点时重新计算该信息。一般来说，您要在快速读取时间（例如nested set）或快速写入时间（adjacency list）之间做出决定。有关这些方面的更多选项，请参阅上述 SO 问题 - flat table approach 似乎最符合您的问题。

抽象出这些考虑的一个标准是Java Content Repository (JCR)，Apache JackRabbit 和JBoss eXo 都是实现。请注意，在幕后，两者仍在进行某种算法计算以保持如上所述的层次结构。此外，JCR 还处理权限、文件存储和其他几个方面 - 所以它可能对您的项目来说是多余的。

【讨论】：

"flat table approach" 链接到 evolt.org 已失效。
@MatthewDutton：已修复。
JCR 的想法很好，不幸的是它有一些怪癖，使其成为大规模使用的噩梦。其中一些是： - 它将数据存储在文件系统和关系数据库中 - 很容易破坏版本控制历史 - 难以存储一致的备份

【解决方案2】：

您可能需要一个面向文档的数据库，例如 MongoDB 或 CouchDB。

查看允许您在 MongoDB 中存储分层数据的不同技术示例： http://www.mongodb.org/display/DOCS/Trees+in+MongoDB

【讨论】：

这和hierarchical data有什么关系？
答案仍然是实际的，但文档链接不是

【解决方案3】：

最常见的是IBM's IMS。还有Cache Database

见this question posted on dba section of stackexchange.

【讨论】：

【解决方案4】：

面对同样的问题，我决定使用 Lua + Redis https://github.com/qbolec/Redis-Tree/创建自己的（非常简单的）解决方案@

【讨论】：

【解决方案5】：

Exist-db 实现了用于 xml 持久性的分层数据模型

【讨论】：

【解决方案6】：

图形数据库也可能会解决这个问题。如果 neo4j 在扩展方面对你来说还不够，可以考虑Titan，它基于包括 HBase 在内的各种存储后端，应该可以很好地扩展。它不像neo4j那么成熟，但它是一个非常有前途的项目。

【讨论】：

【解决方案7】：

LDAP，很明显。 OpenLDAP 会做的很短。

【讨论】：

【解决方案8】：

In mathematics, and, more specifically, in graph theory, a tree is an undirected graph in which any two vertices are connected by exactly one path。所以任何graph db 肯定会完成这项工作。顺便说一句，像树这样的普通图可以简单地映射到任何关系或非关系数据库。要将分层数据存储到关系数据库中，请查看Bill Karwin 的精彩演示。还有一些带有存储树木设施的 ORM。例如TypeORM 支持邻接表和闭包表模式来存储层次结构。

TypeORM 用于 TypeScript\Javascript 开发。 Check popular ORMs 根据您的环境找到支持树木的树木。

非关系数据库之王 [恕我直言] 是 Mongodb。看看它是documentation。了解它如何存储树木。树是最常见的图表类型，它们无处不在。任何成熟的数据库解决方案都应该有处理树的方法。

【讨论】：

【解决方案9】：

这是一个不适合你的答案。 SQLServer 2008 ！！！！它非常适合递归查询。或者您可以采用老式的路线并将层次结构数据存储在单独的表中以避免递归。

我认为关系数据库非常适合树数据。无论是查询性能还是易用性。有一个警告......每次有人发帖时，您将插入一个索引表，可能还有其他几个索引表。插入性能可能是 facebook calibre 论坛上的一个问题。

【讨论】：

您至少需要在这里讨论公用表表达式和/或 XML 功能，这是 SQL Server 2008 有用的原因。
SQL 确实有 hierarchid 数据类型；但是，sql 又慢又笨重。
MySQL 7 现在也有类似的功能

【解决方案10】：

查看MarkLogic。您可以从网站下载演示副本。它是用于非结构化数据的数据库，属于 NoSQL 数据库分类。我知道非结构化数据是一个相当丰富的术语，但只是将其视为不太适合 RDBMS 的行和列的数据（如分层数据）。

【讨论】：

【解决方案11】：

刚刚度过了一个周末的培训课程，使用 MUMUPS db 作为全栈 JavaScript 浏览器应用程序开发框架的后端。好东西！我推荐 GPL 下 MUMPS 的 GT.M 发行版。或者试试http://sourceforge.net/projects/mumps/?source=recommended 香草 MUMPS。查看 http://robtweed.wordpress.com/ 了解 ewd.js js 框架以及有关 MUMPS 的更多信息。

【讨论】：

【解决方案12】：

Amazon Web Service 的简单存储服务 (AWS S3) 是对分层数据提供原生支持的 NoSql 存储服务。基于路径的键本质上是分层的，并且可以使用属性（mime 类型，例如 application/json、text/csv 等）键入 blob 值。 S3 的优势包括能够扩展到极大的整体容量、版本控制以及几乎无限的并发写入。缺点包括不支持条件写入（乐观并发）或一致读取（仅适用于后写），并且不支持引用/关系。它也完全基于使用情况，因此需求的广泛变化不需要复杂的扩展基础设施或过度配置的容量。

【讨论】：

【解决方案13】：

Clicknouse db 明确支持hierarchical data

【讨论】：