我刚开始使用 neo4j 来评估它是否是推荐引擎的良好基础数据库。我想知道是否有关于在读写操作期间在实体上获得的锁的任何文档。
例如如果节点 N 分别通过关系 R1 和 R2 与节点 N1 和 N2 相关，如果正在创建或修改关系 R1，则使用 N、N1、N2 或 R2(可能是关系创建/修改或遍历)的任何操作都会遇到堵塞 ？直觉上，我猜不会，因为只有 R1 被写入，并且这是唯一应该被锁定的实体。但是，我想这也取决于底层实现，特别是因为为每个关系提供了双向遍历(也许 N 和 N1 会被锁定？)。如果有人能指出一些关于此的官方文档，那就太好了。
如果确实发生了这种锁定，我能想到的一种解决问题的方法是将每个节点解析为每个关系目的的子节点，每个节点都连接到根实体。 (假设用户是社交用户，用户是产品用户等)
我想这将允许每个节点的关系数量减少，将根节点解析为写入繁重和读取繁重的子节点，并允许快速检索某些子图。我能看到的唯一缺点是节点和关系的总数增加了 n 倍(我的数据库大小相对较小，n=4，所以我对此没有问题)。任何关于这些结论是否正确的意见，如果是的话，如果它们有助于提高性能和减少锁的数量，将不胜感激。
最佳答案
在创建 R1(在 N 和 N1 之间)的第一个场景中，N 和 N1 将被写入锁锁定，这意味着对 N 或 N1 的其他写入将被阻塞，但读取不会(如果没有读取锁)阅读前手动发布)。
在 R1 以某种方式更改(属性集)的情况下，只有 R1 被锁定。
如果您观察到一个真正的争用问题，您通过将一个实体拆分为几个特定用途的子节点的解决方案是一个相当不错的解决方案。在大多数情况下，我已经看到它使用它是关系类型的 split ......这可能会通过计划的功能来解决，以便更好地处理密集连接的节点。此功能可能会产生与此非常相似的效果。
关于java - neo4j 事务锁，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14012096/