0

我需要解决的问题是将文件系统树的等价物存储到数据库中（以加快搜索操作）。树包含 +400.000.000 个 inode，对于每个 inode，我需要存储一些元信息（平均文件路径为 100 字节，元信息约为 50 字节）。

将在 C++ 程序中进行以下操作：
1. SELECT（预期结果：~200.000）
2. 一次插入 ~20.000 条记录
3. 一次删除 ~20.000 条记录。

到目前为止，我只考虑了关系数据库：MySQL、MariaDB、PostgresSQL（到目前为止我还没有进行任何测试，我仍处于“信息收集”阶段）并且我阅读了一些关于在这样的数据库中存储树的文档。

第一个选项
- 邻接列表模型：表中的每个项目都包含一个指向其父项的指针。
http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/

第二个选项
- 将所有目录存储在一个单独的表中
- 为其余文件创建一个单独的表，并带有指向它们所属目录的指针

所以表格看起来像这样：
DirTable: 

/home  
/home/test/

文件表： 

file1
file2

我的问题：
1. 你知道另一种适合在关系数据库中存储大树的模型吗？2. 如果我要搜索 NoSQL DB，我应该从哪里开始？

非常感谢。

4

1 回答 1

1

听起来您最好使用一种结构，该结构可以通过一次选择为您提供整个子树。有几种方法可以实现这一点，每种方法都有其优点和缺点：

  • 在嵌套集中，您向表中添加两列：lft 和 rgt。节点的子树的 lft 和 rgt 值介于节点的 lft 和 rgt 值之间。该模型查询起来很简单，但对树的更改需要重写整个树的 lft 和 rgt 值，因此更新成本可能很高。
  • 路径枚举将维护列中文件的绝对路径。该模型查询起来也很简单，但是您只能索引路径的固定长度前缀这一事实限制了可以有效搜索的树的深度。
  • 对于闭包表，您将添加一个新表，对于系统上的每个目录，该表都包含子树中某处包含的文件的 ID。同样，查询起来很简单，但是闭包表可能会变得相当大，并且如果目录被移动，则必须更新。

此幻灯片通过图表和示例代码解释了这些模型：http ://www.slideshare.net/billkarwin/models-for-hierarchical-data

于 2012-07-26T13:30:45.737 回答