2013-10-28 2 views
3

다른 노드와 주어진 관계 유형이없는 db의 모든 노드를 선택하려고합니다.특정 유형의 관계가없는 노드 선택

다음은 내 db 구조입니다. 이벤트 노드를 게시하는 사용자 노드가 있습니다. 게시 관계는보다 구체적이며 다양한 유형의 관계가 있습니다 (예 : type1type2).

type1 이벤트가있는 모든 사용자 노드를 신속하게 선택할 수는 있지만 이벤트가있는 개의 관계가 없습니다.

START u = node:users("*:*") 
MATCH (ev1)<-[r1:type1]-(u)-[r2?:type2]->(ev2) 
WHERE r2 IS NULL 
RETURN u 

문제는 R2는 선택의 관계입니다 :

여기에 내가 지금 사용하고 쿼리입니다. 이것은 위의 쿼리를 아주 느리게 만들어서 neo4j 문서가 말하는 것을 확인합니다.

이 쿼리의 속도를 향상 시키려면 어떻게해야합니까? 성능을 향상시키기 위해 데이터를 더 잘 모델링 할 수 있습니까?

감사합니다. 알렉스

+0

의 중복 가능성 [사이퍼가 : 특정 사용자가 아직 평가하지 않은 영화를 찾기] (http://stackoverflow.com/questions/19543957/cypher-finding-movies-that-havent-been- 특정 사용자별로 평가 됨) –

+0

@StefanArmbruster 내가 추천 한 질문에서 대답을 사용했으며 쿼리 응답 유형이 50 % 증가했습니다. 여기에 내가 사용한 검색어가 있습니다 : start u = node : users ('* : *') 일치 (u) - [: type1] ->() 여기서 (u) - [: type2] ->() return count (distinct (u)) –

+0

@StefanArmbruster 그러나 이제 어디서 관계/노드에 대한 참조를 첨부 할 수 없는지 알았습니다. 예. '... (u) - [r2 : type2] -> (ev2) ...'이 오류를 발생시킵니다 : 알 수없는 식별자 'ev2'. 알 수없는 식별자'r2'. 어떤 해결책? –

답변

4

발견 된 해결책은 사용 사례에 따라 두 배입니다. 나는이 있었다 :

  1. 유형 type1의 관계를 가지고 있지만 유형 type2의 관계가없는 모든 사용자 노드를 찾습니다.

    START u = node:users("some query") 
    MATCH (ev1)<-[r1:TYPE1]-(u)-[r2?:TYPE2]->(ev2) 
    WHERE r2 IS NULL 
    RETURN u 
    

    또는 패턴에 필터링을 채택하여 빠른 변형을 사용

두 쿼리는 하나 neo4j 설명서 사용에 대해 경고 optional relationships 사용하여이 문제를 해결할 수 있습니다.

  1. START u = node:users("some query") 
    MATCH (ev1)<-[r1:TYPE1]-(u) 
    WHERE NOT (u)-[:TYPE2]->() 
    RETURN u 
    
    Docs 유형 type1의 관계를 가지고 있지만 특정 속성을 가진 노드 유형 type2의 관계가없는 모든 사용자 노드를 찾습니다.

    START U = 노드 : 사용자 ("일부 쿼리") MATCH (EV1) < - [R1 : TYPE1] - (U) - [R2 : TYPE2] -> (EV2) WHERE ev2.property = 값 및 r2.property = 값 RETURN U 내 질문에 내가 위의 쿼리 속도를 높이기 위해이 조언을 추가 할 것입니다, 그것을 성능 메모를했다 감안할

:

  • 인덱스로 영리를 Lucene에서 가능한 한 많은 쿼리 조건으로 이동합니다. f ROM에 WHERE 색인을 추가하십시오. 시작 노드의 수를 줄이기위한 노력의 전부입니다! 노트! 대량 색인은 쓰기 성능을 저하시킵니다. 사용 가능한 쿼리 구문은 lucene docs을 참조하십시오.
  • 매개 변수 쿼리를 사용하면 neo4j가 쿼리의 실행 전략을 캐시 할 수 있습니다.docs
+0

@StefanArmbruster 맞습니까? –

+0

강력한 +1 매개 변수화 된 키퍼를 사용 중입니다. 인덱싱 거래는 항상 읽기 성능을 위해 성능을 씁니다. 그래서 "가능한 한 많은 인덱스"가 약간 오도하는 것처럼 들리므로 시작 노드의 잠재적 인 수를 줄이기 위해 "가능한 한 현명한 인덱스"여야합니다. –

+0

@StefanArmbruster 수정 됨! 10 배 –