3

我刚刚开始使用 neo4j 来评估它是否会成为推荐引擎的良好基础数据库。我想知道是否有关于在读写操作期间在实体上获得的锁的任何文档。

例如，如果节点 N 分别通过关系 R1 和 R2 与节点 N1 和 N2 相关，如果正在创建或修改关系 R1，那么任何使用 N、N1、N2 或 R2 的操作（可能是关系创建/修改或遍历）都会遇到一块？直觉上，我猜不会，因为只有 R1 被写入，这是唯一应该被锁定的实体。但是，我想这也取决于底层实现，特别是因为为每个关系都提供了双向遍历（也许 N 和 N1 会被锁定？）。如果有人可以向我指出一些有关此的官方文档，那就太好了。

如果确实发生了这种锁定，我能想到的解决问题的一种方法是将每个节点解析为每个关系目的的子节点，每个节点都连接到根实体。（比如用户是社交用户，用户是产品用户等）

我想这将允许每个节点的关系数量减少，将根节点解析为写入繁重和读取繁重的子节点，并允许快速检索某些子图。我能看到的唯一缺点是节点和关系的总数增加了 n 倍（我的数据库大小相对较小，n=4，所以我对此没有问题）。任何关于这些结论是否正确的输入，如果是，如果它们有助于提高性能和减少锁的数量，将不胜感激。

4

1 回答 1

0

In your first scenario where R1 (between N and N1) is being created N and N1 will be locked with a write lock, which means that other writes to N or N1 will block, but not reads (if no read lock is issued manually before reading).

In the scenario where R1 is changed somehow (property set) only R1 is locked.

Your solution by splitting an entity into several specific-purpose sub nodes is a reasonably good one, if you observe a real problem with contention. In most occurences I've seen this used it has been a split on relationship type... something that will probably be solved by a planned feature for better handling of densely connected nodes. This feature will probably yield quite similar effects to that.

于 2013-01-01T19:15:33.807 回答