이 Neo4j와 RDBMS 실행 시간의 비교가 정확합니까?

배경 : 다음은 Graph Databases 책에서 발췌 한 것으로 Neo4j 책에서 언급 된 성능 테스트를 다룹니다 .

그래프의 관계는 자연스럽게 경로를 형성합니다. 그래프 조회 또는 순회는 다음 경로를 포함합니다. 데이터 모델의 근본적인 경로 지향적 특성으로 인해 대부분의 경로 기반 그래프 데이터베이스 작업은 데이터가 배치되는 방식과 밀접하게 연계되어있어 매우 효율적입니다. 파트너와 Vukotic는 자신의 저서 Neo4j in Action에서 관계형 상점과 Neo4j를 사용하여 실험을 수행합니다.

파트너와 Vukotic의 실험은 소셜 네트워크에서 친구의 친구를 최대 5 명까지 찾으려고합니다. 두 사람이 무작위로 선택되면 최대 5 개의 관계가있는 사람들을 연결하는 경로가 있습니까? 각각 약 50 명의 친구가있는 1,000,000 명을 포함하는 소셜 네트워크의 경우, 표 2-1에서 볼 수 있듯이 그래프 데이터베이스가 연결된 데이터에 가장 적합한 선택임을 강력하게 제안합니다.

표 2-1. 관계형 데이터베이스에서 확장 된 친구 찾기와 Neo4j의 효율적인 찾기

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

깊이있는 2 (친구)는 관계형 데이터베이스와 그래프 데이터베이스 모두 온라인 시스템에서 이들을 사용할 수있을 정도로 성능이 우수합니다. Neo4j 쿼리는 관계형 쿼리 시간의 3 분의 2에서 실행되지만, 최종 사용자는 둘 사이의 밀리 초 차이를 거의 인식하지 못합니다. 그러나 깊이 3 (친구의 친구)에 도달 할 때까지 관계형 데이터베이스는 더 이상 합리적인 시간 안에 쿼리를 처리 할 수 ​​없다는 것이 분명합니다. 완료하는 데 걸리는 30 초는 완전히 받아 들일 수 없습니다 온라인 시스템. 반대로 Neo4j의 응답 시간은 비교적 평평한 상태로 유지됩니다. 온라인 시스템에 대해 충분히 빠른 속도로 쿼리를 수행 할 수 있습니다.

깊이 4에서 관계형 데이터베이스는 대기 시간이 길어 온라인 시스템에 실질적으로 쓸모가 없습니다. Neo4j의 타이밍도 약간 저하되었지만 여기서 지연 시간은 반응 형 온라인 시스템에 적합합니다. 마지막으로 깊이 5에서 관계형 데이터베이스는 쿼리를 완료하는 데 너무 오래 걸립니다. 반대로 Neo4j는 약 2 초 안에 결과를 반환합니다. 깊이 5에서 거의 전체 네트워크가 우리의 친구입니다. 실제로 많은 유스 케이스의 경우 결과와 타이밍을 다듬을 것입니다.

질문은 :

• 이것은 소셜 네트워크에서 찾을 수없는 것을 모방하기위한 합리적인 테스트입니까? (실제 소셜 네트워크는 평균적으로 약 50 명의 친구가있는 노드를 의미합니다. " 부자 가 많아 질수록 "모델은 소셜 네트워크에 더 자연스러운 것처럼 보이지만 잘못되었을 수 있습니다.)
• 에뮬레이션의 자연성에 관계없이 결과가 잘못되었거나 재현 할 수 없다고 믿을만한 이유가 있습니까?

Facebook의 Anatomy 라는이 문서를 보면 중앙값이 100이라는 것을 알 수 있습니다. 누적 함수 그림을 보면 평균이 200에 가까울수록 내기 할 수 있습니다. 따라서 50이 가장 좋은 숫자는 아닌 것 같습니다. 그러나 나는 이것이 주요 문제가 아니라고 생각합니다.

주요 문제는 데이터베이스 사용 방법에 대한 정보가 부족하다는 것입니다.

그래프 구조를 위해 특별히 설계된 데이터 스토리지가 기존의 RDBM보다 효율적으로 사용되는 것이 합리적입니다. 그러나 RDBM이 선택한 데이터 스토리지로서 최신 트렌드에 있지 않더라도 이러한 시스템은 데이터 세트 차원에 따라 지속적으로 발전했습니다. 가능한 유형의 디자인, 데이터 인덱싱의 다양한 방법, 동시성 관련 개선 등이 있습니다.

결론적으로 재현성에 관해서는 데이터베이스 스키마가 어떻게 설계되었는지에 대한 적절한 설명이 없다고 생각합니다. 데이터베이스가 그러한 심문의 왕을 지배 할 것으로 기대하지는 않지만, 잘 조정 된 디자인으로 차이가 그렇게 크지 않을 것으로 기대합니다.

RDBMS에서 그래프를 모델링하는 좋은 방법과 빠른 방법 및 벙어리 / 느린 방법이 있습니다.

• 더 빠른 그래프 검색 속도를 위해 영리한 인덱싱 및 Stored Proc, CPU로드 및 튜닝 된 임시 테이블을 RAM 디스크에 사용합니다.

• 일부는 사전 계산 된 그래프 경로를 사용합니다 (소셜 네트워크 시나리오에서는 실행하기가 쉽지 않을 수 있지만 대부분의 노드가 리프 노드 인 트리에서는 시간 간격이 꽤 좋습니다).

• 일부는 단순히 튜닝되지 않은 인덱싱 된 임시 테이블을 사용하여 루프에서 계산합니다. 기사에서 던진 #에서, 그것은 그들이 한 것처럼 냄새가납니다 (30 초 성능이 매우 작은 데이터 세트에서)

  예를 들어, 나만의 트리 계산이 있습니다.

  • 고도로 조정 된 저장 프로 시저에 캡슐화됩니다.

  • 엔터프라이즈 크기의 하드웨어 Sybase ASE15 데이터 서버에서 실행되는 동안이 서버는 다른 모든 엔터프라이즈 응용 프로그램 의 몇 테라 바이트 크기의 데이터와 공유됩니다 . 내 쿼리 실행에만 전념하지는 않습니다.

  • 나는 않았다 하지 RAM 디스크의 기본 속도 향상 도구, 임시 테이블에 액세스 할 수 있습니다.

  • 내가 검색 한 대표적인 데이터 세트는 2.5M 노드 전체 포리스트 데이터 세트 (5와 15 사이에서 다양하지만 5에서 15까지 다양하지만 주어진 노드의 평균 arity 보다 작음)에서 150,000 개의 노드 하위 트리를 얻었 습니다. 실험에 나열된 50 명의 친구)

  • 이 쿼리가 ~ 30-45 초가 될 때까지 조정했습니다. 문제의 수치가 RDBMS 성능을 나타내는 것으로 보이는 지수 지수의 둔화를 나타내지 않습니다. 결과 세트에 지수 증가가 없기 때문에 추가로 두 배 이상합니다. 개인적인 경험에서 임시 테이블).

따라서이 비교는 잘못 되었을 가능성이 높으며 RDBMS 측면 설계가 좋지 않은 경우가 많지만 이전 답변에서 언급했듯이 코드 및 테이블 정의를 100 % 소싱하지 않으면 확인할 수 없습니다.