对于存在非常深的数据树的非常大的数据库（超过10亿行），最有效的结构是什么？读取加载是最高用量，但是树也会定期更改。
有几种标准算法来表示数据树。我发现这个参考作为Mongodb手册的一部分是一个很好的总结：http://docs.mongodb.org/manual/tutorial/model-tree-structures/
我的系统的属性无法很好地映射到任何这些情况。问题是树的深度太大，以至于保持“祖先”或“路径”非常大。树也经常变化，“嵌套集”方法效率不高。我正在考虑“物化路径”和“父参考”方法的混合，其中我存储的路径不是保证唯一的散列，而是90％的时间。然后10％的时间发生碰撞，父参考解析它。这个想法是90％的时间存在对路径哈希的快速查询。这个想法有点像布隆过滤技术。但这完全是为了背景：问题出在本文的第一行。
答案 0 :(得分：1)
我过去用任意深度树做的只是存储一个父键和每个父键，以及一个序列号来控制父母下的孩子的顺序。我使用了RDBM，这非常有效。在阅读所需的代码以正确排列事物之后安排树结构 - 将每个节点放在父节点中的子集合中 - 但实际上运行速度非常快。
这是一个非常简单的方法，因为它没有什么聪明的，但它对我有用。
这棵树总共有大约300或400名成员，我觉得有7或8级深。系统的这一部分根本没有性能问题：它非常快。用户界面是另一回事，但这是另一回事。