Home

그래프 응용에서 순수 그래프 데이터베이스는 성능이 우수하며, 관계형 데이터베이스에서 그래프 데이터 처리는 트랜잭션, 신뢰성 있는 접근제어에 장점이 있다.

순수 그래프 데이터베이스의 대표 제품은 Neo4j로 그래프 데이터베이스 시장의 46%를 점유하고 있다. 관계 데이터베이스에 그래프 데이터를 처리하기 위하여 그래프 질의 구문을 추가한 제품은 SQL Server 2017 버전의 SQL Graph이다[7]. SQL Graph는 관계 데이터베이스와 같은 테이블 구조를 갖고 노드와 에지를 SQL CREATE 문으로 선언을 하고 SQL의 WHERE 절에서 MATCH 문을 통하여 그래프 질의를 한다.

그래프 응용에 대한 Cypher 언어의 그래프 데이터베이스와 SQL의 관계 데이터베이스의 처리 성능 비교는 많은 연구를 통하여 이루어졌다.

Chad Vicknair[1]은 Neo4j와 MySQL 데이터베이스에서 노드와 에지로 구성된 단순 DAG(Directed Acyclic Graph)를 노드수를 4가지(1000, 5000, 10000, 100000)로 변화시키면서 경로질의의 수행 속도와 질의의 용이성, 확장성 등을 비교하였다. 수행 속도는 노드 수가 작은 경우를 제외하고는 대부분 Neo4j가 수행 속도 면에서 MySQL보다 우수하였다.

Adam Welc[11]는 Neo4j와 오라클 데이터베이스에서 노드와 에지로 구성된 단순 DAG(Directed Acyclic Graph)에 저장된 소셜 그래프의 최단거리 문제의 예를 들어 그래프 질의에서 Neo4j가 SQL에 비하여 우수하지 않을 수도 있다는 것을 보였다.

Andrey Gubichev[9]는 Neo4j와 Virtuoso 관계 데이터베이스에서 LUBM 데이터를 이용하여 SPARQL 그래프 패턴매칭 질의에 대한 성능을 측정하였다.

Jürgen Hölsch[10]는 Neo4j와 상용 관계 데이터베이스에서 LUBM 벤치마크를 이용하여 그래프 분석질의와 패턴질의에 대하여 Cypher와 SQL 질의의 수행 속도와 질의의 용이성, 확장성 등을 비교하였다. 질의 수행 속도는 분석질의는 SQL이 Cypher 보다 우수하고, 패턴질의의 경우는 패턴 경로의 길이가 작으면 SQL이, 길이가 커지면 Neo4j의 Cypher 질의가 우수함을 보였다. 그 외, 그래프 데이터베이스에 대한 많은 연구가 다양한 DBMS와 질의 타입에 대하여 비교 연구되어 왔다[12][13].

기존의 연구는 대표적인 그래프 데이터베이스인 Neo4j와 MySQL, 오라클 등 관계 데이터베이스와의 성능 비교가 주로 이루어졌으며 그래프 질의의 유형에 따라 성능 평가 결과가 조금씩 다르게 나타난다. 본 연구는 Jürgen Hölsch의 세분화된 그래프 패턴 질의에 대하여 기존의 관계 데이터베이스 SQL 언어를 확장한 SQL Server DBMS의 SQL Graph를 중심으로 그래프 패턴 질의 작성의 용이성과 성능 평가를 시도하였다.

기존의 연구는 그래프 질의를 그래프 데이터베이스와 관계 데이터베이스에서 처리를 하고 성능 및 질적인 비교를 수행하였다. 본 연구는 관계 데이터베이스의 SQL 질의어를 확장하여 관계 데이터베이스 엔진에서 그래프 데이터베이스의 Cypher 언어를 처리하는 SQL Graph와 비교를 한다. 추가적으로 관계 데이터베이스의 대표인 오라클 데이터베이스의 SQL 언어에 대한 비교를 포함한다. 연구의 개요도는 그림 1과 같다.

Fig. 1. 
Database query comparison platform

그래프 데이터베이스 성능 측정을 위한 표준화된 벤치마크 데이터는 따로 없지만 시맨틱 웹에서 사용하는 RDF 그래프 모델의 LUBM 벤치마크 데이터를 사용한다. LUBM은 Lehigh 대학에서 개발한 것으로 도메인이 대학 운영인 데이터이다[14]. LUBM 벤치마크 데이터는 OWL 포맷으로 생성된다. OWL 형식 데이터는 그래프 데이터에 적재하기 위하여 변환기를 이용하여 GraphML로 바꾼다.

3가지 데이터베이스의 스키마 설계와 DML 생성 과정은 그림 2와 같다.

Fig. 2. 
Benchmark data conversion

(1) Neo4j 데이터 생성

LUBM 벤치마크 데이터는 GraphML 데이터 형식으로 바꾸어 Neo4j의 Import 도구를 이용하여 적재한다. 적재 과정에서 그래프 데이터의 노드, 에지 타입, 데이터가 표 1과 같이 생성된다. 적재된 노드 타입은 12개, 노드 수는 38,334개 에지 타입은 12개, 에지 수는 113,464개이다.

Table 1. 
Graph data contents

Node Type	n	Edge type starting from node(number of edges)
University	1,000
Department	34	subOrganizationOf (552)
Full Professor	289	doctoralDegreeFrom (1,242) mastersDegreeFrom (1,242) undergraduateDegreeFrom (5,561) worksFor (1,242) teacherOf (3,728) headOf (34) publicationAuthor (24,688)
Associate Professor	410
Assistant Professor	333
Lecturer	210
Undergraduate Student	13,559	memberOf (17,878) takesCourse (49,305) advisor (7,044) teachingAssistantOf (947)
Graduate Student	4319
Course	1,889
GraduateCourse	1,839
ResearchGroup	518
Publication	13934
Total	38,334	113,464

Fig. 3. 
Neo4j example execution plan

Neo4j의 Cypher는 MATCH 문에서 그래프 경로에 따라 질의를 하며 결과는 RETURN 문을 통하여 반환된다. 예를 들어 교수의 강좌를 찾는 경우 질의는 다음과 같다. Neo4j 그래프 DBMS 질의의 실행 계획은 NodeByLabelScan, Expand, Filter 등의 연산을 사용한다.

MATCH (a:FullProfessor)--(b:Course)
RETURN count(*)

(2) SQL Server용 데이터 생성

LUBM GraphML 형식의 데이터로 부터 SQL Server의 SQL Graph 데이터 스키마 설계는 수작업으로 진행하였으며, 노드는 노드 테이블로, 에지는 에지 테이블로 스키마 설계를 한다.

스키마 생성 과정에서 그래프 노드는 노드 테이블로, 에지는 에지 테이블로 변환한다.

노드 테이블 생성의 예를 들면 다음과 같다.

CREATE TABLE departments (
  departmentid smallint NOT NULL,
  universityid smallint NOT NULL) AS NODE;

에지 테이블 생성의 예로 교수와 학과의 소속 관계를 나타내는 worksFor는 다음과 같은 에지로 생성된다.

CREATE TABLE worksFor AS EDGE;

그래프 노드를 관계 테이블로 변환하는 방법은 유사한 노드 타입을 통합된 테이블로 구성하는 방법과 그래프 노드를 1:1로 테이블로 변환하는 방법이 있다. 이 경우 장단점이 있는데 본 연구에서는 관계 데이터베이스 설계 시와 가까운 전자의 방법을 선택하였다[15]. 예를 들면 교수를 나타내는 FullProfessor, AssociateProfessor, AssistantProfessor, Lecturer 4가지 노드는 관계 데이터베이스에서는 Teacher 테이블로 통합한다. Teacher 테이블에 ttype 속성을 두어 교수의 타입을 구분한다.

GraphML 데이터로부터 DML 생성은 본 논문에서 Python 프로그램으로 제작하였다.

그림 4는 SQL Graph 용으로 설계된 스키마 구조를 나타낸다.

Fig. 4. 
Schema for SQL graph

Fig. 5. 
Example execution plan of SQL graph

SQL Server의 SQL Graph는 SQL 구문에 MATCH 문을 추가하여 사용한다. MATCH 문은 Neo4j의 MATCH 문과는 달리 에지에 반드시 바운드되는 에지 이름을 적도록 제한되어 있다. 예를 들어 교수의 강좌를 찾는 경우 질의는 다음과 같다. SQL Server의 실행 계획은 Hash Match 연산을 사용한다.

SELECT count(*)
FROM teachers t, teacherof, courses c
WHERE MATCH(t-(teacherof)->c)
   AND t.ttype=3 AND c.ctype=0;

그래프 질의는 패턴 질의(Pattern Matching Query)와 분석 질의(Analytical Query)로 나눈다[10]. 패턴질의는 노드 레이블로 경로 필터링, 에지 레이블로 경로 필터링, 싸이클 등 그래프의 일부분을 접근하는 질의이고, 분석질의는 노드 차수, 차수의 집중도, 연결성, 최단 거리 계산 등 그래프의 많은 부분을 접근하는 질의이다.

(정의) 그래프 패턴 P

그래프 G=(V, E)가 주어졌을 때, 그래프 패턴 P는 P=(Vp, Ep)로 나타내며 부분 그래프가 노드와 에지에 대한 조건 p를 각각 만족한다.

본 연구에서는 그래프 패턴 질의의 대표적인 타입 4가지에 대하여 질의를 Cypher(Neo4j)와 SQL Graph(SQL Server), SQL(Oracle) 언어로 실험을 한다. 4가지 타입은 Jürgen Hölsch[10] 연구에서 구분한 방법으로, 노드 레이블로 경로 필터링, 에지 레이블로 경로 필터링, 노드/에지 레이블로 경로 필터링, 사이클 경로 타입의 질의이다. 성능 평가를 좀 더 정밀하게 하기 위하여 4가지 질의 패턴 타입 각각에 단순질의, 복잡질의의 2가지 형으로 나누어 실험한다.

질의의 타입과 실험을 위한 LUBM 벤치마크 예제 질의 4가지 타입, 8가지 질의는 다음과 같다.

(1) 패턴 질의 타입 1: 노드 레이블로 경로 필터링 : 그래프 노드 레이블로 필터링하는 질의로 에지에는 제한을 두지 않는 경우이다. 즉 탐색 에지를 질의에 바운드 시키지 않은 경우이다. SQL Graph나 SQL은 에지에 해당되는 교차테이블이나 외래키를 반드시 바운드 시켜야 한다.

(Q 1: 단순형) 정교수(FullProfessor)의 강좌를 찾아내는 질의를 구하여라.

(Cypher)
   MATCH (a:FullProfessor)--(b:Course)
   RETURN count(*)
(SQL Graph)
   SELECT count(*)
   FROM teachers t, teacherof, courses c
   WHERE MATCH(t-(teacherof)->c)
      AND t.ttype=3 AND c.ctype=0;
(SQL)
   SELECT count(*)
   FROM teachers t, courses c
   WHERE t.uniid=c.uniid AND t.depid=c.depid
      AND t.id=c.teacherid AND t.ttype=c.teachertype
      AND t.ttype=3 c.ctype=0;

SQL 문의 경우 복합키를 사용하였기 때문에 질의가 길어지는 불가피함이 발생한다. 예를 들어 Teacher 테이블의 키는 (대학번호, 학과번호, 교수번호, 교수타입)으로 (uniid, deptid, teacherid, ttype)가 된다. 스키마 생성시 인조키를 만들어 기본키로 설정했다면 질의가 다음과 같이 간단해진다.

SELECT count(*)
FROM teachers t, courses c
WHERE t.id=c.teacherid;

그러나 LUBM 벤치마크에 노드에 기본키가 없으므로 본 연구에서는 테이블 변환시 복합키를 그대로 사용하였다.

(Q 2: 복잡형) 정교수(FullProfessor)의 학과, 학과소속학생, 학생의 수강강좌를 찾아내는 질의를 구하여라.

(Cypher)
   MATCH (b:FullProfessor)--(c:Department)
    --(d:UndergraduateStudent)--(e:Course)
   RETURN count(*)
(SQL Graph)
   SELECT count(*)
   FROM teachers t, worksfor, departments d,
    memberof, students s, takescourse, courses c
   WHERE
      MATCH (t-(worksfor)->d<-(memberof)-s
     -(takescourse)->c)
      AND t.ttype=3 AND s.stype=0 AND c.ctype=0;
(SQL)
   SELECT count(*)
   FROM university u, teachers t, departments d,
    students s, takescourse tc, courses c
   WHERE u.universityid=t.uniid
      AND t.uniid=d.universityid
      AND t.depid=d.departmentid
      AND d.universityid=s.uniid
      AND d.departmentid=s.depid
      AND s.uniid=tc.uniid AND s.depid=tc.depid
      AND s.stype=tc.studtype AND s.id=tc.studid
      AND tc.uniid=c.uniid AND tc.depid=c.depid
      AND tc.coursetype=c.ctype AND tc.courseid=c.id
      AND t.ttype=3 AND s.stype=0 AND c.ctype=0;

(2) 패턴 질의 타입 2: 에지 레이블로 경로 필터링 : 그래프 에지 레이블로 필터링하는 질의로 노드에는 제한을 두지 않는 경우이다. 즉 탐색 노드를 질의에 바운드 시키지 않은 경우이다. SQL Graph나 SQL은 노드에 해당되는 테이블을 반드시 바운드 시켜야 한다.

(Q 3: 단순형) 교수의 강좌와 강좌를 듣는 수강학생들을 보여라.

(Cypher)
      MATCH (a)-[:teacherOf]->(b)<-[:takesCourse]-(c)
      RETURN count(*)
(SQL Graph)
      SELECT count(*)
      FROM teachers t, teacherof, courses c,
       takescourse, students s
      WHERE MATCH (t-(teacherOf)->c<-(takescourse)-s);
(SQL)
      SELECT count(*)
      FROM teachers t, courses c,
       takescourse tc, students s
      WHERE t.uniid=c.uniid AND t.depid=c.depid
         AND t.id=c.teacherid AND t.ttype=c.teachertype
         AND c.uniid=tc.uniid AND c.depid=tc.depid
         AND c.id=tc.courseid AND c.ctype=tc.coursetype
         AND tc.uniid=s.uniid AND tc.depid=s.depid
         AND tc.studid=s.id AND tc.studtype=s.stype;

(Q 4: 복잡형) 교수의 강좌를 듣는 학생의 지도교수의 석사학위 대학, 같은 대학 박사학위 교수 관계를 보여라.

(Cypher)
   MATCH (a)-[:teacherOf]->(b)<-[:takesCourse]-(c)
      -[:advisor]->(d)-[:mastersDegreeFrom]->(e)
    <-[:doctoralDegreeFrom]-(f)
   RETURN count(*)
(SQL Graph)
   SELECT count(*)
   FROM teachers t, teacherof, courses c, takescourse,
    students s, advisor, teachers tt,
    mastersDegreeFrom, university u,
    doctoralDegreeFrom, teachers ttt
   WHERE
      MATCH (t-(teacherof)->c<-(takesCourse)-s
    -(advisor)->tt-(mastersDegreeFrom)->u
    <-(doctoralDegreeFrom)-ttt);
(SQL)
   SELECT count(*)
   FROM teachers t, courses c, takescourse tc,
    students s, teachers tt, university u,
    teachers ttt
   WHERE t.uniid=c.uniid AND t.depid=c.depid
      AND t.ttype=c.teachertype AND t.id=c.teacherid
      AND c.uniid=tc.uniid AND c.depid=tc.depid
      AND c.ctype=tc.coursetype AND c.id=tc.courseid
      AND tc.uniid=s.uniid AND tc.depid=s.depid
      AND tc.studtype=s.stype AND tc.studid=s.id
      AND s.uniid=tt.uniid AND s.depid=tt.depid
      AND s.advisortype=tt.ttype AND s.advisorid=tt.id
      AND tt.masterD=u.universityid
      AND ttt.docD=u.universityid;

(3) 패턴 질의 타입 3: 노드/에지 레이블로 경로 필터링 : 그래프 노드 및 에지 레이블로 필터링하는 질의이다.

(Q 5: 단순형) 정교수의 강좌와 강좌를 듣는 학부학생들을 보여라.

(Cypher)
   MATCH (a:FullProfessor)-[:teacherOf]->(b:Course)
    <-[:takesCourse]-(c:UndergraduateStudent)
   RETURN count(*)
(SQL Graph)
   SELECT count(*)
   FROM teachers t, teacherof, courses c,
    takescourse, students s
   WHERE MATCH (t-(teacherOf)->c<-(takescourse)-s)
      AND t.ttype=3 AND c.ctype=0 AND s.stype=0;
(SQL)
   SELECT count(*)
   FROM teachers t, courses c,
    takescourse tc, students s
   WHERE t.uniid=c.uniid AND t.depid=c.depid
      AND t.id=c.teacherid AND t.ttype=c.teachertype
      AND c.uniid=tc.uniid AND c.depid=tc.depid
      AND c.id=tc.courseid AND c.ctype=tc.coursetype
      AND tc.uniid=s.uniid AND tc.depid=s.depid
      AND tc.studid=s.id AND tc.studtype=s.stype
      AND t.ttype=3 AND c.ctype=0 AND s.stype=0;

(Q 6: 복잡형) 정교수의 강좌와 강좌를 듣는 학부학생들의 부교수인 지도교수의 석사학위 대학을보여라.

(Cypher)
   MATCH (a:FullProfessor)-[:teacherOf]->(b:Course)
    <-[:takesCourse]-(c:UndergraduateStudent)
    -[:advisor]->(d:AssociateProfessor)
    -[:mastersDegreeFrom]->(e:University)
   RETURN count(*)
(SQL Graph)
   SELECT count(*)
   FROM teachers t, teacherof, courses c, takescourse,
    students s, advisor, teachers tt,
    mastersDegreeFrom, university u
   WHERE
      MATCH (t-(teacherOf)->c<-(takescourse)-s-
          (advisor)->tt-(mastersDegreeFrom)->u)
      AND t.ttype=3 AND c.ctype=0 AND s.stype=0
      AND tt.ttype=2;
(SQL)
   SELECT count(*)
   FROM teachers t, courses c, takescourse tc,
    students s, teachers tt, university u
   WHERE t.uniid=c.uniid AND t.depid=c.depid
      AND t.ttype=c.teachertype AND t.id=c.teacherid
      AND c.uniid=tc.uniid AND c.depid=tc.depid
      AND c.ctype=tc.coursetype AND c.id=tc.courseid
      AND tc.uniid=s.uniid AND tc.depid=s.depid
      AND tc.studtype=s.stype AND tc.studid=s.id
      AND s.uniid=tt.uniid AND s.depid=tt.depid
      AND s.advisortype=tt.ttype AND s.advisorid=tt.id
      AND tt.masterD=u.universityid
      AND t.ttype=3 AND c.ctype=0 AND s.stype=0
      AND tt.ttype=2;

(4) 패턴 질의 타입 4: 노드의 사이클

(Q 7: 단순형) 학부학생의 지도교수 중 정교수인 교수와 정교수의 소속학과 관계를 찾아라.

(Cypher)
   MATCH (a:UndergraduateStudent)--(b:FullProfessor)
    --(c:Department)--(a)
   RETURN count(*)
(SQL Graph)
   SELECT count(*)
   FROM students s, advisor, teachers t,
    worksfor, departments d, memberof
   WHERE MATCH(s-(advisor)->t-(worksfor)->d
    <-(memberof)-s)
      AND s.stype=0 AND t.ttype=3;
(SQL)
   SELECT count(*)
   FROM students s, teachers t, departments d
   WHERE s.uniid=t.uniid AND s.depid=t.depid
      AND s.advisorid=t.id AND s.advisortype=t.ttype
      AND t.uniid=d.universityid
      AND t.depid=d.departmentid
      AND d.universityid=s.uniid
      AND d.departmentid=s.depid
      AND t.ttype=3 AND s.stype=0;

(Q 8: 복잡형) 학부학생의 수강과목의 교수가 부교수인 경우에 대한 지도학생의 수강강좌, 수강강좌의 강사가 조교수이며 처음학생의 지도교수를 찾아라.

(Cypher)
   MATCH (a:UndergraduateStudent)--(b:Course)
    --(c:AssociateProfessor)
    --(d:UndergraduateStudent)
    --(e:Course) --(f:AssistantProfessor)--(a)
   WHERE b <> e AND a <> d
   RETURN count(*)
(SQL Graph)
   SELECT count(*)
FROM students s, takescourse tc, courses c,
    teacherof to1, teachers t, advisor a,
    students ss, takescourse tcc, courses cc,
    teacherof to2, teachers tt, advisor aa
WHERE
      MATCH (s-(tc)->c<-(to1)-t
    <-(a)-ss-(tcc)->cc<-(to2)-tt<-(aa)-s)
      AND s.stype=0 AND c.ctype=0
      AND t.ttype=2 AND ss.stype=0
      AND cc.ctype=0 AND tt.ttype=1
      AND NOT (c.uniid=cc.uniid
          AND c.depid=cc.depid
          AND c.ctype=cc.ctype AND c.id=cc.id)
      AND NOT (s.uniid=ss.uniid
          AND s.depid=ss.depid
          AND s.stype=ss.stype AND s.id=ss.id);
(SQL)
   SELECT count(*)
   FROM students s, takescourse tc,courses c,
    teachers t, students ss, takescourse tcc,
    courses cc, teachers tt
   WHERE s.uniid=tc.uniid AND s.depid=tc.depid
      AND s.stype=tc.studtype AND s.id=tc.studid
      AND tc.uniid=c.uniid AND tc.depid=c.depid
      AND tc.coursetype=c.ctype AND tc.courseid=c.id
      AND c.uniid=t.uniid AND c.depid=t.depid
      AND c.teachertype=t.ttype AND c.teacherid=t.id
      AND t.uniid=ss.uniid AND t.depid=ss.depid
      AND t.ttype=ss.advisortype AND t.id=ss.advisorid
      AND ss.uniid=tcc.uniid AND ss.depid=tcc.depid
      AND ss.stype=tcc.studtype AND ss.id=tcc.studid
      AND tcc.uniid=cc.uniid AND tcc.depid=cc.depid
      AND tcc.coursetype=cc.ctype AND tcc.courseid=cc.id
      AND cc.uniid=tt.uniid AND cc.depid=tt.depid
      AND cc.teachertype=tt.ttype AND cc.teacherid=tt.id
      AND tt.uniid=s.uniid AND tt.depid=s.depid
      AND tt.ttype=s.advisortype AND tt.id=s.advisorid
      AND NOT ((c.uniid = cc.uniid)
      AND (c.depid = cc.depid)
      AND (c.teachertype = cc.teachertype)
      AND (c.teacherid = cc.teacherid))
         AND NOT ((s.uniid = ss.uniid)
      AND (s.depid = ss.depid)
      AND (s.stype = ss.stype) AND (s.id = ss.id))
      AND s.stype=0 AND c.ctype=0
      AND t.ttype=2 AND ss.stype=0
      AND cc.ctype=0 AND tt.ttype=1;

실험을 위한 컴퓨터는 Windows 10 Home, Intel Premium CPU G4400 3.30GHz, 8GB RAM을 사용하였다. 그래프 데이터베이스는 neo4j 3.4.1, 관계형 데이터베이스는 오라클 12c, 그래프 SQL은 SQL Server 2017을 사용하였다. LUBM 그래프 데이터를 SQL 데이터로 변환하는 DML 생성은 Python 프로그램으로 작성하였다.

패턴질의는 앞 절에서 설명한 4가지 패턴의 단순형/복잡형 8가지 질의(Q1~Q8)를 테스트하였다. DBMS 결과를 출력하는 오버헤드가 다르기 때문에 패턴질의의 결과는 count(*)를 출력하도록 하여 IO 지연 시간을 제거하였다. 수행시간은 8가지 질의 타입에 대하여 각각 5번 무작위 실험하여 최대/최소를 제거한 3개 평균값으로 하였다. 실험 결과 각 질의마다 매 실험 중 첫 번째 실험이 시간이 많이 걸린다. 3가지 DBMS 모두 비슷한 현상이지만 특히 오라클은 첫 번째 질의 시간이 가장 많이 걸리고 이후 수행시간이 최적화 작동으로 인하여 급속히 감소한다. 실험에서는 두 번째 이후 시간을 측정하였다.

질의의 실행계획을 살펴보면 Neo4j의 Cypher는 All Node Scan(Q3, Q4) 혹은 Node by Label Scan(Q1-Q2, Q5-Q8)이었으며, SQL Server의 SQL Graph는 Hash Match, 오라클의 SQL은 Hash Join으로 실행되었다.

각 질의들의 실행 시간 평균은 표 2와 같다.

표 2의 실험 결과를 보면 다음을 관찰할 수 있었다.

(1) MATCH 문을 사용하는 Neo4j의 Cypher와 SQL Server의 SQL Graph를 비교해보면 Cypher는 SQL Graph에 비하여 그래프의 노드 혹은 에지가 바운드되지 않은 패턴 타입 1과 패턴 타입 2와 같은 경우 수행시간이 더 크다(Q1~Q4). 그러나 패턴 타입 3과 패턴 타입 4와 같이 탐색해야할 에지나 노드가 바운드되어 정해진 질의의 경우 SQL Graph보다 수행시간이 더 작다(Q5~Q8). 그림 6은 Neo4j Cypher와 SQL Graph를 비교한 것이다.

Fig. 6. 
Neo4j and SQL graph query comparison

(2) SQL Server의 SQL Graph와 오라클의 SQL 문을 비교해보면 복잡한 그래프 패턴 질의가 아닌 경우 오라클의 SQL은 SQL Server의 SQL Graph 보다 수행 시간이 작다. 오라클은 이미 알려진 성숙한 최적화 기능을 통하여 수행 시간을 단축시킨다. 그러나 그래프의 경로가 4 이상인 질의의 경우는 오라클은 Neo4j나 SQL Graph보다 수행 시간이 더 오래 걸린다(Q4, Q6, Q8). 그림 7은 SQL Graph와 오라클 SQL의 수행 시간을 각각 비교한 것이다.

Fig. 7. 
SQL graph and SQL query comparison

전체적으로 그래프 패턴 질의에서 그래프 경로가 길어지면 MATCH 문을 사용하는 Cypher와 SQL Graph를 사용하는 질의가 일반 SQL 질의보다 성능이 뛰어나다. Cypher 질의어의 경우 탐색할 에지와 노드가 질의문 안에 바운드 되는 경우나 싸이클 질의 경우 SQL Graph 보다 더 우수한 결과를 나타내었다고 볼 수 있다.

그래프 패턴질의를 위한 질의 언어 3 가지를 다음으로 비교할 수 있다. 질의 언어의 질적인 면은 정량화하기는 어렵지만 개발자에게 질의 언어의 선택에 도움을 줄 수 있다.

(1) 프로그래밍의 용이성 측면에서 Neo4j의 Cypher는 그래프 데이터베이스에 가장 적합하다. 그래프 데이터베이스를 사용할 수 없다면 SQL Server의 SQL Graph와 같이 그래프 질의에 SQL 언어를 사용할 수 있음은 큰 장점이다. 개발자들이 기존의 SQL 언어에 그래프 언어인 Cypher 스타일 언어를 사용함으로써 프로그래밍을 쉽게 한다. 그래프 패턴 질의를 오라클 경우와 같이 SQL 만으로 표현하면 많은 조인이 필요하다.

(2) DBMS 성숙도 및 지원 면에서는 오라클과 SQL Sever가 DBMS 기능 완성도 및 지원 면에서 매우 우수하다. 관계 데이터베이스는 다양한 응용에 구축되어 왔고 버그가 적으며 기능 지원이 많다. 그래프 데이터베이스는 아직 시장 규모가 작고 제작사인 Neo4j사나 wiki에서 기술적으로 지원되고 있다. SQL Graph는 2017년 추가된 기능으로 아직 완성도 및 지원은 낮은 편이다.

(3) 데이터 무결성 및 보안 측면에서 관계 데이터베이스는 트랜잭션의 ACID 성질을 지원하여 보안 방법 및 도구가 그래프 데이터베이스에 비하여 매우 우수하다.

데이터베이스의 그래프 질의어를 표 3에서 비교하였다.