基于Neo4j的应用架构 - 采用普通节点和关系使用基本API还是采用Spring/GORM？

Question

我希望听取那些设计和实现过大型 Neo4j 应用程序（数千万节点/关系）的人的建议，特别是在建模和使用各种 API 方面（纯 Java/Groovy Neo4j vs Spring-Data-Neo4j vs Grails GORM/Neo4j）。我想知道是否值得添加额外的 OGM（对象图映射）层及其相关抽象？是否有人发现最好坚持使用“普通”的图形建模方式，包括节点+属性、关系+属性、遍历和（例如）Cypher 来建模和存储数据？我的担忧是，“强制”某个 OGM 抽象到一个图形数据库中将影响未来适应/更改领域模型以及查询数据的灵活性。我们是一个 Grails 店，我已经尝试过 GORM/Neo4J 和 spring-data-neo4j。这个数据集的主要目的是对大量人员、他们的别名、他们的联系人以及所有类型的犯罪活动和历史进行建模和查询。将有超过 50 个主要的领域类。模型必须具有灵活性（在项目早期阶段需要快速演变），并具有灵活性和查询速度。我必须承认，当我可以使用 POJOs 或 POGOs、一点 Groovy 魔法和一些简单的手动编写的域对象<->节点/关系映射代码时，我很难找到使用 OGM 层的充分理由。据我所知，我认为只使用节点、遍历和 Cypher（即 KISS）就足够了。但我非常乐意听取其他人的经验和建议。谢谢你的时间和思考，TP。

- Tim Pedersen

Answer 1

作为Grails Neo4j插件的作者，我可能有偏见。创建该插件的主要原因是将Grails领域类的易用性和强大的开箱即用脚手架应用于Neo4j的约80%的使用情况。对于另外20%需要遍历等特定需求的情况，我们直接使用Neo4j API（遍历/ Cypher），而不使用GORM API。

当前版本的Neo4j插件存在超级节点问题，因为每个领域实例都连接到子参考节点。如果多个并发请求（线程）添加新的领域实例，则有可能出现锁定异常。我将通过子子参考方法或使用索引来解决这个问题。

Cypher也可以在Neo4j Grails插件中使用。

另一方面，Spring-Data-Neo4j是一种更高级的方法，可以更精细地控制映射细节，但需要使用特定注释。我没有找到将其轻松集成到Grails中的方法，以使脚手架工作。

我们正在一个拥有约60k用户和约10^6关系的生产应用程序中使用插件的前身版本。由于保密协议，我无法提供更多详细信息。

- Stefan Armbruster

---

谢谢Stefan，实际上我打算直接联系您，询问您在GORM/Neo4J插件方面的“现实生活”经验。我正在尝试避免在使用Neo4J时出现常见的架构和编码“陷阱”，特别是在使用对象图映射层的情况下。 - Tim Pedersen

Answer 2

我们不使用Grails，但使用混合的纯neo4j/spring-data-neo4j解决方案。原因基于我们的某些领域数据有一个固定的模式，而另一些则没有。SDN可以减轻很多负担，并且在需要时可以与纯neo4j混合使用。

我们有描述数据模型的类，我们使用SDN持久化这些类的对象，没有其他技巧，只是使用SDN的基础知识。然后我们有包含未预先知道的模型数据的类。这些类存储在节点中，包含用于描述数据所属模型类型的特殊属性。当neo4j 2发布后，我们可能会将该信息移动到标签中。在这些节点之间可能存在关系，也由SDN管理上述数据模型进行描述。我们还有从通用节点到SDN节点的关系，这很好用，因为所有东西最终都成为相同的事物：节点。

使用这种方法，我们尚未遇到任何问题。我们最喜欢的是，我们事先不知道如何对数据进行建模的数据以您希望在预先了解它时存储数据的方式进行存储，使得数据实际匹配所选的模型，当使用其他类型的（非图形）数据库时，这是非常难做到的。

- Wouter

---

当Spring 2发布时，您可能是指"neo4j 2"吗？ - t0r0X