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

Question

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

(正在开发社交网络应用程序 - 如果您知道任何“通用”社交网络设计，请指出它们……会有帮助)

看这张图——状态更新代表一个链表，而兴趣代表杂项兴趣。对于一个用户来说，这些兴趣真的可以爆炸到数千个节点——这不会导致某种 super 节点问题吗？

图1

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

例子:图 2 用户
|
+ 兴趣+
+----- 兴趣
+----- 兴趣
+----- 等等...

而且不应该interests也有“sub header”类别节点，比如“books”，“movies”，“products”这样的:

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

(显然我是 neo 的新手)

这是我的问题:

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

2. 兴趣可能不会总是激增到数千个节点 - 可能是十几个或 100 个 - 添加类别的设计是否会增加太多开销？考虑尝试寻找与您喜欢相同内容的 friend - 添加类别是否会增加太多开销？
   

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

4. 除了类别节点，是否应该有一个类别属性来描述它属于哪个类别？在索引上添加具有类别属性的节点会和拥有类别节点一样好吗？
   

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

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

Answer 1

我认为当您的兴趣激增到数十万或数百万连接时，兴趣类别是个好主意，如果它只有几千个，它应该也足够好。也许这甚至是您可以在实际需要时将您的用户节点发展到的东西。 (就像推特上对 super 巨星的不同处理)。

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

您始终需要考虑的一点是，接触到的关系的数量将随着您遍历图中的每一步而呈指数增长。所以请注意，如果您从一个用户查询到它的所有 friend 或 friend 的 friend 及其所有兴趣，接触的元素数量会迅速增长。确保您的服务器有足够的内存来在内存中保留足够大的图形部分，以便快速响应您的请求。

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

顺便说一句。为了急切地过滤，每个兴趣都有一个不同的关系类型甚至可能是明智的，这样您就可以尽早过滤而不必真正关注您不感兴趣的关系。

索引通常有助于全局类别，您可以使用类别的名称和用户 ID 来索引您的类别，但随后您有用户时间类别索引条目，这些条目也可以快速增长。

如果您的用例确实是关于每个类别而不是所有兴趣(尤其是所有用户和所有兴趣)，我认为类别方法应该可以很好地扩展。