triplestores 대 빠른 쿼리에 대한 네이티브 그래프 dbs

Question

우리가 사용하기 위해 네이티브 그래프 데이터베이스와 트리플 저장소 (RDF 저장소)를 연구 중입니다. 현재 트리플 스토어의 경우 Marklogic에 초점을 맞 춥니 다. Neo4j이고 기본 그래프 db의 경우 OrientDB 일 수 있습니다.

아래 Q의 파트 A는 상황을 설명하고 있습니다.이 두 유형의 DB 간의 주요 차이점을 조사하고 있습니다. 나는이 첫 부분에 대한 검증을 찾고 있는데, 나는이 그림에서 무엇인가를 놓쳤는가.

을 AFAIK 지금까지 :

두 번째 part-- 파트 B

, 나는 각 DB 내가

파트 A 파트 A에 개설하고있어 얼마나 많은 사람들의 얼마나 많은에 대한 답을 찾고 있어요 , 주요 차이점은 트리플 스토어 관계 또는 오히려 관계 자체를 기반으로 가장자리를 저장하는 것입니다. 그래서, 그것은 가장자리의 "봉지"입니다. 각 가장자리는 그 관계의 의미를 반영하기 위해 특수하고 잘 디자인 된 속성을 가지고 있습니다. 반면에 네이티브 그래프 dbs는 노드 구조와 링크를이 노드와 링크에 정의 할 속성과 함께 저장합니다.

나는 다음 두 가지가이 두 가지에 대한 정면보기를 위해 두 극단을 설정한다고 생각합니다. 뒤에 오는 2 개는 극단이다 - 나는 거기 밖으로 dbs가이 극치의 어느 쪽이든보다는 더 많은 것을하고 있다는 것을 아주 확실하다.

1) 에지 백 (트리플 저장소) 전체에 트리플 각 과목 술어 오브젝트라고 (sourceNode, edge, destNode)는 트리플 저장소 항목을 형성하는 하나의 레코드로서 저장된다. 트리플 스토어는이 3 개의 각 열에 대해 색인이 생성되므로 호주에 거주하는 친구가있는 사람의 목록이 필요할 때 i (또는 오히려 트리플 스토어 엔진)가 신속하게 "친구"관계를 얻습니다. 그 중 검색 노드가 사람이고 소스가 "destinations of Australia"인 소스 또는 dest 노드가있는 노드.

2.) 네이티브 그래프 : 레이블과 등록 정보가있는 노드와 그 사이의 링크. "호주에 거주하는 친구가있는 사람"을 찾기 위해 "사람"이라는 레이블이 붙은 노드를 찾은 다음 해당 노드의 관계 목록 (링크 된 목록 (?))을 검색하고 그곳에. 이것은 트리플 스토어의 관계 (트리플)에 대한 하나의 검색과는 대조적으로, 노드에서 하나, 노드에서 두 번째 검색입니다.

나는 트리플 스토어 대 네이티브 그래프 DB의 장단점에 대해 블로그에서 계속해서 보았던 한 가지 사실은 인덱싱 때문에 쿼리에 대한 triplestores 점수라는 점입니다. 관계에 빠르게 액세스 할 수 있습니다. 네이티브 그래프 db에서는 관계가 발생하는 노드를 통해 관계에 액세스합니다. (이 동일한 토큰으로 네이티브 그래프 DB는 그래프 알고리즘과 솔루션을보다 쉽게 ​​구현하고 더 빨리 실행할 수 있도록 그래프 구조를 유지할 수 있다는 이점을 가지고 있음을 알고 있습니다.)

그러나 인덱싱의 부족은 속성 및/또는 레이블에 따라 노드 및/또는 관계의 인덱싱을 허용하는 경우 네이티브 그래프 db의 단점 일 필요는 없습니다. 그것은 그 라벨에 노드와 인덱스의 라벨을 허용하는 경우

• 는 개발자로 나는 전체적인 그래프의 서브 그래프를 가지고 거기에서 갈 수 있습니다. 제한된 도메인에 대한 이러한 쿼리는 훨씬 빠릅니다.

• 관계 레이블을 지정할 수있는 경우 위의 "호주에 거주하는 친구가있는 사람 목록"과 같이 관계를 "회전"하는 쿼리는 더 빨리 실행할 수 있습니다.쿼리가 노드의 링크를 트래버스하지 않고 노드의 속성을 조회하지만 대신 직접 링크를 조회하고 액세스하기 때문입니다. 내가 얼마나 많은 이들의 Marklogic, Neo4j 및 OrientDB가하고있는 궁금

?

this의 제 6 장을 건너 뛰었으며 Neo4j에 관한 책을 읽었으며 가장자리의 색인 (관계)에 대한 직접적인 검색에 대해서는 아무것도 보지 못했습니다. 내가 놓친 것이 있습니까?

Neo4j이 가장자리에서 색인을 생성하는 경우, 네이티브 그래프 dbs보다 빠른 쿼리의 장점이 트리플 스토어에 어떻게 발생합니까?

TIA.

// ----------------------

편집 :

참고 : 나는 다른 유용한 토론 중 Graph DBs vs. Document DBs vs. Triplestores을 보았다 .

Answer 1

OrientDB, 당신은 둘 다 할 수 있습니다

1. 정점 및 상호 관계에서 시작. 예 : SELECT FROM People WHERE 'Australia' IN out('Friend').country
2. 가장자리에서 시작하십시오. 예 : SELECT expand(in) FROM Friend WHERE out.country = 'Australia'

색인이 사용되지 않으므로 두 쿼리 모두 속도가 느려집니다. 이 경우, People.country에 대한 색인을 만들고 '호주'에서 검색어를 시작하고 들어오는 친구들을 교차시키는 것이 가장 좋습니다. 예 : SELECT expand(in('Friend')) FROM People WHERE country = 'Australia'.

Answer 2

파트 A : 트리플 스토어와 그래프 저장소의 차이점 - 차이점은 저장된 내용이 아니라 쿼리 방법에 더 많은 부분이 있습니다.

그래프 저장소는 그래프 쿼리에 응답하는 것을 목표로합니다. 그래프의 구조에 관한 질문을 포함하는 것. 여기에는 예를 들어 고속도로/고속도로를 피하는 등의 조건부 평가 또는 50mph의 한계에서 캐러밴을 운전하는 등 두 지점 간의 최소 거리 (예 : 경로 계획)가 포함되며 계산 된 값 (예 : 거리/시간 가장 좋은 경로 단계). 여기에는 비슷한 하위 그래프와 다양한 다른 그래프 유형 쿼리를 찾는 것도 포함됩니다.

트리플 스토어는 일치하는 주제에 대한 정보를 반환하는 것을 목표로합니다. 예 : "Drug Gang 유형의 조직에 속해있는 다른 사람들을 아는 모든 사람들을 찾아서 자신의 개인 정보를 반환하십시오." 이 쿼리에서는 쿼리하는 네트워크의 경계를 알 수 있습니다 (사람 -> 사람 -> 조직 -> 조직 유형). 그리고 정보 집합 (모든 '사람'주장)을 반환합니다. 이것은 트리플 쿼리입니다.

위의 두 쿼리 유형의 본질 때문에 매우 다른 물리적 아키텍처가 나타납니다. Neo4j와 대부분의 그래프 저장소는 쿼리로드를 확장하는 데 여러 노드가 사용되는 '각 노드에 대한 모든 정보'접근 방식을 채택합니다. 다른 노드는 데이터의 100 % 사본을 포함합니다.

반면 트리플 스토어 (순수한 재생 또는 MarkLogic 및 OrientDB와 같은 NoSQL 데이터베이스)는 여러 서버의 파티션/샤드에 데이터를 분할하도록 설계되었습니다. 따라서 대량의 주석을 필요로하는 대용량 데이터가 아닌 일반 하드웨어의 선형 확장이 가능합니다.단점은 일부 데이터가 여러 서버에 걸쳐있는 경우 로컬 네트워크에서 복잡한 '그래프 스타일'쿼리를 완료해야한다는 것입니다.

그래프 스토어에 트리플을 저장할 수 없거나 트리플 스토어에서 그래프 쿼리를 수행 할 수 없다는 것은 아닙니다.하지만 직접 쿼리를 만들면됩니다. 유형.

MarkLogic의 트리플 저장소에있는 대형 데이터 집합 (예 : '일반'트리플 저장소 쿼리의 경우 보통 수 밀리 초가 아닌)에서 그래프 쿼리에 대한 쿼리 콘솔 예제가 있습니다.

월드 와이드 웹 컨소시엄 (W3C)이 주도하는 트리플 스토어 주변에는 개방 표준이 있습니다. 이러한 표준에는 RDF 및 SPARQL 및 관련 표준이 포함됩니다. 개방형 표준을 사용하면 물론 하나의 제품에 대한 공급 업체 잠금을 피할 수 있습니다. MarkLogic Server 및 Allegrograph는 이와 관련하여 공개 표준을 모두 준수합니다.

W3C 표준의 단점은 RDF에 '관계에 대한 주장'이 없다는 것입니다. 즉, 관계 자체에 속성을 저장할 수 없습니다. Neo4j와 같은 일부 그래프 상점에서는이를 허용합니다. 관계를 트리플 스토어에서 '일'의 유형으로 삼아 모델링 할 수는 있지만 일할 정신적 인 모델이 아닙니다.

문서와 트리플이 모두있는 곳에서는 하이브리드 NoSQL 데이터베이스 둘 다의 인덱싱과 질의를 기본적으로 지원하는 것이 유용합니다. MarkLogic Server와 OrientDB 모두이 기능을 제공합니다. MarkLogic Server는 구조적 (요소가 있거나없는), 필드 (정확한 일치), 범위 (보다 작음,보다 큼), 지형 공간 (특정 폴리곤 등의 영역 내 지점), 양방향 설명 할 공간이 더 많음)과 동일한 레코드에 대한 한 번의 히트에서의 의미 론적 쿼리. 두 가지를 모두 다룰 무언가가 필요하다면, 거기를 보길 원할 것입니다.

내 자신의 작업을 위험에 빠뜨릴 위험이 있으므로 주제에 대한 NoSQL (소매, 400 페이지 버전)과 NoSQL 2016 (kindle 전용)의 두 권의 책으로 모든 배경을 제공합니다. 너는 필요해. 나는 또한 https://adamfowler.org/blog/에 관련된 주제에 관하여 blogged했다. 희망이 도움이됩니다.