나는 그의 데이터 모델이 비순환 적으로 지시 된 그래프라는 것을 알고있는 클라이언트를 가지고있다. 우리는 노드 컬렉션과 가장자리의 중간 테이블로 작업 해 왔으며 그 성능은 꽤 좋았습니다. 현재 구현에서는 100,000 개 미만의 데이터 노드를 보유하고 있지만, 이는 1 ~ 2 배 정도 증가 할 수 있습니다. 그는 최근에 그래프가 있기 때문에 Neo4J 또는 Titan과 같은 그래프 데이터베이스가 "더 좋을 것"이라고 확신하게되었습니다.관계형 데이터베이스에서 어려운 그래프 데이터베이스는 무엇을 해결합니까?
SQL을 사용하여 해결할 수없는 그래프 지향 데이터베이스가 실제로 해결하거나 SQL 클라이언트로부터 훨씬 더 많은 부하를 필요로하는 문제는 무엇입니까? 내가 볼 수있는 것에서는 경로 발견이 인 것처럼 보일 수 있지만 전체적인 이야기는 아닙니다.
관계형 데이터베이스에서 노드와 가장자리는 공통점이있는 값으로 관련됩니다. 노드 또는 에지를 검색하려면 일반적으로이 값에 대한 인덱스를 쿼리해야합니다.
그래프 데이터베이스에서 노드와 에지는 관계형 데이터베이스가 인덱스의 내부 구조를 유지하는 데 사용하는 것과 동일한 종류의 내부 데이터베이스 구조에 의해 직접 관련됩니다. 따라서 가장자리에서 노드 또는 노드의 가장자리를 찾는 것은 노드 수에 관계없이 관계형 인덱스에서 한 단계 깊숙이 들어가는 것과 같습니다. 관계형 데이터베이스에 수백만 개의 노드가있는 경우 색인은 여러 수준으로 깊어집니다.
실제로 mongo에는 "geo spacial"데이터베이스 기능이 내장되어 있으므로 mysql을 사용하여 작업하려는 것처럼 처리해야합니다. 당신이 언급 한 두 데이터베이스 (필자는 Titan과 함께 작업했습니다)는 그래프 작업에 더 좋았으며 PHP 나 db 문에 너무 가혹하지는 않습니다.
간단히 말해서 고장이났다면 고치지 마십시오. 이점이 귀하 또는 귀하의 고객에게 명확하지 않은 경우, 그래프 데이터베이스의 불분명 한 이점에 대해 마이그레이션 비용을 가중 시키십시오.
앞서 언급 한 그래프 데이터베이스에 대한 경험이 없기 때문에, 나는 당신이 가지고있는 데이터 유형에 더 적합한 데이터베이스가 될 수 있기 때문에 그러한 데이터베이스로부터 얻는 것이 더 빠른 개발이라고 가정 할 수 있습니다. 나는 MongoDB와 함께 많은 일을 해왔고 나를위한 케이크의 체리는 데이터베이스 쿼리/쓰기의 단순성으로 인해 개발 속도가 빨라졌으며 스키마를 정의하지 않고 훨씬 더 풍부한 문서 구조가 뒤 따랐다. 또한 수퍼 단순 복제, 자동 장애 조치, 자동 샤딩 등과 같은 놀라운 기능을 얻을 수 있지만 단 한 번의 100k 문서만으로도 이러한 종류의 문제에 관해 곧 생각할 가능성은 거의 없습니다. 모든 주류 관계형 데이터베이스는 소규모 서버에서 실행될 수 있으며 해당 양의 문서를 잘 수행 할 수 있습니다.
다양한 쿼리에 필요한 "탐색의 깊이"만큼이나 "노드 수"가 아닙니다. 물론 중첩 세트 및 계층 적 ID 및 연결과 같은 관계형 데이터베이스 접근 방식이 있지만 이러한 매핑은 종종 트리를 사용하도록 설계되었으며 덜 엄격한 [DAG] (http://en.wikipedia.org/wiki/Directed_acyclic_graph)와는 작동하지 않도록 설계되었습니다. 물론, 포스트가 개별 노드/에지 테이블에서 힌트를 얻은 이후로, 나는 DAG가 이미 사용되고 있다고 의심합니다. 그런 다음 DAG는 다시 순회 깊이로 돌아갑니다. –