아마존 Neptune, 밝혀진 진실

카테고리 없음

아마존 Neptune, 밝혀진 진실

Jacob_ 2021. 12. 1. 19:13

아마존 Neptune, 밝혀진 진실

올해 5월 아마존은 아마존 Neptune이라는 클라우드 그래프 데이터베이스 서비스 GA(General Availability)를 발표했습니다. 다음은 아마존 Neptune의 강점과 약점을 요약한 블로그 입니다. 작년에 우리는 Neo4j, Titan 및 타이거그래프에 대한 벤치마크 보고서를 발표했습니다. 아마존 Neptune이 다른 3개의 그래프 데이터베이스와 비교하여 어떻게 다르게 작동하는지 알아내는 것은 매우 재미 있는 일이라 생각됩니다. 이 질문에 답하기 위해 우리는 아마존 Neptune으로 동일한 벤치마크를 수행했습니다. 우리의 벤치마크로 확인된 내용을 이 블로그를 통해 전달합니다.

요약

아마존 Neptune은 RDF와 속성 그래프 모델(Property Graph models)을 모두 제공합니다. 이 벤치마크에서는 그렘린(Gremlin)을 쿼리 인터페이스로 사용하는 속성 그래프 모델에 중점을 두었습니다.

데이터 로딩 속도: 타이거그래프는 Neptune r4.4xlarge 인스턴스보다 21~31.2배, Neptune r4.8large 인스턴스보다는 30~57.6배 빠르게 데이터를 로딩합니다.
스토리지: 아마존 Neptune은 동일한 그래프 데이터에 대해 8.0~9.6배 더 많은 디스크 스토리지가 필요합니다.
1홉(hop) 및 2홉 그래프 쿼리: 타이거그래프는 트위터 데이터셋의 경우 1홉 그래프 쿼리에서는 최소 10배 더 빠르고, 2홉 그래프 쿼리에서는 최소 57배 더 빠릅니다.
3홉 및 6홉 쿼리: 3홉 쿼리의 경우 아마존 Neptune은 20회 중 17회 시도에서 메모리 부족(OOM) 오류를 반환했으며 6홉 쿼리는 완료할 수 없었습니다.
분석 쿼리(PageRank, Connected Components 등): Neptune에서는 지원되지 않지만, 타이거그래프에서는 지원됩니다.

*타이거그래프의 로딩 시간에는 스키마 생성에 필요한 몇 분의 시간이 포함되지 않습니다. 이 시간은 일정하며 데이터 크기에 따라 달라지지 않습니다. 모든 독자가 벤치마크 결과를 재현할 수 있도록 벤치마크에 사용된 데이터셋, 쿼리, 입력 파라미터, 결과 파일과 스크립트를 GitHub를 통해 제공하였습니다[1].

설정 데이터 세트

벤치마크에서는 공개적으로 사용 가능한 두 가지 데이터셋을 사용하였습니다. 첫 번째는 graph500.org 에서 가져왔으며, 이 데이터는 Kronecker 제품을 이용하여 인위적으로 생성한 데이터입니다. 두 번째는 잘 알려진 트위터의 팔로어 데이터셋입니다. 각 그래프에 대해 원시 데이터는 탭으로 구분된 단일 엣지 목록 형식으로 되어 있습니다. 아래와 같은 형식입니다.

U1 U3

U1 U4

U2 U3

Table 1. 데이터셋

데이터명	데이터 설명	노드 개수	엣지 개수	Raw 데이터 크기(MB)
graph500	Synthetic Kronecker graph	2.4M	64M	967
twitter	트위터의 팔로워 방향 그래프	41.6M	1.47M	24,375

이 곳에서 데이터를 확인할 수 있습니다 🡪 graph500, twitter

하드웨어 & 소프트웨어

Table 2. 클라우드 하드웨어

A. r4.8xlarge 의 경우 250G EBS(Elastic Block Service)-optimized Provisioned IOPS SSD (IO1)를 연결했습니다. 데이터 로딩 및 쿼리를 수행하는 중에 동일한 IOPS(input/output operations per second) 를 보장하기 위해 공급업체 소프트웨어를 설치하고, Raw 데이터와 그래프 DB 데이터를 저장하는데 사용한 스토리지입니다. 이 250G SSD 드라이브에 대해 50/GiB의 IOPS를 설정, 총 12,500 IOPS 를 설정하였습니다.

B. Neptune DB 인스턴스에는 5개의 클래스가 있습니다. 각 클래스에는 CPU, 메모리, SSD 등과 같이 사전에 정의된 설정이 있습니다. 벤치마크에는 가장 큰 두 개의 DB 인스턴스 클래스를 기반으로 하였습니다.

C. 아마존 Neptune의 IOPS는 아마존 Cloudwatch 콘솔에서 확인할 수 있습니다.

Table 3. 아마존 Neptune 클라이언트 시스템

Anazon EC2 Type	vCPUs	Memory(GiB)	OS	네트워크 성능
r4.xlarge	4	30.5	Amazon Linux AMI	Up to 10Gbps

테스트

먼저 다음 측정 기준에 따라 데이터 로딩 성능을 비교했습니다.

벤치마크를 위한 데이터셋 로딩 시간(데이터셋 로딩 시간에는 특정 CSV 형식이 필요하므로 아마존 Neptune에 대한 노드(vertex) 파일을 준비하는 시간이 포함됩니다)
로딩된 데이터의 스토리지 크기

Table 4. 적재 방법

제품명	데이터 로딩 API
타이거그래프	GSQL declarative loading job
Amazon Neptune	Neptune DB 인스턴스에 S3에 저장된 외부파일을 직접 로딩하는 Neptune 로더

그리고 다음 쿼리들에 대해 응답 시간을 측정했습니다.

300개의 고정 랜덤 시드(fixed random seeds)에 대한 모든 1홉 경로의 엔드포인트(endpoint) 노드를 계산하고 제한 시간은 쿼리당 3분으로 설정합니다.
300개의 고정 랜덤 시드에 대한 모든 2홉 경로의 엔드포인트 노드를 계산하고 제한 시간은 쿼리당 3분으로 설정합니다.
10개의 고정 랜덤 시드에 대한 모든 3-홉 경로의 엔드포인트 노드를 계산하고 제한 시간은 쿼리당 3분으로 설정합니다.
10개의 고정 랜덤 시드에 대한 모든 6홉 경로의 엔드포인트 노드를 계산하고 제한 시간은 쿼리당 3분으로 설정합니다.
PageRank 및 Weakly Connected Component 검색 쿼리를 테스트하려고 했지만, 아마존 Neptune은 알고리즘 쿼리를 위한 언어 지원이 부족한 것 같습니다.

"고정 랜덤 시드"란 그래프에서 N개의 노드를 한 번 무작위로 선택하고 테스트를 위해 이 목록을 반복 가능한 입력 조건으로 저장했음을 의미합니다. 각 쿼리의 경로는 하나의 노드에서 시작하여 k까지 경로의 끝에 있는 모든 노드를 찾습니다. N개의 쿼리를 순차적으로 수행하였으며, 노드 집합을 반환하는 대신 발견된 경로의 엔드포인트 노드의 수만 계산하므로 I/O 시간은 수행 시간 에 포함되지 않습니다. 그러나 우리는 아마존 Neptune과 타이거그래프가 동일한 경로 엔드포인트 노드 집합을 검색하고 있는지 확인하기 위해 교차 검증 테스트도 실행했습니다.

결과

아래 그림은 로딩 시간, DB 스토리지 크기, k-hop-path-neighbor-count 쿼리 시간에 대한 벤치마킹 결과입니다.

Figure 1. 로딩 시간

아마존 Neptune 로딩 시간에는 노드 파일 로딩 시간, 엣지 파일 로딩 시간 및 노드 파일 준비 시간이 포함되었습니다. 타이거그래프는 노드 파일을 생성할 필요 없이 엣지 파일을 바로 로딩할 수 있습니다. 또 한 타이거그래프는 분리된 노드 파일 없이 엣지 파일을 직접 불러올 수도 있습니다. 노드뿐 아니라 엣지(edge)도 타이거그래프의 엣지 파일에서 생성되며, 이 둘을 생성하는 시간은 타이거그래프의 데이터 로딩 시간에 포함됩니다.

Figure 2. 디스크 스토리지 크기

아마존 Neptune의 경우 확인된 총 스토리지 크기는 복제 계수(replication factor)를 고려하여 6으로 나눴습니다. 이를 통해 아마존 Neptune의 단일 인스턴스와 타이거그래프의 단일 인스턴스의 그래프 스토리지를 완벽하게 비교할 수 있었습니다.

Figure 3. 300개의 고정 랜덤 시드에 대한 1-hop-neighbor-count 쿼리의 평균 수행 시간

Figure 4. 300개의 고정 랜덤 시드에 대한 2-hop-neighbor-count 쿼리의 평균 수행 시간

graph500 데이터에 대해서 Neptune-1의 경우 300개 쿼리 중 하나가 시간이 초과되었으며, 트위터 데이터의 경우에는 Neptune-1에서 63개의 쿼리에서 시간 초과가 발생, Neptune-2에서는 60개의 쿼리에서 시간 초과가 발생하였습니다.

Figure 5. 10개의 고정된 랜덤 시드에 대한 3-hop-neighbor-count 쿼리의 평균 수행 시간

graph500 데이터에 대해서 Neptune-1과 Neptune-2에서 모두 메모리 부족(OOM) 오류로 인해 10개의 쿼리 중 8개가 실패하였으며, 트위터 데이터에 대해서는 Neptune-1과 Neptune-2에서 모두 OOM으로 인해 10개의 쿼리 중 9개가 실패하였습니다.

Figure 6. graph500의 로딩 시간

항목	타이거그래프	Neptune-1	Neptune-2
엣지	55.97s	1571s	1052s
노드		45s	30s
노드 파일 준비		93.19s	93.19s
합계	55.97s	1709.19s	1175.19s

Figure 7. 트위터 로딩 시간

항목	타이거그래프	Neptune-1	Neptune-2
엣지	785.24s	42248s	21700s
노드		733s	503s
노드 파일 준비		2258.669s	2258.669s
합계	785.24s	45239.669s	24461.669s

Neptune에서는 엣지를 로딩하기 전에 별도의 노드 파일을 로딩해야 합니다. 그래서 엣지 파일에서 노드 데이터를 추출하고 노드 파일을 로딩하는데 수행된 시간을 포함하였습니다.

Figure 8. graph500에 대한 K-hop-path-neighbor count 쿼리의 평균 수행 시간

graph500	타이거그래프	Neptune-1	Neptune-2
1홉	0.0063s	0.01578s	0.01346s
2홉	0.0713s	7.76588s (시간초과 1회)	8.25123s
3홉	0.4125s	2.1185s (OOM오류 8회)	2.2670s (OOM오류 8회)
6홉	1.782s	(전체 OOM오류)	(전체 OOM오류)

Figure 9. 트위터에 대한 K-hop-path-neighbor 카운트 쿼리의 평균 수행 시간.

graph500	타이거그래프	Neptune-1	Neptune-2
1홉	0.0241s	0.33582s	0.28924s
2홉	0.4595s	26.1679s (시간초과 63회)	27.4006s (시간초과 60회)
3홉	6.73s	38.223s (OOM오류 9회)	27.4006s (OOM오류 9회)
6홉	63.0556s	(전체 OOM오류)	(전체 OOM오류)

우리는 K-hop-path-neighbor 쿼리의 평균 시간을 계산할 때 시간이 초과되거나 OOM 오류가 발생한 경우에는 제외하였습니다.

논의

이 섹션에서는 우리가 수행한 테스트와 관련하여 아마존 Netptune과 타이거그래프의 몇 가지 차이점에 대해 논의하고자 합니다.

아마존 Netptune

Neptune은 아마존 S3 스토리지에서만 데이터를 수집할 수 있는 벌크 로더(bulk loader)를 제공하므로 사용자는 먼저 데이터를 S3에 넣어야 합니다. Neptune의 최대 저장 용량은 64TB[2]입니다. 속성 그래프의 경우 데이터 파일은 CSV 형식이어야 합니다. 또한 그래프의 속성 유형은 단순 스칼라 유형(simple scalar types)[3]이어야 하는 반면 타이거그래프 속성 유형은 스칼라와 map, list 및 set과 같은 복합 유형도 지원합니다. Neptune은 노드와 엣지를 각각 로딩해야 합니다. 엣지 파일에서 노드ID를 추출한 다음 적절한 형식의 파일에 쓰는 방식으로 로딩을 준비해야 했습니다. 벤치마크한 두 인스턴스의 최대 IOPS를 기록한 결과, 우리는 그들의 IOPS 성능이 타이거그래프 EC2 머신의 SSD보다 훨씬 좋다는 것을 아마존 Cloudwatch 콘솔을 통해서 확인할 수 있었습니다. 더 좋은 하드웨어임에도 불구하고 Neptune의 데이터 로딩 시간은 타이거그래프보다 21배 ~ 57.6배 느렸습니다.

1홉 쿼리의 경우 Neptune의 두 인스턴스는 모두 3분 제한 시간 설정 내에서 300개의 랜덤 입력을 완료할 수 있습니다. 그러나 2홉 쿼리의 경우 graph500 데이터에서 Neptune-1은 하나의 쿼리에서 수행 시간 초과가 발행 하였습니다. 그리고 더 큰 트위터 데이터셋을 이용할 때는 Neptune-1에서 63개의 쿼리 수행 시간 초과가 발생하였고, Neptune-2에서는 60개의 쿼리 수행 시간 초과가 발생하였습니다. 설상가상으로 3홉 쿼리의 경우 graph500 데이터에서 Neptune-1과 Neptune-2에서 모두 10개 중 8개의 쿼리를 수행할 때 메모리가 부족하여 테스트를 온전하게 완료할 수 없었습니다. 트위터 데이터셋에서 Neptune-1과 Neptune-2 모두 9개의 쿼리를 수행할 때 메모리가 부족했으며, 마지막으로 아마존 Neptune은 6홉 쿼리의 테스트에서는 응답하지 못했습니다. Neptune 인스턴스는 고정된 환경 구성으로 제공되며 사용 가능한 가장 큰 인스턴스를 이용하여 테스트하였습니다.

아마존 Neptune은 그렘린 OLAP API[4]에서 VertexProgram을 지원하지 않습니다. 따라서 Weakly Connected Component 또는 PageRank와 같은 분석 쿼리를 실행할 수 없습니다.

Neptune은 최대 15개의 읽기 전용 복제본을 생성하는 것으로 서버 노드 복제(server node replication)를 지원합니다[2]. 그러나 데이터가 클러스터 내부에서 분할되는 분산 데이터베이스는 지원하지 않습니다. 이 테스트에서는 읽기 전용 복제본 없이 기본 노드만 사용하였습니다.

Neptune 인스턴스에는 하나의 내장 그래프가 제공되며, 사용자들은 멀티 그래프를 생성할 수 없습니다.

타이거그래프

타이거그래프에는 ETL이 내장된 고급 로딩 언어(high-level loading language)를 지원하므로 다양한 입력 유형을 허용하고 데이터 변환을 수행할 수 있습니다. 타이거그래프의 한 가지 특징은 노드에 속성이 없는 경우, 사용자는 어떤 노드 파일도 없이 엣지 파일을 로딩할 수 있다는 것입니다. 이 상황은 테스트에 사용된 두 가지 데이터 세트에 해당됩니다.

타이거그래프는 아마존보다 20배 이상 빠르게 데이터를 로딩할 뿐만 아니라 더 작은 공간을 사용합니다. 이것은 타이거그래프가 동일한 양의 메모리에 더 큰 데이터베이스를 저장할 수 있음을 의미합니다. 또한 CPU 캐시가 그래프의 더 많은 데이터를 보유할 수 있기 때문에 더 빠르게 데이터를 액세스할 수 있습니다.

메모리와 시간 초과 문제 없이 모든 k홉 쿼리가 완료되었습니다. 또한 타이거그래프의 GSQL 언어는 Weakly Connected component, PageRank와 같은 OLAP 유형의 쿼리를 구현할 수 있습니다. 표준 GSQL로 작성되었기 때문에 사용자는 이러한 쿼리를 자유롭게 작성할 수 있습니다.

타이거그래프에 대해 자세히 알아보려면 다음과 같은 유용한 리소스를 참조하세요.

타이거그래프 개발자 에디션 다운로드: https://www.타이거그래프.com/developer/
GSQL 백서 다운로드: https://info.타이거그래프.com/gsql
Neptune 벤치마크: 다운로드: https://info.타이거그래프.com/타이거그래프_vs_neptune

참조

[1] Script for reproduce Neptune benchmark and 타이거그래프 benchmark https://github.com/타이거그래프/ecosys/tree/benchmark/benchmark/neptune
https://github.com/타이거그래프/ecosys/tree/benchmark/benchmark/타이거그래프
[2] Neptune read replica and storage limits https://aws.amazon.com/neptune/faqs/
[3] Neptune CSV load data types https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html
[4] Neptune does not support VertexProgram https://docs.aws.amazon.com/neptune/latest/userguide/access-graph-gremlin-differences.html

src : https://www.tigergraph.com/blog/amazon-neptune/