동일한 값을 갖는 문자열 속성이 실제로있는 노드 유형이 있습니다. 그 문자열 값의 옵션이 5 개 밖에없는 수백만 개의 노드. 나는 그 재산에 의한 수색을 할 것이다.Neo4j 디자인 : 속성 대 "노드 및 관계"
내 질문에 성능과 메모리면에서 무엇이 더 좋을까요? a) 노드 속성으로 구현하고 중복 된 부분이 많습니다 (그리고 WHERE를 사용하여 검색). b) 5 개의 추가 노드로 구현합니다. 모든 원래 노드는 그 중 하나를 참조합니다 (추가 MATCH를 사용하여 검색).
자세한 내용을 알지 못해도 일반적인 목적의 대답을하기가 어렵습니다.
성능 측면에서 가능한 한 빨리 검색을 제한하는 것이 좋습니다. 순회를 위해 속성을 조사 할 필요가없는 경우 더욱 유용합니다.
필자는 lookup 속성을 별도의 노드로 이동하고이 값을 관계 유형으로 사용하는 것이 더 낫다고 가정합니다.
저는이 문제에 대해서도 조금 생각했습니다. 내 경우, 나는 국가 대표했다 :
전체 노드 + 관계 접근 방식은 그 단 하나의 관계를 더 매력적 보이는 완료가 제출 참조는 속성 문자열이 아닌 매번 유지되어야하며 추가 속성을 유지 관리해야하는 추가 색인을 스캔 할 필요가 없습니다 (메모리와 성능은 직관적으로 b e).
또 다른 장점은 노드가 여러 "특수 노드"에 링크되는 기능을 쉽게 지원한다는 것입니다. 모델에서 이것이 가능해야하는 상황을 예상하는 경우 속성 배열을 사용해야하는 것 (및 "in"을 사용하여 검색하는 것)보다 낫습니다.
실제로 문제가 발생했다는 것을 알았습니다. 매번 이러한 특수 노드에 어떻게 액세스합니까? 어느 특정 종류의 상수 참조를 유지할 수 있습니다.이 특수 노드의 노드 ID는 시작 문 (여기는 우리가하는 것)에서 바로 이동할 수 있습니다. 그렇지 않으면 특수 노드의 속성에 대한 검색을 수행해야합니다. 노드마다 (이름, 아마도) 그 관계를 따라 이동합니다. 이것은 사이퍼 쿼리가 가장 예쁜 것은 아닙니다.
난 정말 관계 유형으로 값을 사용하는 아이디어를 좋아하는이 블로그 게시물이 새로운 Neo4j 2.0 기능에 좋은 소개입니다. 그렇다면이 새로운 관계를 가리킬 데이터가없는 쓸모없는 노드가 하나만 필요합니다. 또 다른 질문은 다음과 같습니다. 단일 노드에 대한 백만 건의 관계에 성능 문제가 있습니까? 나는 그 노드에서 어떤 검색도하지 않을 것이다. 또한 루트 노드를 사용하는 것이 합리적일까요? – Martynas
해당 노드로만 이동하는 한 성능 저하가 없습니다. 만약 당신이 다른 방향으로 나아 간다면, 당연히 1 백만의 관계를 조사해야 할 것입니다. –
루트 노드를 사용하지 않는 것이 좋습니다.루트 노드에 연결된 새로운 노드를 만들 수 있습니다. 그렇지 않으면 내 생각에 나쁜 모델링 전략 인 여러 다른 개념으로 루트 노드를 채울 수 있습니다. –