그래프 데이터베이스 (내 케이스 Neo4j)를 사용하면서 동일한 정보를 여러 가지 방법으로 표현할 수 있습니다. 각 엔티티를 노드로 만들고 관계를 통해 모든 엔티티를 연결하거나 Node.diff의 속성 목록에 엔티티를 추가하기 만하면노드 vs 속성의 모든 정보를 저장, 계산에 어떻게 나타내야합니까?
다음은 동일한 데이터의 두 가지 다른 표현입니다. 
전반적으로 어떤 메커니즘이 어떤 조건에서 적합합니까?
이 사용 사례는 4 개의 깊이가 될 때까지 다른 노드에서 데이터베이스를 탐색하고 연결된 노드 또는 속성을 통해 정보를 검사하는 방식입니다 (접근 방식에 따라 다름). "Stanford에 간 John의 친구는 누구입니까?" 스토리지 측면에서의 차이를 무엇
은, 첫 번째는 당신이 그런 Stanford- 같은 기관에 질의하고 있기 때문에 훨씬 더 그 실체가 많은 사람 노드와 관련이
을 계산들이. 노드로 모델링하는 것이 더 직관적이고 쉽게 쿼리 할 수 있다고 생각합니다. "Stanford에 온 모든 사람을 찾으십시오"라는 말은 두 번째 모델에서 지나치는 곳이 없기 때문에 쉽지 않을 것입니다. 속성을 주로 사용하여 노드/엔티티를 설명하여 쿼리의 결과를 필터링하는 데 사용합니다. 2010 년에 스탠포드에 온 존의 친구는 누구입니까?이 경우 연도 속성은 결과를 다듬기 위해 사용됩니다. 사용 사례에 따라 다르지만, 1 년이 정말로 중요하고 많은 쿼리를 유도하거나 타임 라인을 나타내는 데 사용되면 스탠포드에 연결된 노드로 그 해를 모델링 할 수도 있습니다.
일반적으로 속성은 지연되어로드되며 캐시, 특히 문자열에 보관하는 것이 더 비쌉니다. 노드와 관계는 탐색에 가장 효과적입니다. 특히 관계 유형이 관계 레코드와 함께 저장되므로 탐색에 사용될 때 속성로드를 트리거하지 않기 때문에 특히 효과적입니다.
또한 균형 잡힌 그래프 (즉, 10K 이상의 관계가있는 많은 조밀 한 노드가 아닙니다.)가 가장 효과적입니다.
대부분의 reoccurring proeprties를 엔티티에 연결하는 노드로 모델링하려고 했으므로 그래프 자체를 사용하여 값을 필터링하거나 속성 값을 비싼 인덱스로 되돌릴 필요가 없습니다 조회.
Thanks Peter. Neo4j 내부의 누군가가 말하지 않는다면, 그가 결정할 수있는 근거가 없다. Neo4j에 대한 사실을 어디에서 찾을 수 있습니까? "일반적으로 속성은 느슨하게로드되며 캐시, 특히 문자열에 보관하는 것이 더 비쌉니다." Neo4j 사이트에서 이러한 정보를 사용할 수 있다면 우리의 결정에 큰 변화가있을 것입니다. – Sravan
피터는 neo4j에서 왔습니다 .-) 설명서에서 성능 가이드를 보았습니까 : http://docs.neo4j.org/chunked/stable/performance-guide.html – Luanne
답변 해 주셔서 감사합니다. 쿼리를 작성하는 것이 얼마나 쉽고 어렵다는 것이 아니라 저장 및 계산 측면에서 성능에 영향을줍니다. – Sravan