问题描述
据我所知，一旦在Spring Data Neo4j中加载了NodeEntity，默认行为是通过仅获取相关节点的ID来延迟加载其关系。 尽管在大多数情况下看起来还可以，但对于所谓的“超级节点”（与其他节点有很多关系的节点），我对此表示怀疑。 这类节点即使本身很小，也将拥有大量的id，使用的内存比我们想要的要多，并且实际上可能没有“延迟加载”。
所以我的问题是-我应该如何处理这种超节点？
我的第一个想法是从此类节点中删除所有@ RelatedTo / @ RelatedToVia映射（或至少删除具有“大量”关系类型的那些），并在需要对这些关系进行操作时仅绕过SDN，并在其他情况。 看起来有道理吗？ 在这种情况下，您还有其他建议或经验吗？
1楼
我尚未使用SDN，但将尝试尝试近似元节点。 通过这种近似，您可以构建一个结构，将关系的总数划分为多个元节点的数量（如果一个节点具有1000个连接，而您使用10个元节点，则每个元节点将具有100个连接，而超级节点只有4个。您可以看到图形表示在下面的图片中： : 。
这样，您可以很好地控制一个节点可以有多少个关系，因此可以最大程度地由SDN加载多少个节点。
您可以在上阅读有关它的更多信息，也可以在此类似的帖子中
2楼
首先，您能否提供正在使用的SDN版本，以便我们将问题定位到库的正确维护者。
其次，虽然我并不真正了解SDN的内部原理，但是与其他OGM进行了大量合作，但是我对LazyLoading的理解与您提供的完全不同，原因很简单，因为懒惰地加载id在某种意义上是非常有害的如果另一个进程正在删除具有这些ID之一的节点之一，则可能损坏了数据。
通常，这在其他OGM中非常普遍，如果对象没有表示关系的注释，则只需从其元数据和已加载的节点重新创建该对象。
但是，如果它具有关系，则应创建该对象的代理，以扩展实体本身。
代理上的实体值不会在第一个实例中实例化，然后您将覆盖所有getter并在代理中添加用于检索相关节点的方法（因此，实体管理器将注入到代理中）。
因此，基本上，一个代理将是空的，直到您在其上调用一个getter为止。
您还可以通过创建扩展默认数据库的自定义存储库来“细粒度”此行为，在某种意义上，您可以选择仅LAZY_LOAD一种关系类型，而EAGER_LOAD其他类型。
albert描述的方法在某些情况下很有意义，但是在基本的OGM方面很难实现，您最好有一个BehaviorComponent在生命周期事件中为您处理，或者在getter中添加某种分页方法，我认为该方法目前不在OGM中。
3楼
对于超级节点，我只是不指定超级节点实体上的关系。 但仅在相关节点上。
并且，如果您对关系感兴趣，则可以查找相关节点并跟随超节点。
或者，如果您确实需要加载数百万个关系，请使用cypher语句。
为此，您也可以将许多关系放在单独的节点上，或者添加树状子结构，该子结构还可以处理子选择。