Neo4j 그래프 DB 속도 향상

Neo4j 그래프 구축을 하는데 프로젝트를 진행했었다

AWS에 구축된 Neo4j DB에 한번 업로드시 60만개 이상의 노드와 관계를 올려야 한다. 당연히 시간이 엄청 오래 걸린다...

relationship types만해도 64만 개 이상...

한번 업로드할때 4시간이가 5시간.. 걸렸던걸로 기억한다 (올리고 자고 다음날 확인하고..)

이 업로드는 결국은 다했지만, 나중에 5월에 다녀온 AWS studnet Community day에서 Neo4j 관련 강연이 있었다

내가 했던 일이라 당연히 관심이 생겨서 듣게 되었다...

 

강연자분은 그래프 전문가였다.. 다른거 안하고 오직 그래프만 연구하신던 분이었다..
강연자분은 AWS S3에서 대용량 데이터를 가져와 Neo4j 그래프 DB를 구축할 때 처리한 경험을 소개해주었다

강연의 주요 부분 중 하나를 정리해보았다.

S3에 저장을 할때 csv (row-based)와 parquet (col-based) 저장형태가 있었다.

이때 csv는 각 행이 하나의 레코드이며, 텍스트 기반, 용량 크고 파싱이 느리다는 특징이 있다.

parquet의 경우에는 열 기반 저장 포맷, 용량이 작고, 특정 컬럼만 읽는 데 유리하여 성능이 우수하다는 특징이 있다.

 

강연자분이 실험한 결과에서도 csv는 약 10만개 이상의 레코드부터 용량 증가가 매우 가파르게 나타났다는 것을 알게 되었다.

결과적으로 Parquet이 대용량에서 성능/저장 효율이 훨씬 뛰어나다는 것을 확인 하였고, 이어서 Neo4j에 업로드에 대한 소개도 해주었다.

 

Neo4j는 두 가지 주요 접근 방식이 있었다.

 

 하나는 UI (json) 방식: Neo4j Browser, Bloom 등에서 시각적으로 노드 간 관계를 보며 쿼리

 다른 하나는 Binary (cypher-shell) 방식: 배치 처리나 스크립트를 통해 CLI에서 Cypher 실행

cypher-shell을 사용하여 배치처리나, 대규모 업로드하는 것이, UI 툴에서 Cypher 쿼리를 직접 입력하고 실행하는 것보다 훨씬 좋다는 것을 보여주었다.

UI툴에서 직접 쿼리하는 것은 소규모 작업 같은 곳에서 사용해야 하고 S3나 배치 작업 같이 외부에서 업로드하는 것은 cyper-shell을 활용해야 작업 속도나, 효율성이 더 좋다는 것을 확인할 수 있었다. 

 

이 이유에 대해 조금 더 적어볼려고 한다. 즉, 직접적인 네트워크 통신 (Low-level Protocol)을 하고 있기 때문이다.

• cypher-shell은 Bolt protocol이라는 Neo4j의 이진(binary) 통신 프로토콜을 사용해 서버와 빠르게 통신을 진행하지만,
• UI(Neo4j Browser)는 주로 HTTP API나 웹소켓 기반으로 처리되므로 속도와 오버헤드 측면에서 불리하게 나타나기 때문이다.

또한 cyper-shell은 렌더링이 없기 때문이다.

• UI는 결과를 시각적으로 렌더링해야 하므로, 노드 수가 많아지면 렌더링 비용이 커지게 되지만,
• cypher-shell은 결과를 텍스트로만 반환하기에 훨씬 가볍고 빠르기 때문이다.