Neo4j SDN 4图形性能与指数

在我的Neo4j/SDN 4应用程序中，我的所有密码查询都基于内部Neo4j ID

这是一个问题，因为我不能在我的web应用程序URL上依赖这些ID。Neo4j可以重用这些ID，因此很有可能在将来的某个时候，在相同的ID下，我们可以找到另一个节点

我试图根据以下解决方案重新实现此逻辑：但发现查询性能下降

从理论上看，基于

@Index（unique=true，primary=true

）属性的密码查询是否应该

例如：

@Index(unique = true, primary = true)
private Long uid;

entity.uid = {someId}

@NodeEntity
public abstract class BaseEntity {

    @GraphId
    private Long id;

    @Index(unique = false)
    private Long uid;

    private Date createDate;

    private Date updateDate;

...

}

@NodeEntity
public class Commentable extends BaseEntity {
...
}

@NodeEntity
public class Decision extends Commentable {

    private String name;

}

使用与基于内部Neo4j ID的密码查询相同的性能：

id(entity) = {someId} 

已更新

这是

：模式

输出：

Indexes
   ON :BaseEntity(uid) ONLINE
   ON :Characteristic(lowerName) ONLINE
   ON :CharacteristicGroup(lowerName) ONLINE
   ON :Criterion(lowerName) ONLINE
   ON :CriterionGroup(lowerName) ONLINE
   ON :Decision(lowerName) ONLINE
   ON :FlagType(name) ONLINE (for uniqueness constraint)
   ON :HAS_VALUE_ON(value) ONLINE
   ON :HistoryValue(originalValue) ONLINE
   ON :Permission(code) ONLINE (for uniqueness constraint)
   ON :Role(name) ONLINE (for uniqueness constraint)
   ON :User(email) ONLINE (for uniqueness constraint)
   ON :User(username) ONLINE (for uniqueness constraint)
   ON :Value(value) ONLINE

Constraints
   ON ( flagtype:FlagType ) ASSERT flagtype.name IS UNIQUE
   ON ( permission:Permission ) ASSERT permission.code IS UNIQUE
   ON ( role:Role ) ASSERT role.name IS UNIQUE
   ON ( user:User ) ASSERT user.email IS UNIQUE
   ON ( user:User ) ASSERT user.username IS UNIQUE

如您所见，我在

：BaseEntity（uid）

BaseEntity

是我的实体层次结构中的基类，例如：

@Index(unique = true, primary = true)
private Long uid;

entity.uid = {someId}

@NodeEntity
public abstract class BaseEntity {

    @GraphId
    private Long id;

    @Index(unique = false)
    private Long uid;

    private Date createDate;

    private Date updateDate;

...

}

@NodeEntity
public class Commentable extends BaseEntity {
...
}

@NodeEntity
public class Decision extends Commentable {

    private String name;

}

这个

uid

索引是否会在我查找

（d:Decision）的示例时使用，其中d.uid={uid}

配置文件结果-内部ID与索引属性

基于内部ID的查询

PROFILE MATCH (parentD)-[:CONTAINS]->(childD:Decision) 
WHERE id(parentD) = 1474333 
MATCH (childD)-[relationshipValueRel1475199:HAS_VALUE_ON]-(filterCharacteristic1475199) 
WHERE id(filterCharacteristic1475199) = 1475199 
WITH relationshipValueRel1475199, childD 
WHERE  ([1, 19][0] <= relationshipValueRel1475199.value <=  [1, 19][1] )  
WITH childD  
MATCH (childD)-[relationshipValueRel1474358:HAS_VALUE_ON]-(filterCharacteristic1474358) 
WHERE id(filterCharacteristic1474358) = 1474358 
WITH relationshipValueRel1474358, childD 
WHERE  (ANY (id IN ['Compact'] WHERE id IN relationshipValueRel1474358.value ))  
WITH childD  
MATCH (childD)-[relationshipValueRel1475193:HAS_VALUE_ON]-(filterCharacteristic1475193) 
WHERE id(filterCharacteristic1475193) = 1475193 
WITH relationshipValueRel1475193, childD 
WHERE  (ANY (id IN ['16:9', '3:2', '4:3', '1:1'] 
WHERE id IN relationshipValueRel1475193.value ))  
WITH childD  
OPTIONAL MATCH (childD)-[vg:HAS_VOTE_ON]->(c) 
WHERE id(c) IN [1474342, 1474343, 1474340, 1474339, 1474336, 1474352, 1474353, 1474350, 1474351, 1474348, 1474346, 1474344] 
WITH childD, vg.avgVotesWeight as weight, vg.totalVotes as totalVotes 
WITH * MATCH (childD)-[ru:CREATED_BY]->(u:User)  
WITH ru, u, childD , toFloat(sum(weight)) as weight, toInt(sum(totalVotes)) as totalVotes  
ORDER BY  weight DESC 
SKIP 0 LIMIT 10 
RETURN ru, u, childD AS decision, weight, totalVotes, 
[ (parentD)<-[:DEFINED_BY]-(entity)<-[:COMMENTED_ON]-(comg:CommentGroup)-[:COMMENTED_FOR]->(childD) | {entityId: id(entity),  types: labels(entity), totalComments: toInt(comg.totalComments)} ] AS commentGroups, 
[ (parentD)<-[:DEFINED_BY]-(c1)<-[vg1:HAS_VOTE_ON]-(childD) | {criterionId: id(c1),  weight: vg1.avgVotesWeight, totalVotes: toInt(vg1.totalVotes)} ] AS weightedCriteria, 
[ (parentD)<-[:DEFINED_BY]-(ch1:Characteristic)<-[v1:HAS_VALUE_ON]-(childD)  WHERE NOT ((ch1)<-[:DEPENDS_ON]-())  | {characteristicId: id(ch1),  value: v1.value, totalHistoryValues: toInt(v1.totalHistoryValues), description: v1.description, valueType: ch1.valueType, visualMode: ch1.visualMode} ] AS valuedCharacteristics

配置文件匹配（parentD）-[：CONTAINS]->（childD:Decision）
其中id（parentD）=1474333
匹配（childD）-[relationshipValueRel1475199:HAS_VALUE_ON]-（filterCharacteristic1475199）
其中id（filterCharacteristic1475199）=1475199
与关系ValueRel1475199，childD
其中（[1,19][0]（u:用户）
以ru、u、childD、toFloat（总和（重量））作为权重，toInt（总和（总票数））作为总票数
按重量说明订购
跳过0限制10
返回ru、u、child作为决策、权重、总投票数，
[（parentD）您不应该在web URL中使用Neo4j内部ID，因为它们可以在删除节点后重新使用，等等

从性能角度看，内部id的速度与您所能获得的速度一样快-它实际上是带有节点/关系记录的文件中的一个偏移量（您可能已经注意到这是两个独立的id序列，您可以拥有id=z的节点和id=x的关系）

索引的任何使用都必须较慢，因为数据库首先进行索引查找，获取内部id，然后读取节点记录

但是，对于绝大多数应用程序而言，性能差异可以忽略不计——可能比网络延迟或一般OGM开销小得多

如果你看到明显的不同


验证数据库中是否存在索引（例如Neo4j浏览器中的
：schema
）
打开日志记录并验证您的查询具有正确的标签（为
org.neo4j.ogm
设置
info
级别）
如果索引存在且查询包含右标签，则使用
PROFILE
检查查询计划

已更新

是，索引将用于以下查询：

MATCH (d:Decision) WHERE d.uid = {uid} ...

应该由

session.load(Decision.class, uid)

如果索引是主索引或
DecisionRepository
上的
findByUid

注意，当WHERE子句出现在查询中间时，索引可能不被使用：
...
WITH x
MATCH (x)-[...]-(d) WHERE d.uid = {uid} ...

这取决于查询计划，您应该使用
PROFILE
来调查这一点。
谢谢您的回答。现在我正在尝试一种方法来重构我的系统，以避免ID重用问题，我看到以下模式-在我的web URL中，我将使用代理uid。如果不需要将ID放置在web url我将使用内部Neo4j id。因此，代理uuid将仅在web url中使用，否则在客户端的所有其他位置，我将使用内部Neo4j id。这有意义吗？有两种方法通过id访问实体可能会不必要地使事情复杂化。我只会使用自定义uuid。正如我所说的，索引速度很快，内部d和索引查找将比网络延迟或一般OGM开销小几个数量级因此，基于纯uid的方法的性能下降是显而易见的。我已经更新了我的问题，并提供了：schema命令和我的SDN实体层次结构的输出。你能看一下吗？我已经添加了内部id与索引uid的配置文件信息-差异是238与426ms。有没有可能基于uid提高性能？