Database ArangoDB-索引是否比拥有更多集合更好？

我有3种类型的实体：

• 科目
• 话题
• 任务

每个科目都有主题和任务。这些主题可以相互依赖。（当然，属于sj1主题的主题只能依赖于另一个同样属于sj1主题的主题。）

在任务和主题之间存在着联系（也必须属于同一主题），这意味着要解决某项任务，我们需要了解某些主题

因此，一项任务可能需要更多的主题。此外，更多任务可能需要一个主题。（NM连接。）

存储的最佳解决方案是什么

解决方案

• 每种类型的实体有3个集合
• 在任务和主题中，有主题标识符属性的索引
• 以及用于存储主题[N][M]任务之间的连接的边缘集合

解决方案

• 每个主题有一个集合
• 对于每个主题，有1个主题和1个任务集合。主题和任务/主题之间的连接可以基于集合名称的前缀。（即，对于化学科目，我们有化学任务和化学主题集合）
• 对于每个主题，都有一个用于任务和主题之间连接的边缘集合，还有一个用于主题之间连接的边缘集合（即化学主题任务连接和化学主题连接）

这样，如果我想在主题或主题任务之间搜索，我不需要根据主题标识符索引对它们进行预筛选。我将立即获得包含我所有数据的所需集合。此外，我没有任务和主题中每个文档的索引开销。 另一方面，这将导致收藏混乱

---

旁注：最多有50个主题，但任务和主题的数量是无限的。

用你的话来说，“意识”是通过“图形”生成的，它不需要额外的索引就可以达到最佳效果。ArangoDB自动创建特殊的“_键”和“_from/_to”索引，用于图形遍历

但是对于索引，所有的搜索性能都是基于您想要查找的数据来添加索引的。这实际上取决于您希望如何搜索：

• 一个集合具有多个实体类型或
• 按实体类型分隔的多个集合

---

拥有大型集合不会受到惩罚，而且图形可以链接单个集合中的文档-不需要将它们分离。此外，还可以有多个边缘集合和/或多个文档集合。这些概念对我们这些像我一样来自传统RDBMS的人提出了挑战——“无模式”或“多模型”数据库在某种程度上转向了规范化

就个人而言，我选择基于数据源构建相当大的集合（我从外部源导入数据）。每个集合包含由

objType

属性标识的多个对象/数据模式的文档。这里的好处是，您可以在单个字段（甚至是包含多个字段的索引，如

title

+

objType

）上搜索集合中的所有文档，可以非常快速地减少要迭代/遍历的文档集—这通常是获得真正性能收益的地方

---

所以。。。我想我推荐解决方案#3？

“拥有大型集合不会受到惩罚”-据我所知，惩罚来自这样一个事实，即如果对属性使用索引，那么插入集合的每个记录也会在“索引集合/表”中生成一条记录。（如果文档缺少某个属性，则skiplist索引除外）使用第二种解决方案可以避免这种情况，即使我们仍然可以使用这种方法按主题进行搜索。基本上，问题是，如果创建200个集合，我会受到惩罚吗？@Woster-是的，索引创建（或由于插入/删除而进行的修改）只是一个问题，但只有在您的集合被大量修改的情况下。我的系统（一个运行在OK-ish硬件上的4-CPU虚拟机，没有什么特别的）索引500K条记录（有7个散列索引）需要不到10秒的时间。如果ETL脚本对索引字段（超过50%的记录）进行主要修改，您可能会遇到麻烦，但是，也许截断并重新加载或“集合交换”是更好的计划。@Woster-不，除了加入/遍历边缘集合所需的时间外，拥有200个集合不应该受到惩罚。如果两个概念（200个集合或1个集合）之间的边数相同，那么在单个服务器场景中，遍历的性能应该几乎没有差异（集群本质上是不同的）。