我刚刚进入图形数据库，我似乎一直在决定使用“索引节点”或“索引属性”来跟踪诸如“节点类型”之类的东西。由于到目前为止我还没有真正的经验，因此我没有任何信息可以作为决定的依据，而且这两种方法似乎都同样有效。
所以，问题是：两种方法之间的权衡是什么，规模（即节点数量）如何影响决策？
对于一个示例场景，假设有两种类型的“事物” ：User和，或者如果我们希望每个节点都有一条边分别指向一个节点和一个节点。Producttype: Usertype: ProductUserProduct
在哪种情况下哪种方法更好？
注意：我特别关注 Neo4j 和 Titan，但我认为这也会更普遍地适用。
首先，你需要问自己：一个顶点/节点的类型需要被索引吗？即您是否需要按类型检索顶点/节点，比如说，从图中检索所有“用户”顶点，或者您是否需要回答从检索给定类型的所有顶点开始的查询，然后进一步过滤/处理这些？
如果这个问题的答案是yes，那么我建议您将类型存储为索引的字符串属性。或者，如果您正在使用基于 jvm 的语言进行开发，您可以定义一个类型枚举并将其用作属性类型，以实现更多的类型安全和自动错误检查。Titan 支持任意用户定义的类/枚举作为属性类型，并将压缩它们以减少内存占用。
但是，这种方法的缺点是它不会扩展，因为您正在构建一个低选择性指数。这意味着可能会有很多类型为“用户”或“产品”的顶点，所有这些都需要分别与“用户”或“产品”的索引条目相关联。这使得维护和查询该索引非常昂贵且难以扩展（想象一下 facebook 有一个“类型”索引：“照片”条目下将有数十亿个顶点）。如果您（还）不关心缩放，那么这可以工作。
如果问题的答案是否定的，那么我建议将类型建模为图中的顶点/节点。即有一个“用户”顶点和一个“产品”顶点以及从每个用户到“用户”顶点的标记为“类型”的边等。
这种方法的优点是您可以使用图形对数据进行建模，而不是让数据库之外的字符串值代表关键的类型信息。在构建应用程序时，图形数据库将成为其中心组件并持续很长时间。随着编程语言和开发人员的来来去去，您不希望数据建模和类型信息与他们一起出现并面临以下问题：“SPECIAL_USER 是什么意思？” 相反，有一个 SPECIAL_USER 顶点并向其添加出处信息，即，谁创建了这种类型，它代表什么以及简短的描述——所有这些都在数据库中。
这种方法的一个问题是，当您的应用程序扩展时，“用户”和“产品”顶点将有很多边缘发生在它们身上。换句话说，您正在创建产生扩展问题的超级节点。这就是 Titan 引入单向边缘概念的原因。单向边就像网络上的链接：起始顶点指向另一个顶点，但该顶点不知道边。由于您不想从“用户”顶点遍历所有用户顶点，因此您不会失去任何东西，而是获得可伸缩性和性能。
你想问什么样的问题？在 Neo4j 中，您可以创建一个User和一个Product索引，甚至将它们组合成一个，然后可以询问类似的问题
start bob = node:User(name='Bob') match ....
甚至全文搜索。为了方便检查一个节点是用户还是产品，你可以让属性仍然在节点上，只是为了方便和快速的遍历。如果您没有从 User/Product 遍历到实例节点（您为此进行索引查找），您甚至可以通过将PRODUCTorUSER关系返回到类型（超级）节点来进行检查，从而为您提供检查遍历像
start s = node:User(name='Bob') match s-[r]-(product)-[typeRel:PRODUCT]->() return product
高温高压
在这里 imo 忽略了索引的一个非常重要的原因。假设您有一个具有许多不同属性和许多不同节点类型的复杂图，并且您希望将一个模式与具有一堆属性的“人”匹配。
如果没有索引，您别无选择，只能遍历该图，其中可能只有 0.01% 的节点是人员类型。并且遍历可能不会到达图中的未连接区域。
相反，如果我为人员编制了索引，我只需遍历每个人，并在每个人周围进行本地搜索以查看他们的模式是否匹配。
您应该能够立即看到，这些方法中的第一种与图表的总大小成比例，但第二种方法仅与图表中的总人数成比例。
道德：如果您设想一个用例，其中将使用特定类型的节点作为模式中的绑定节点对图形进行多次搜索（例如，这里有很多搜索“具有模式 X 的人”），那么您应该索引这些节点以提高搜索性能。
如果您要搜索诸如“人 Peter 的两个链接中的所有节点”之类的内容，那么按人的名称对其进行索引将是至关重要的，并且无论图形大小如何，都可以实现恒定的时间性能 - 因为您实际上是在查找彼得在哈希表中。