深层数据树的高效数据库结构

对于非常深的数据树而言，非常大的数据库（超过10亿行），最有效的结构是什么？读取的加载量是最高的使用量，但是定期对树进行更改。深层数据树的高效数据库结构

有几种标准算法来表示数据树。我发现这篇文章是Mongodb手册的一部分，是一个很好的总结：http://docs.mongodb.org/manual/tutorial/model-tree-structures/

我的系统具有不能很好地映射到这些情况的属性。问题在于树的深度非常大，以至于保留“祖先”或“路径”非常大。树也经常变化，“嵌套集”方法效率不高。我正在考虑“物化路径”和“父参考”方法的混合体，而不是存储散列的路径，而不是保证是唯一的，而是散布时间的90％。然后，有10％的时间发生碰撞，父母参考解决它。这个想法是，有90％的时间对路径哈希进行了快速查询。这个想法有点像布隆过滤技术。但这都是为了背景：问题在于这篇文章的第一行。

来源

2014-01-24 tradetree

你能更精确地说明你的意思是“读取加载”吗？ –

我的意思是查询vs插入，我应该这么说。我的意思是有定期插入数据库，但大多数访问是查询。重要的是，这不是一棵静态树，插入可以发生在树中的任何位置，但70％的访问是用于查询的。 – tradetree

什么样的查询？整个树（从“木”）？获得（直接）给定节点的孩子吗？获得（递归）给定节点的后代？获得（直接）给定节点的父节点？获取给定节点的所有祖先？ –

我过去用任意深度的树做过的事情就是存储一个父密钥与每个父密钥，以及一个序号，它控制着父母下的孩子的顺序。我使用了RDBM，这非常有效。在阅读所需的代码以正确地安排事物之后安排树结构 - 将每个节点放在父节点中的一个Child集合中 - 但实际上它运行得非常快。

这是一个很不错的方法，因为没有什么聪明的，但它确实对我有用。

这棵树总共有大约300或400个成员，并且我认为是7或8层深。系统的这部分根本没有性能问题：速度非常快。用户界面是另一回事，但这是另一回事。

来源

2014-01-24 12:44:14

我可能会误解，但这不是一个非常小的数据库吗？ 8个级别的400名成员很小，不是吗？我的问题是找不到功能性解决方案，但找到了一个高效的解决方案。除非我误解了你对“成员”的定义，否则我有十亿个“成员”？ – tradetree

好的，你确实在Q中说了十亿成员。但这不是理所当然的事情（人们对这些事情可以说各种各样的事情）。你需要让它变得更可信 - 比如“几乎每个亿的数据点”。否则，人们可能会认为您正在构建新的Facebook（他们似乎都在构建“社交网站”），并且很可能永远看不到他们的家人。所以道歉这个答案是不合适的。 –

PS我想你已经看过了，但维基百科的文章http://en.wikipedia.org/wiki/Graph_(data_structure)#Representations有一些选择。 –

深层数据树的高效数据库结构

回答

相关问题