Neo4j 图形设计 - 标题/类别节点？

Question

为单个用户允许数千个关系的最佳设计是什么？

（在社交网络应用程序上工作 - 如果您知道任何“通用”社交网络设计，请指出它们......会有所帮助）

看到这张图片 - 状态更新代表一个链接列表，而兴趣代表杂项兴趣。对于单个用户，这些兴趣可能真的会爆炸到数千个节点 - 这不会导致某种超级节点问题吗？

图一

为这些兴趣设置一个类别或“标题”节点，然后将这两个兴趣归入该类别节点会是更好的设计吗？我认为，当您最初处理用户节点和几个关系/标头节点时，它可能更有效，而不是与用户节点直接相关的数千个节点。

示例： 图 2 用户
|
+ 兴趣+
+----- 兴趣
+----- 兴趣
+----- 等等...

而且兴趣不应该也有“子标题”类别节点，比如“书”、“电影”、“产品”之类的：

**FIGURE 3**
User
|
+ interests+ 
           + books+
           |      + interest
           |      + interest
           |      + interest
           + movies+<br>
                   + interest
                   + interest
                   + interest

（显然我是 Neo 的 n00b）

这是我的问题：

1. 哪种模型最适合高性能、可扩展、类似 facebook 的系统 - 一种没有分类，一种有分类？牢记性能..
   

2. 兴趣可能不会总是激增到数千个节点 - 可能是十几个或 100 个 - 添加类别设计是否会增加太多开销？考虑尝试寻找和你一样喜欢的朋友 - 添加类别会增加太多开销吗？
   

3. 后一种图像（具有类别和子类别节点的图像）是否只是看起来更好，但对性能、组织等没有任何作用？
   

4. 是否应该只有一个类别属性来描述它所在的类别，而不是类别节点？在索引上添加具有类别属性的节点是否与添加类别节点一样好？
   

5. 关于问题 4，在索引上添加具有类别的节点会是更好的解决方案吗？
   

6. 这种结构有什么缺点？它们有什么真正的优势吗？
   

Answer 1

我认为当您的兴趣激增至数十万或数百万个连接时，兴趣类别是一个好主意，如果它只有几千个，它应该仍然足够好。也许这甚至是您可以将您的用户节点发展到您真正需要它的东西。 （就像 twitter 上对超级明星的不同处理方式）。

这还取决于您的用例，您希望使用模型回答哪些类型的查询，这些查询是否仅限于类别或始终跨所有类别查询以下兴趣？

您必须始终考虑的一点是，所触及的关系数量会随着您在图表中的每一步而呈指数增长。因此请注意，如果您从用户查询其所有朋友或朋友的朋友以及他们所有的兴趣，则所触及的元素数量会迅速增长。确保您的服务器有足够的内存以在内存中保留足够大的图表部分以快速响应您的请求。

并确保尽早进行性能和负载测试（例如使用数据生成器）。

顺便说一句。为了急切地过滤，每个兴趣都有一个不同的关系类型甚至是明智的，这样您就可以在早期过滤而无需实际关注您不感兴趣的关系。

索引通常有助于全局类别，您可以使用名称和用户 ID 为您的类别编制索引，但随后您的用户乘以类别索引条目也可以快速增长。

我认为，如果您的用例真的是针对每个类别而不是针对所有兴趣（尤其是针对所有用户和所有兴趣），那么类别方法应该可以很好地扩展。