본문 바로가기
카테고리 없음

Neo4j의 "10¹² (1,000,000,000,000)" 그래프의 숨겨진 진실

Jacob_ 2022. 6. 14. 11:40

Neo4j의 "10¹² (1,000,000,000,000)" 그래프의 숨겨진 진실

 

Mingxi Wu

2021년 8월 12일

블로그, 벤치마크

 

 

Neo4j의 100TB 데모는 눈가림 속임수 마술에 가깝습니다.

제가 그래프 데이터베이스 벤치마크(graph database benchmarks)에 관심 갖게 된 계기는 SIGMOD 2018에서 Peter Boncz(LDBC 의장)와의 대화였습니다. 그는 관계형 데이터베이스 벤치마크로 유명한 TPC-H를 분석할 때 사용했던 "필수병목지점(choke point)" 이라는 개념을 저에게 소개하였습니다. 그리고 그래프 데이터 관리 벤치마크인 LDBC-SNB(Linked Data Benchmark Council – Social Network Benchmark)를 설계할 때 그 필수병목지점 방법론을 사용했다고 하였습니다. 그 당시 저는 단순비교를 위해 토폴로지만으로(속성이 없는 노드와 엣지) 구성된 데이터셋을 사용하고 k-홉 쿼리, PageRank와 Connected Components와 같이 잘 알려진 반복 알고리즘에 의존하는 6개의 그래프 데이터베이스에 대한 비교를 완료하였습니다(이것은 업계 최초였고, 그 이후 다른 그래프 스타트업 및 학계의 벤치마크 보고서가 이어졌습니다).

저는 TigerGraph에서 가장 큰 규모의 은행, 헬스케어, 유통 및 제조 기업과 함께 일하면서, 이러한 벤치마크가 엔터프라이즈급 그래프 데이터베이스를 평가하기에는 현실세계의 요구 사항과 거리가 있다는 것을 깨달았습니다. 저는 복잡한 현실세계의 그래프 쿼리 패턴에 좀더 가까운 그래프 벤치마크를 찾고 있었고, LDBC-SNB가 제가 찾던 바로 그 벤치마크였습니다.

그때부터 TigerGraph는 릴리스 성능(release performance)평가용 벤치마크 제품 군으로 LDBC-SNB를 채택했으며 가장 큰 LDBC-SNB 데이터 셋(2019년 1TB, 2020년 5TB)를 사용하여 확장성 측면에서 세계기록을 지속적으로 갱신하였습니다.

최근에 Neo4j는 100TB 규모로 LDBC-SNB 쿼리를 실행했다는 것을 홍보했습니다(51분48초에 시작하는 비디오는 여기, 데모의 소스 코드는 여기를 참고하세요). 처음에 저는 그 소식을 듣고 큰 관심을 가졌습니다. 왜냐하면 존경 받는 우리의 경쟁자가 확장성에 초점을 맞추기 시작했고 그래프 유즈케이스용으로 현실세계를 반영한 빅데이터셋의 중요성을 깨달았기 때문입니다. 그러나 그 데모의 실제 내용을 보고 난 후 정말 실망하였습니다. 소위 100TB 데모로 불리는 이것은 LDBC-SNB 벤치마크를 제대로 활용하지 않았기 때문입니다. 그것은 순전히 마케팅을 위한 속임수였습니다. 즉, 이것은 실제 비즈니스 문제를 해결하고자 하는 실무자에게 유용한 데모가 아닙니다.

이 블로그는 벤치마킹이 왜 중요한지 논하고 Neo4j의 100TB 데모가 왜 속임수인지를 보여 줄 것입니다.

제 배경에 대해서 간단히 말씀 드리겠습니다. 저는 ISO GQL 표준 위원회에 속해 있으며 GQL 그래프 쿼리 표준에 적극적으로 기여하고 있습니다. 저는 20년 동안의 연구(플로리다 대학의 데이터베이스 박사 교육과정)와 데이터베이스 분야에서의 개발 경험(마이크로소프트, 오라클, Turn Inc. 및 TigerGraph)을 바탕으로 이 블로그를 작성 하고 있습니다.

저는 이 기술 블로그를 통해 데이터베이스를 처음 접하는 일반 독자들이 쉽게 읽을 수 있도록 최선을 다 하였습니다.

 

Neo4j의 최근 100TB 데모에 대한 요약

간단히 말해서, Neo4j는 LDBC 벤치마크라는 이름과 그래프/테이블 스키마를 사용하여 실생활에는 쓸모가 없는 단순화된 더미 데이터셋을 생성했고(엔터티들 간의 상관관계와 엣지 및 관계차수에 현실성이 없는), Neo4j가 확장 가능하고 글로벌 쿼리에 응답 할 수 있다고 주장하고 또 그런 착각을 일으킬 목적으로 LDBC SNB 14개 IC 쿼리(32 페이지) 중에 4개의 간단한 쿼리들만 골랐습니다. 확장 가능하다는 것, 글로벌 쿼리에 응답 할 수 있다는 것, 모두 사실이 아닙니다.

 

확장 가능한 분산 데이터베이스를 쓰는 사용자는 머신이나 샤드가 몇 개가 필요한지 알 필요도 없고 신경 쓸 필요도 없습니다. 데이터베이스는 투명하게 작동해야 됩니다.

Neo4j는 시스템의 샤드 수, 스키마의 한 파트(part)의 샤드 수, 그리고 나머지 파트(part)의 샤드 수에 대해 자랑하며 들떠 있습니다. 이 단순한 사실이 Neo4j의 Fabric이 분산되거나 확장 가능한 데이터베이스가 아니라는 것을 보여줍니다. 가끔 저는 데이터베이스 전문가로서 Neo4j가 아키텍처의 치명적인 확장성 결함을 기술적 성과인 것처럼 바꿔 버리고, 제품 마케팅에 대해서는 그토록 확고하게 대처하는 것을 보면서 그저 감탄할 따름입니다. 진정한 분산 그래프 데이터베이스가 갖추어야 하는 것이 무엇인지, 그리고 Neo4j의 Fabrics 제품과의 비교를 보려면 이 기사의 개괄적인 요약을 참조하십시오.

 

그에 비해 TigerGraph는 Neo4j가 데모에서 1000대 이상의 머신으로 시연한 모든 것을 100대 미만으로도 처리 할 수 있습니다. 이는 사용자에게 투명하게 샤딩에 대한 어떤 계획도 없이 즉시 처리 할 수 있고, 심지어는 TigerGraph Cloud에서도 가능합니다.  이에 대한 별도의 블로그를 계속 지켜봐 주십시오.

 

Neo4j의 데모에 대한 더 자세한 내용

1. Neo4j는 100TB 데이터를 생성하기 위해서 그들만의 데이터 생성기를 만들었습니다. 더미 데이터 생성은 간단합니다. 요즘 저렴한 스토리지로 100TB의 데이터를 생성하는 것은 매우 간단합니다. Neo4j가 생성한 데이터셋에는 데이터 왜곡(균일하지 않은 데이터)도 없고 현실적인 분산도 없습니다. LDBC-SNB의 공식 데이터 생성기는 Facebook 소셜 네트워크 연구에서 설명한 실제 분포에 가까운 연결된 데이터(그래프를 의미하는)를 생성하도록 설계되었습니다. 그러나 Neo4j 데모에 사용된 데이터는 유리한 결과를 만들기 위해 단순화되었으며 현실세계의 복잡성도 반영하지 않았습니다. 벤치마크 쿼리 중에는 입맛에 맞는 것들만 골랐고, 마케팅 착각을 만들려고 "글로벌 쿼리"라는 용어를 잘못 사용하였습니다. 

2. Neo4j의 라이브 데모는 14개의 LDBC-SNB IC 쿼리 중 특정 쿼리를 골랐습니다. 이 쿼리는 조 단위의 그래프 엘리먼트들 중 고작 몇 천 개의 그래프 엘리먼트(노드와 엔터티, 엣지와 관계)만 터치합니다. 그것은 딥링크 분석 이 전혀 아니며, 의미 있는 방식으로 확장성을 증명하지도 않습니다. 반대로, TigerGraph는 2019년부터 테라바이트 규모의 LDBC-SNB 벤치마크를 구현하기 위해 엄격한 벤치마킹 방법론을 채택하였습니다. 모든 벤치마크는 다음 방법론을 사용하였습니다:

 

  • Raw데이터를 생성하기 위해 LDBC-SNB 스키마와 데이터 생성기를 엄격하게 사용하였습니다. 
  • LDBC-SNB 벤치마크의 모든 쿼리를 구현하였습니다. 유리한 쿼리만 골라서 구현하지 않았습니다.
  • 스케일팩터(scale factor)-1 및 스케일팩터-100은 다른 상용 데이터베이스와 모든 결과를 교차 검증하였습니다(다른 제품들은 스케일팩터-1K의 대규모 데이터셋에서 모든 쿼리를 완료할 수 없기 때문에). 테라바이트 규모로 벤치마크하기 전에 모든 쿼리와 그 결과는 정확하다는 것은 보장됩니다. 

이를 통해 고객에게 제품에 대한 360︒ 뷰를 제공하고 전체 그래프 데이터베이스 업계에서 모범을 보여 권위 있는 LDBC 그래프 데이터베이스 벤치마크를 공정하게 사용하고 있음을 보여주고자 합니다. 우리는 벤치마크를 공정하게 사용할 수 있도록, 그래서 그래프 데이터베이스 채택이 건전하고 객관적인 환경에서 육성 될 수 있게 모든 그래프 데이터베이스 공급업체를 초대합니다.

 

왜 벤치마크이어야 하는가?

IT 전문가들은 기술기반 제품 구매를 계획할 때 여러 경쟁 제품을 평가하고 내 요구 사항에 가장 적합한 제품이 무엇인지에 대한 질문에 답을 할 수 있어야 합니다.

 

벤치마크는 여러 차원에 걸쳐 잘 정의된 객관적 기준을 기반으로 대체 제품을 평가합니다. 이를 서로 다른 기술들에 대한 정량적 비교를 통해 소프트웨어 구매를 보다 객관적으로 선택 할 수 있게 해 줍니다.

 

잘 설계된 그래프 데이터베이스 벤치마크는 다음과 같은 관점에서 다양한 그래프 데이터베이스를 공정하게 360도 정량적 비교를 할 수 있도록 해 줍니다.

  • 성능. 모든 데이터베이스 관리 시스템의 가장 기본적인 KPI는 성능입니다. 벤치마크 쿼리에 얼마나 빨리 응답할 수 있습니까? 처리량(throughput)은 얼마입니까? 
  • 확장성. 또 다른 주요 측정값은 확장성입니다. 기술에 대한 의사결정은 미래 성장을 고려해야 합니다. 사용자는 데이터베이스 크기의 제한이 얼마인지 관심이 있습니까? 1TB, 10TB, 100TB, 1PB 등을 처리할 수 있습니까? 어느 정도 규모까지 데이터베이스가 잘 동작합니까? 아키텍처의 제약사항은 며칠 또는 몇 달 안에 고칠 수 없기 때문에 이것은 중요한 질문입니다. 이것은 수 년이 걸립니다!
  • 저장 압축 비율. 이는 TCO (총 소유 비용)와 연결됩니다. 그래프 데이터베이스 공급업체의 주요 기술 장벽 중 하나는 어떻게 디스크와 메모리에 그래프를 간결하게 표현할 수 있느냐 입니다. 동일한 Raw 데이터가 주어지면 그래프 스토리지가 작을수록 메모리에 더 많은 데이터를 저장할 수 있습니다. 따라서 스토리지 액세스 대기 시간이 줄어들고 하드웨어 비용도 낮아집니다. 
  • 쿼리 표현력. 잘 설계된 그래프 데이터베이스 벤치마크는 그래프 데이터베이스 언어 표현에 한계를 드러낼 수 있습니다. 그래프 데이터베이스는 다른 데이터베이스 쿼리 언어가 할 수 없는 매우 복잡한 쿼리를 수행할 수 있기 때문에 이것은 그래프 데이터베이스의 평가에 있어서 독특한 관점입니다. 경험이 풍부한 데이터베이스 구매 담당자는 전체 벤치마크를 확장하지 못하는 데이터베이스는 구매를 망설일 것 입니다. 
  • 가변성. 가변성을 위해서 데이터베이스는 갱신과 조회가 동시에 실행될 수 있어야 합니다. 가변적인 데이터베이스는 실시간 데이터 조회가 가능하므로 실 세계 시나리오에서 대단히 중요합니다.

 

어떤 벤치마크이어야 하는가?

5년 전 TigerGraph에서 벤치마크 활동을 이끌기 시작했을 때 저는 간단하지만 엄격한 방법을 사용하였습니다. 풍부한 관계를 갖는 실제 데이터셋을 선택하고, 하드웨어를 고정하고, 가장 일반적으로 사용되는 그래프 쿼리를 선택하고(k-홉, 페이지랭크 등), 교차 검증을 수행한 다음에 여러 가지 다른 스케일팩터들로 성능을 테스트합니다. 이 방법은 베어메탈급 성능을 제공하였고, 다른 많은 그래프 데이터베이스 공급업체들이 우리의 접근법을 따라 했습니다. 우리가 아는 한 이 접근법은 업계 최초였습니다. 그러나 당시의 시간과 자원의 한계로 인해 모든 것을 다룰 수는 없었습니다. 그래프 데이터베이스의 약점을 체계적으로 찾아내고 정량화할 수는 없습니다. 그리고 제가 이 간단한 방법을 중단한 주요 이유는 실제 그래프 데이터베이스 사용자의 사용 패턴과 거리가 멀었기 때문입니다

피터가 저에게 LDBC-SNB 벤치마크를 소개한 후, 저는 이를 후속 벤치마크에 포함시켰습니다. 왜 일까요?

  • 현실적인 데이터 특징들. 다른 데이터셋과 달리 이 LDBC-SNB 벤치마크 데이터셋은 실제 소셜 Forum 시나리오를 시뮬레이션 합니다. 스키마는 11개 노드 유형과 15개 엣지 type이 포함되어 있습니다. 페이스북과 같은 실제 소셜 네트워크에서 발견되는 데이터 및 엣지 분포를 시뮬레이션 합니다. 그리고 노드들과 엣지에는 속성이 있으며, 속성 값이 현실적이고 상관 관계가 있는지 확인하기 위해 디비피디아(DBpedia)의 실제 데이터를 사용합니다.
  • 다양한 필수병목지점을 다루는 대표적인 그래프 쿼리. 필수병목지점은 벤치마크의 기반이 되는 대표적인 기술 병목 현상으로, 그것을 해결하면 제품 성능을 크게 향상시킵니다. LDBC-SNB에는 OLTP 및 OLAP 스타일 쿼리 패턴을 다루는 IC(Interactive Complex), IS(Interactive Short) 및 BI(Business Intelligence)의 세 가지 쿼리셋이 있습니다. 이 세 가지 쿼리셋 모두 데이터를 변경하는 쿼리(mutation queries)를 포함합니다.
  • 쿼리 불가지론. 제가 좋아하는 또 다른 측면은 각 쿼리 의미가 순수 영어로 설명되고 그림으로 시각적으로 설명된다는 것입니다. 모든 데이터 관리 공급업체는 SQL, 싸이퍼(Cypher) 또는 GSQL 과 같은 DSL(도메인 별 언어-domain specific language) 을 사용하여 벤치마크 쿼리를 구현하고 동일한 결과를 얻을 수 있습니다. ISO 표준 GQL 이 2023년 또는 그 이후에 나오기 전까지 이것은 훌륭한 일입니다.
  • 데이터 생성기. 데이터 생성기는 중요합니다. 데이터는 결정론적으로(예측한 대로) 생성되어야 하고, 실제에 가까운 특성을 지닌 데이터를 생성해야 하며, 대규모 데이터셋을 생성할 수 있도록 확장성을 가져야 합니다. LDBC-SNB 데이터 생성기는 업계에서 가장 평판이 좋고 잘 알려진 관계형 데이터베이스 벤치마크인 TPC 벤치마크 스타일을 따릅니다. 스케일팩터-1(1GB 데이터), 스케일팩터-10(10GB 데이터), 스케일팩터-1k(1TB 데이터) 등 다양한 스케일팩터를 결정론적으로 생성할 수 있습니다. 또한 데이터 생성기는 결정론적으로 생성된 각 데이터셋에 상응하는 쿼리 파라미터를 생성할 수 있고, 이 벤치마크 쿼리 결과는 반드시 존재해야(non-empty) 합니다.
  • 수십 년간 활동해온 명성 있는 팀. 그 뒤에 있는 TF(taskforce)는 수십 년 동안 그래프 데이터 벤치마크 설계에 대해 연구 활동하는 명성 있는 데이터베이스 연구원입니다. 그들의 출판물 목록을 참조하십시오.

 

Neo4j의 LDBC-SNB을 이용한 100TB 데모

위와 같이, 우리는 LDBC-SNB 스키마를 사용한 Neo4j의 100TB 데모를 살펴볼 준비가 되었습니다. Neo4j는 데모 가이드에서 이 데모가 벤치마크가 아니라는 점을 교묘하게 설명했기 때문에 제가 "벤치마크"라는 단어를 사용하지 않았다는 것에 기억하세요. 

“데이터 자체는 LDBC Social Network Benchmark 그래프의 사양에 따라 생성되었습니다.

이 데모는 벤치마크가 아니지만 벤치마크 데이터는 확장 전략의 영향을 평가하는 데 완벽합니다."

분명히 Neo4j는 명성 때문에 권위 있는 벤치마크인 LDBC-SNB를 선택하였습니다. 그리고 그들은 소위 Fabric 제품의 확장성과 성능을 보여주고 싶었을 것입니다. 불행히도 이것은 LDBC-SNB벤치마크의 올바른 사용이 아닙니다. 왜 일까요?

 

지나치게 단순화된 데이터가 생성되었습니다.

시연 당시 LDBC-SNB의 공식 데이터 생성기는 100TB의 Raw 데이터를 생성할 수 없었습니다. Neo4j 는 데이터를 생성하는 그들만의 방법을 공개했는데, 이는 본래의 벤치마크 철학을 따르지 않았습니다. 그들은 그래프를 하나의 Person 샤드 와 1129개의 Forum 샤드(숫자는 데모 비디오에서 가져왔습니다) 로 분할한 다음 동일한 알고리즘과 파라미터를 사용하여 각 Forum 샤드 내부의 데이터를 독립적으로 생성하였습니다. 그래프 크기는 Forum 샤드 수에 따라 선형으로 확장되기 때문에 데이터 크기를 100TB로 쉽게 확장하였습니다. 

저는 아래와 같이 그들의 데이터 생성 방법을 분해하고 데모 쿼리 결과가 데이터 크기의 증가에 따라 예측 가능하다는 것을 보여 드립니다. 

그림 1에서 볼 수 있듯이 LDBC-SNB 스키마는 하나의 Person 샤드와 1,000개 이상의 Forum 샤드, 이렇게 두 가지 주요 부분으로 분할됩니다. Person 샤드는 연속된 ID를 갖는 3B Person을 포함합니다. 각 Forum 샤드에는 Person 샤드에 대한 모든 Person ID 참조(속성이 없는)가 포함됩니다. 

그림 2는 두 Person을 연결하는 엣지인 KNOWS가 어떻게 생성되는지 보여줍니다. 각 Person K는 1인당 최대 20명을 직접 알고 있습니다. 그리고 이 20명의 ID들은 연속적이고 K와 인접해 있습니다. 결과적으로 K는 최대 40명(친구 및 친구의 친구)을 알고 있습니다. 이 방법론은 예측이 가능한 복잡성을 지닌 데이터를 생성합니다. 친구의 친구 수는 상한이 40입니다. Person 노드의 친구는 인접한 ID 범위에 있으므로 지역성이 좋아 집니다. 그 결과 데모에서 더 나은 캐싱(더 나은 성능)이 나타났습니다. 이에 비해 LDBC-SNB 공식 데이터 생성기에 의해 시뮬레이션된 친구의 수는 페이스북 소셜 네트워크 의 연구에 설명된 멱법칙(power-law, 한 수가 다른 수의 거듭제곱으로 표현되는 두 수의 함수적 관계) 분포를 따릅니다. 스케일팩터-1(1GB 데이터)에서 평균적으로 36명의 친구와 2,845명의 친구의 친구를 생성합니다. BI 데이터 셋의 LDBC-SNB 공식 데이터 생성기를 사용하여 추가 검증을 위한 실험을 수행하고 한 Person당 평균 KNOWS 엣지 수를 집계하였습니다. 스케일팩터-1의 경우 각 Person은 평균 24.45개의 KNOWS 엣지, 스케일팩터-100은 60.91개의 KNOWS 엣지, 그리고 스케일팩터-10K는 137.40개의 KNOWS 엣지를 가집니다. 따라서 평균 KNOWS 엣지는 대략 log10(m)만큼씩 증가합니다. 여기서 m은 스케일팩터입니다. 아래 표를 참조하십시오.

그림 3은 하나의 Forum 샤드에 대한 데이터 생성을 보여줍니다. 각 Forum 샤드는 정확히 10,000개의 Forum이 있습니다. 각 Forum에는 100~800개의 게시물이 있는데, 이는 Forum당 평균 450개 입니다. 게시물 작성자는 Person 샤드에서 랜덤으로 선택됩니다. 각 게시물에는 0~80개의 댓글이 있으며 이는 게시물당 평균 40개에 해당됩니다. 40개의 댓글 작성자는 Person 샤드에서 랜덤으로 뽑힌 40명의 연속적인 인물입니다. 각 게시물의 타임스탬프는 현재 시간에서 랜덤으로 0~100일을 뺀 값이고, 각 댓글의 타임스탬프는 현재 시간에서 랜덤으로 0~10일을 뺀 값입니다. 모든 난수는 균일 분포로 생성됩니다. Neo4j의 데이터 생성기는 동일한 알고리즘을 반복하여 1,000개 이상의 Forum 샤드를 생성합니다. 따라서 Forum 샤드는 거의 동일하고 독립적이므로 현실적이지 않습니다. 

이 인위적인 그래프에는 데이터 왜곡이 없고 엔터티 간의 현실적인 상관 관계도 포함되어 있지 않습니다. 

반면 LDBC-SNB의 공식 데이터 생성기는 하나의 청크(chunk)로 데이터를 생성하고 샤드를 전혀 고려하지 않아 보다 현실적입니다.

 

용어에 오해의 소지가 있습니다. 

Neo4j의 데모는 글로벌 쿼리(global query)라는 용어를 잘못 쓰고 있습니다.

Neo4j CEO는 "데모 쿼리는 데이터베이스에 부하를 주도록 설계된 심층적이고 복잡한 그래프 글로벌 쿼리"라고 주장했는데 이는 사실이 아닙니다.

데이터베이스 벤치마크에서 "글로벌 쿼리"는 그래프의 많은 부분을 터치하는 쿼리의 종류를 말합니다(LDBC-SNB BI 쿼리 설명은 여기를 참조하세요). 이 일반적으로 통용되는 의미를 바탕으로 데모 쿼리에서 터치된 그래프 엘리먼트의 수를 계산해 보겠습니다.

데모 쿼리 IC9는 다음과 같이 설명됩니다. 

“주어진 Person을 시작으로 그 Person의 친구 또는 친구의 친구(시작한 Person은 제외)가 만든 (가장 최근의) 메시지를 찾습니다. 주어진 maxDate(해당일 제외) 이전에 생성된 메시지만 고려합니다.” 

Neo4j가 IC9 데모를 실행한 방법을 살펴보겠습니다.

1. 데모에서는 IC9 쿼리에 대해 다음과 같은 고정 파라미터(여기에서 발췌)를 사용하였습니다.

description: "LDBC Read Interactive / complex / 9",
params: {
       Date0: new neo4j.types.Date(2022, 1, 14),
       Person: neo4j.int(1346680336),
}

2. update쿼리가 통합되지 않고 동일한 쿼리가 반복적으로 실행됩니다. 원래 IC 쿼리 워크로드는 update(insert) 쿼리가 포함된 트랜잭션용으로 설계되었습니다. 데모에서 update를 통합하지 않고 입력 파라미터를 고정하면 Neo4j가 캐시된 결과를 사용할 수 있으므로 반복 실행으로 평균 실행시간을 낮출 수 있습니다. 또한, 주어진 Person의 친구와 친구의 친구가 연속되도록 하는 연속된 엣지 생성 방식을 사용하여 캐시를 많이 활용합니다. 데모를 주의 깊게 관찰하면 처음 몇 번 실행한 후 쿼리 속도가 빨라지는 것을 알 수 있습니다. 

3. 고정된 Person이 있는 경우 쿼리는 최대 40명의 친구와 친구의 친구를 찾습니다(쿼리의 2-7행). 그런 다음 fabric 드라이버는 40명과 마감일(maxDate) "2022/1/14"를 모든 Forum 샤드로 보냅니다(쿼리의 10-15행). Neo4j가 타임스탬프를 생성하는 방식은 모든 게시물과 댓글이 대상이 되므로 마감일(maxDate)은 쓸모가 없습니다. 이제 이 쿼리가 하나의 Forum 샤드에서 터치할 수 있는 메시지 수를 계산해 보겠습니다. 

  • a. 주어진 Person이 게시물의 댓글 작성자가 될 확률은 얼마일까요? 그 Person은 40/3B의 가능성을 가질 것 입니다. 이는 댓글 작성자가 생성되는 방식을 기반으로 합니다. 그림 3에서 댓글 작성자는 연속적인 40명을 랜덤으로 선택하여 생성됩니다. 왜냐하면 Person K는 K-40, K-39, …K에서 각각 시작하는 40개의(크기가 40인) 연속적인 Person 세그먼트에 포함되기 때문입니다.

랜덤으로 선택된 세그먼트는 Person K를 게시물의 댓글 그룹 작성자로 만듭니다.

  • b. Forum 샤드에는 평균 4,500,000개의 게시물이 있으므로 한 Person이 평균적으로 Forum 샤드에서 4,500,000*(40/3B) = 0.06 개 댓글의 작성자가 될 수 있습니다. 40명의 연속된 Person(친구 및 친구의 친구)이 주어지면 Forum 샤드에서 최소 40*0.06= 2.4개 댓글의 작성자가 될 수 있습니다.
  • c. 데모에는 1,129개의 Forum 샤드가 있으므로 고정된 Person을 입력한 IC 9 쿼리는 평균 2.4*1,129=2,709.6개의 메시지를 터치합니다. 터치된 그래프 엘리먼트는 O(2.4* 샤드수)가 되며, 이는 전체 그래프 엘리먼트들(꼭지점 및 엣지)보다 훨씬 적습니다. Neo4j는 단순히 쿼리가 모든 Forum 샤드에 터치했기 때문에 데모 쿼리가 전역 쿼리라고 주장하였습니다. 그러나 그들의 쿼리는 샤드당 10개 미만의 그래프 엘리먼트(elements)를 터치합니다. 따라서 "데이터베이스에 부하를 주도록 설계된 쿼리"라고 할 수 없습니다.

사실 위의 쿼리는 LDBC-SNB 벤치마크의 IC(Interactive Complex) 워크로드에서 가져온 것입니다. 이런 분류의 쿼리는 주어진 노드의 이웃에만 액세스합니다. 따라서 이러한 쿼리는 로컬이며 대략적으로 런타임 O(log n)로 나타냅니다. 여기서 n은 그래프 엘리먼트의 수입니다. 예를 들어 TuGraph 의 감사 결과 에서 데이터 생성기 스케일팩터가 30에서 300으로 증가할 때 처리량은 0%~10%(5,436 ops/sec 에서 4,855 ops/sec 로)만 감소합니다. 데이터 크기가 10배 증가하면 처리량이 10배 감소할 것으로 예상할 수 있지만, 실제로는 그렇지 않습니다.

또한, LDBC-SNB 벤치마크 데이터 생성기를 사용하면 IC9에서 선택한 Person 및 메시지의 수가 소셜 네트워크 내부의 상관 관계로 인해 특정 Forum에서 클러스터링 될 수있습니다. Neo4j 데이터 생성기는 터치된 메시지를 Forum 샤드에 균일하게 배포했으며 그 결과 런타임 쿼리 패턴은 비현실적입니다. 

데모 쿼리는 LDBC-SNB IC 워크로드에서 유리한 것만 골랐습니다.

데모에서는 2개의 쿼리(IC9 및 최근 게시물) 만 사용하였습니다. 원래 IC 제품군에는 14개의 쿼리가 있습니다(여기 33페이지 참조). 이 데모로 Neo4j의 전체적인 성능을 알 수가 없습니다. 벤치마크 쿼리는 다양한 필수병목지점들을 포괄하는 제품군으로 설계되었습니다. 유리한 것만 골라낸 쿼리는 벤치마크 디자인의 목적에 어긋나고 착각을 불러 일으킵니다.

예를 들어 아래의 BI 11 쿼리는 LDBC-SNB 최신 버전에서 가져온 것인데, 주어진 국가의 모든 고유한 Person-삼각관계를 계산합니다. 이 쿼리가 Neo4j fabric 데이터베이스에서 구현되는 경우 쿼리는 Person 샤드의 CPU와 메모리만 사용하고 1,000개 이상의 Forum 샤드에 있는 리소스는 유휴 상태가 됩니다. 

 

사실, 이 쿼리는 비용이 많이 들고 결과의 크기는 복잡도 O(n^1.5) 입니다. 여기서 n은 이 경우의 Person 수입니다. Person 노드를 다른 샤드에 배포하고 클러스터에서 사용 가능한 모든 컴퓨팅 성능으로 조인(join) 알고리즘을 실행하면 모든 Person을 단일 시스템(샤드)에 배치하는 것보다 성능이 훨씬 더 빠릅니다(더 많은 컴퓨팅 리소스로 인해). 벤치마크에서 유리한 것만 골라낸 쿼리는 청중이 Neo4j의 데모 설정에서 이 문제를 보지 못하게 막습니다. 데이터베이스 이론의 최근 발전은 "Worst-case Optimal Join Algorithms" 에 의해 최악의 데이터 복잡성 측면에서 이 문제를 최적으로 해결할 수 있습니다.

 

결론

Neo4j의 최근 100TB 데모는 LDBC-SNB 벤치마크의 올바른 사용이 아닙니다. 데이터는 매우 인공적이고 현실적이지 않으며 쿼리는 벤치마크에서 유리한 것만 골랐으며 데모에서는 "글로벌 쿼리"라는 용어를 잘못 사용하여 마케팅 착각을 불러 일으킵니다.

대조적으로, TigerGraph는 2019년부터 테라바이트 규모에서 LDBC-SNB 벤치마크를 구현하기 위해 엄격한 벤치마킹 방법론을 채택하였습니다. 우리의 모든 벤치마크에는 다음 원칙이 적용되었습니다.

  • Raw 데이터를 생성하기 위해 LDBC-SNB 스키마와 데이터 생성기를 엄격하게 사용하였습니다.
  • LDBC-SNB 벤치마크에서 모든 쿼리를 구현하였습니다. 유리한 쿼리만 고르지 않았습니다.
  • 스케일팩터-1 및 스케일팩터-100에서 다른 상용 데이터베이스 시스템과 모든 결과를 교차 검증하였습니다. 모든 쿼리와 그 결과는 테라바이트 규모로 벤치마킹 하기 전에 정확한지 확인합니다.

그렇게 함으로써 우리는 고객에게 우리 제품에 대한 360도 뷰를 제공하고 전체 그래프 데이터베이스 산업에서 모범을 보여 권위 있는 그래프 데이터베이스 벤치마크의 공정한 사용을 보여주고 싶습니다. 모든 그래프 데이터베이스 벤더는 벤치마크를 공정하게 사용하여 그래프 데이터베이스가 건전하고 객관적인 환경에서 채택될 수 있도록 합니다.

활발한 토론은 정직한 의사소통의 기초입니다. 모든 데이터베이스 실무자가 TigerGraph 팀과 함께 객관적인 벤치마크의 장점에 대한 대화를 나눌 수 있도록 초대합니다. 또한 Neo4j, 아마존 Neptune, 데이터스택스 및 TigerGraph를 포함한 주요 그래프 데이터베이스에 대한 평가를 위해 그래프 데이터베이스에 대한 구매자 안내서를 읽어 보시기 바랍니다.

 

 

 

source : https://www.tigergraph.com/blog/truth-behind-neo4js-trillion-relationship-graph/

티스토리툴바