2018.03.23

연결된 데이터베이스 저장에 유용한 ‘그래프 데이터베이스’의 이해

Serdar Yegulalp | InfoWorld
키 값, 문서 지향, 컬럼 패밀리, 그래프, 관계형… 오늘날 데이터베이스의 종류는 데이터의 종류만큼 다양한 듯하다. 덕분에 데이터베이스를 선택하기는 더 어려울지 몰라도 적절한 데이터베이스를 선택하기는 더 쉽다. 물론 숙제가 필요하다. 데이터베이스에 대해 알아야 한다.

현재 시장에서 이해도가 가장 낮은 데이터베이스 유형 중 하나는 그래프 데이터베이스다. 고도로 상호 연결된 데이터에 적합하도록 설계된 그래프 데이터베이스는 관계형 데이터베이스보다 더 ‘관계적인’ 데이터베이스로 설명할 수 있다. 그래프 데이터베이스는 광범위한 정보의 거미줄에서 복잡한 관계를 포착하고자 할 때 빛을 발한다.



이 글에서는 그래프 데이터베이스가 무엇이고, 다른 데이터베이스와 왜 다르며, 어떤 종류의 데이터 문제를 해결하는 데 적합한지 알아본다.

그래프 데이터베이스 vs. 관계형 데이터베이스
전통적인 관계형 또는 SQL 데이터베이스에서 데이터는 테이블로 정리된다. 각 테이블은 고정된 수의 컬럼을 사용해 특정 형식으로 데이터를 기록하며 각 컬럼은 자체적인 데이터 형식(정수, 시간/날짜, 자유 텍스트 등)을 갖는다.

이 모델은 주로 하나의 테이블 데이터를 다룰 때 가장 적합하다. 또한 여러 테이블에 걸쳐 저장된 데이터를 집계하는 용도로도 나쁘지는 않다. 그러나 이 경우 몇 가지 눈에 띄는 제약이 있다.

음악 데이터베이스를 생각해 보자. 앨범과 밴드, 레이블, 연주자가 있다. 그 레이블에서 내놓은 저 밴드의 이 앨범에 참여한 모든 연주자를 보고하려면(4가지 서로 다른 테이블), 이러한 관계를 명시적으로 기술해야 한다. 관계형 데이터베이스에서는 새 데이터 컬럼(일대일 또는 일대다 관계) 또는 새 테이블(다대다 관계)을 통해 이를 수행한다.

관리하는 관계의 수가 적절하다면 이 방법은 실용적이다. 그러나 수백만, 많게는 수십억 개의 관계를 다룬다면(예를 들어 친구의 친구의 친구) 이러한 쿼리는 효과적으로 확장되지 않는다.
간단히 말해 데이터 자체가 아닌 데이터 간 관계가 주 관심사라면 다른 종류의 데이터베이스, 바로 그래프 데이터베이스가 효과적이다.

그래프 데이터베이스의 특징
“그래프”라는 용어는 수학의 그래프에서 따왔다. 그래프는 각각 정보(속성)를 포함하고 사이에 레이블이 붙은 관계(또는 모서리)가 있는 노드(또는 꼭지점) 모음을 설명하는 데 사용된다.
소셜 네트워크는 그래프의 좋은 예다. 소셜 네트워크에서 사람들은 노드, 각 사람의 특성(이름, 나이 등)은 속성, 사람들을 연결하는 선(“친구” 또는 “엄마” 또는 “상사”와 같은 레이블이 붙음)은 관계를 나타낸다.

전통적인 데이터베이스에서 관계에 대한 쿼리를 처리하려면 오랜 시간이 소요될 수 있다. 관계가 외래 키로 구현되고 테이블 조인에 의해 쿼리되기 때문이다. SQL DBA라면 누구나 알겠지만 조인은 특히 많은 수의 개체를 정렬해야 하거나 더 심하게는 여러 테이블을 조인해서 간접(예를 들어 “친구의 친구”) 쿼리를 수행해야 할 경우 값비싼 작업이다. 그래프 데이터베이스는 바로 이 부분에 강점이 있다.

그래프 데이터베이스는 관계를 데이터와 함께 저장한다. 관계된 노드는 데이터베이스에서 물리적으로 연결되므로 이러한 관계에 대한 접근은 데이터 자체에 대한 접근과 대등하게 즉각적이다. 즉, 그래프 데이터베이스는 관계형 데이터베이스처럼 관계를 계산하지 않고 단순히 스토리지에서 관계를 읽기만 한다. 쿼리를 충족하는 과정은 그래프를 따라 걷거나 “횡단하는” 간단한 작업이다.

그래프 데이터베이스는 개체 간 관계를 기본적인 방식으로 저장해서 관계에 대한 쿼리를 쉽고 빠르게 할 뿐만 아니라 다양한 종류의 개체와 다양한 종류의 관계를 그래프에 포함할 수 있게 해준다. 다른 NoSQL 데이터베이스와 마찬가지로 그래프 데이터베이스에도 스키마가 없다. 따라서 성능과 유연성 측면에서 그래프 데이터베이스는 관계형 또는 테이블 지향 데이터베이스보다 문서 데이터베이스 또는 키 값 저장소에 더 가깝다.

그래프 데이터베이스 사용 사례
그래프 데이터베이스는 다루는 데이터가 고도로 연결되며 그 데이터가 다른 데이터와 어떻게 연결되고 다른 데이터를 어떻게 참조하는지에 의해 그 데이터를 표현해야 할 때(일반적으로 다대다 관계를 통해) 가장 적합하다.

앞서도 말했지만 소셜 네트워크가 좋은 예다. 그래프 데이터베이스는 활동 피드와 같은 소셜 네트워크에 있는 데이터 뷰를 구성하고 표시하거나, 여러분의 소셜 네트워크 친구와 가까운 누군가를 여러분이 알 가능성을 결정하는 데 필요한 작업을 줄여준다.

그래프 데이터베이스의 또 다른 응용은 다른 데이터 표현으로는 알아내기 어려운 그래프 데이터의 연결 패턴 찾기다. 사기 탐지 시스템은 그래프 데이터베이스를 사용해서 다른 방법으로는 알아내기 어려운 엔티티 간 관계를 밝혀낸다.

비슷한 맥락에서 그래프 데이터베이스는 엔티티 간 관계나 상호종속성을 관리하는 애플리케이션에도 잘 어울린다. 추천 엔진, 콘텐츠 및 자산 관리 시스템, ID 및 액세스 관리 시스템, 규정 준수 및 위험 관리 솔루션에서 그래프 데이터베이스가 많이 사용된다.

그래프 데이터베이스 쿼리
그래프 데이터베이스는 다른 NoSQL 데이터베이스와 마찬가지로 SQL 대신 일반적으로 자체 맞춤형 쿼리 방법론을 사용한다.

흔히 사용되는 그래프 쿼리 언어 중 하나는 네오4j(Neo4j) 그래프 데이터베이스용으로 개발된 사이퍼(Cypher)다. 사이퍼는 2015년 하반기부터 별도의 오픈 소스 프로젝트로 개발됐으며 다른 여러 밴더가 각각의 제품을 위한 쿼리 시스템으로 도입했다(예: SAP HANA).

Scott의 친구인 모든 사람을 찾는 검색 결과를 반환하는 사이퍼 쿼리의 예는 다음과 같다.

MATCH (a:Person {name:’Scott’})-[:FRIENDOF]->(b)
RETURN b


화살표 기호((->))는 사이퍼 쿼리에서 그래프의 방향성 관계를 나타내는 데 사용된다.
많이 사용되는 또 다른 그래프 쿼리 언어인 그렘린(Gremlin)은 아파치 팅커팝(TinkerPop) 그래프 컴퓨팅 프레임워크용으로 개발됐다. 그렘린 구문은 일부 언어의 ORM 데이터베이스 액세스 라이브러리에 사용되는 구문과 비슷하다.

그렘린의 “Scott의 친구” 쿼리 예는 다음과 같다.

g.V().has(“name”,”Scott”).out(“friendof”)

많은 그래프 데이터베이스는 내장 또는 서드파티 라이브러리를 통해 그렘린을 지원한다.
그 외의 쿼리 언어로 스파클(SPARQL)이 있다. 스파클은 원래 W3C에서 자원 기술 프레임워크(RDF, Resource Description Framework) 형식으로 저장된 데이터를 쿼리하기 위해 개발한 언어다. 달리 말하자면 스파클은 그래프 데이터베이스 검색용으로 고안된 언어는 아니지만 사용은 가능하다. 전체적으로는 사이퍼와 그렘린이 더 광범위하게 사용된다.

스파클 쿼리에서 SELECT 및 WHERE 절과 같은 일부 요소는 SQL을 연상시키지만 그 외의 나머지 구문은 SQL과 완전히 다르다. 스파클은 SQL과도, 또한 다른 그래프 쿼리 언어와도 전혀 관계가 없다.

인기 있는 그래프 데이터베이스
그래프 데이터베이스는 비교적 틈새 사용 사례에 해당하므로 관계형 데이터베이스만큼 종류가 많지는 않다. 대신 눈에 띄는 제품을 그만큼 쉽게 찾고 토론할 수 있다.

네오4j(Neo4j)
네오4j는 일반적인 용도로 단연 가장 성숙하고(11년째) 가장 잘 알려진 그래프 데이터베이스다. 이전의 그래프 데이터베이스 제품과 달리 SQL 백엔드를 사용하지 않는다. 네오4j는 수십만 개의 관계를 반환하는 쿼리와 같이 대규모 그래프 구조를 지원하기 위해 내부에서 만들어져 나온 네이티브 그래프 데이터베이스다.

네오4j는 무료 오픈 소스와 유료 엔터프라이즈 에디션으로 제공되며 후자는 데이터 집합의 크기에 제한이 없다(그 외에도 여러 기능이 있음). 또한 연습을 위한 몇몇 샘플 데이터 집합이 포함된 샌드박스를 통해 온라인으로 네오4j를 실험할 수 있다.

마이크로소프트 애저 코스모스 DB(Cosmos DB)
애저 코스모스 DB 클라우드 데이터베이스는 야심 찬 프로젝트다. 목표는 일관적인 API 집합으로 여러 종류의 데이터베이스(전통적인 테이블, 문서 지향, 컬럼 패밀리 및 그래프 데이터베이스)를 하나의 통합 서비스를 통해 에뮬레이트하는 것이다.

그런 면에서 그래프 데이터베이스는 코스모스 DB의 다양한 작동 모드 중 하나일 뿐이다. 그렘린 쿼리 언어와 그래프 형식 쿼리를 위한 API를 사용하며, 아파치 팅커팝용으로 만들어진 그렘린 콘솔을 부가적 인터페이스로 지원한다.

코스모스 DB의 또 다른 큰 특징은 인덱싱, 확장, 지역 복제(geo-replication)가 사람의 개입 없이 애저 클라우드에서 자동으로 처리된다는 점이다. 마이크로소프트의 올인원 아키텍처가 성능 측면에서 네이티브 그래프 데이터베이스와 비교해 어느 정도일지는 아직 확실치 않지만 코스모스 DB는 확실히 쓸모가 있는 유연성과 규모의 조합을 제공한다.

야누스그래프(JanusGraph)
야누스그래프는 타이탄DB(TitanDB) 프로젝트에서 분리돼 나왔으며 현재 리눅스 재단의 관할 하에 있다. 여러 가지 지원되는 백엔드(아파치 카산드라, 아파치 H베이스(HBase), 구글 클라우드 빅테이블(Bigtable), 오라클 버클리DB(BerkeleyDB))를 사용해서 그래프 데이터를 저장하며 그렘린 쿼리 언어를 지원하고(아파치 팅커팝 스택의 다른 요소도 지원) 아파치 솔라(Solr), 아파치 루신(Lucene) 또는 엘라스틱서치(Elasticsearch) 프로젝트를 통해 전체 텍스트 검색도 수용할 수 있다.

야누스그래프 프로젝트의 후원사 중 하나인 IBM은 IBM 클라우드에서 호스팅 버전의 야누스그래프인 컴포즈 포 야누스그래프(Compose for JanusGraph)를 제공한다. 컴포즈 포 야누스그래프는 애저 코스모스 DB와 마찬가지로 자동 확장 및 고가용성을 제공하며 가격은 리소스 사용량을 기준으로 한다. editor@itworld.co.kr


2018.03.23

연결된 데이터베이스 저장에 유용한 ‘그래프 데이터베이스’의 이해

Serdar Yegulalp | InfoWorld
키 값, 문서 지향, 컬럼 패밀리, 그래프, 관계형… 오늘날 데이터베이스의 종류는 데이터의 종류만큼 다양한 듯하다. 덕분에 데이터베이스를 선택하기는 더 어려울지 몰라도 적절한 데이터베이스를 선택하기는 더 쉽다. 물론 숙제가 필요하다. 데이터베이스에 대해 알아야 한다.

현재 시장에서 이해도가 가장 낮은 데이터베이스 유형 중 하나는 그래프 데이터베이스다. 고도로 상호 연결된 데이터에 적합하도록 설계된 그래프 데이터베이스는 관계형 데이터베이스보다 더 ‘관계적인’ 데이터베이스로 설명할 수 있다. 그래프 데이터베이스는 광범위한 정보의 거미줄에서 복잡한 관계를 포착하고자 할 때 빛을 발한다.



이 글에서는 그래프 데이터베이스가 무엇이고, 다른 데이터베이스와 왜 다르며, 어떤 종류의 데이터 문제를 해결하는 데 적합한지 알아본다.

그래프 데이터베이스 vs. 관계형 데이터베이스
전통적인 관계형 또는 SQL 데이터베이스에서 데이터는 테이블로 정리된다. 각 테이블은 고정된 수의 컬럼을 사용해 특정 형식으로 데이터를 기록하며 각 컬럼은 자체적인 데이터 형식(정수, 시간/날짜, 자유 텍스트 등)을 갖는다.

이 모델은 주로 하나의 테이블 데이터를 다룰 때 가장 적합하다. 또한 여러 테이블에 걸쳐 저장된 데이터를 집계하는 용도로도 나쁘지는 않다. 그러나 이 경우 몇 가지 눈에 띄는 제약이 있다.

음악 데이터베이스를 생각해 보자. 앨범과 밴드, 레이블, 연주자가 있다. 그 레이블에서 내놓은 저 밴드의 이 앨범에 참여한 모든 연주자를 보고하려면(4가지 서로 다른 테이블), 이러한 관계를 명시적으로 기술해야 한다. 관계형 데이터베이스에서는 새 데이터 컬럼(일대일 또는 일대다 관계) 또는 새 테이블(다대다 관계)을 통해 이를 수행한다.

관리하는 관계의 수가 적절하다면 이 방법은 실용적이다. 그러나 수백만, 많게는 수십억 개의 관계를 다룬다면(예를 들어 친구의 친구의 친구) 이러한 쿼리는 효과적으로 확장되지 않는다.
간단히 말해 데이터 자체가 아닌 데이터 간 관계가 주 관심사라면 다른 종류의 데이터베이스, 바로 그래프 데이터베이스가 효과적이다.

그래프 데이터베이스의 특징
“그래프”라는 용어는 수학의 그래프에서 따왔다. 그래프는 각각 정보(속성)를 포함하고 사이에 레이블이 붙은 관계(또는 모서리)가 있는 노드(또는 꼭지점) 모음을 설명하는 데 사용된다.
소셜 네트워크는 그래프의 좋은 예다. 소셜 네트워크에서 사람들은 노드, 각 사람의 특성(이름, 나이 등)은 속성, 사람들을 연결하는 선(“친구” 또는 “엄마” 또는 “상사”와 같은 레이블이 붙음)은 관계를 나타낸다.

전통적인 데이터베이스에서 관계에 대한 쿼리를 처리하려면 오랜 시간이 소요될 수 있다. 관계가 외래 키로 구현되고 테이블 조인에 의해 쿼리되기 때문이다. SQL DBA라면 누구나 알겠지만 조인은 특히 많은 수의 개체를 정렬해야 하거나 더 심하게는 여러 테이블을 조인해서 간접(예를 들어 “친구의 친구”) 쿼리를 수행해야 할 경우 값비싼 작업이다. 그래프 데이터베이스는 바로 이 부분에 강점이 있다.

그래프 데이터베이스는 관계를 데이터와 함께 저장한다. 관계된 노드는 데이터베이스에서 물리적으로 연결되므로 이러한 관계에 대한 접근은 데이터 자체에 대한 접근과 대등하게 즉각적이다. 즉, 그래프 데이터베이스는 관계형 데이터베이스처럼 관계를 계산하지 않고 단순히 스토리지에서 관계를 읽기만 한다. 쿼리를 충족하는 과정은 그래프를 따라 걷거나 “횡단하는” 간단한 작업이다.

그래프 데이터베이스는 개체 간 관계를 기본적인 방식으로 저장해서 관계에 대한 쿼리를 쉽고 빠르게 할 뿐만 아니라 다양한 종류의 개체와 다양한 종류의 관계를 그래프에 포함할 수 있게 해준다. 다른 NoSQL 데이터베이스와 마찬가지로 그래프 데이터베이스에도 스키마가 없다. 따라서 성능과 유연성 측면에서 그래프 데이터베이스는 관계형 또는 테이블 지향 데이터베이스보다 문서 데이터베이스 또는 키 값 저장소에 더 가깝다.

그래프 데이터베이스 사용 사례
그래프 데이터베이스는 다루는 데이터가 고도로 연결되며 그 데이터가 다른 데이터와 어떻게 연결되고 다른 데이터를 어떻게 참조하는지에 의해 그 데이터를 표현해야 할 때(일반적으로 다대다 관계를 통해) 가장 적합하다.

앞서도 말했지만 소셜 네트워크가 좋은 예다. 그래프 데이터베이스는 활동 피드와 같은 소셜 네트워크에 있는 데이터 뷰를 구성하고 표시하거나, 여러분의 소셜 네트워크 친구와 가까운 누군가를 여러분이 알 가능성을 결정하는 데 필요한 작업을 줄여준다.

그래프 데이터베이스의 또 다른 응용은 다른 데이터 표현으로는 알아내기 어려운 그래프 데이터의 연결 패턴 찾기다. 사기 탐지 시스템은 그래프 데이터베이스를 사용해서 다른 방법으로는 알아내기 어려운 엔티티 간 관계를 밝혀낸다.

비슷한 맥락에서 그래프 데이터베이스는 엔티티 간 관계나 상호종속성을 관리하는 애플리케이션에도 잘 어울린다. 추천 엔진, 콘텐츠 및 자산 관리 시스템, ID 및 액세스 관리 시스템, 규정 준수 및 위험 관리 솔루션에서 그래프 데이터베이스가 많이 사용된다.

그래프 데이터베이스 쿼리
그래프 데이터베이스는 다른 NoSQL 데이터베이스와 마찬가지로 SQL 대신 일반적으로 자체 맞춤형 쿼리 방법론을 사용한다.

흔히 사용되는 그래프 쿼리 언어 중 하나는 네오4j(Neo4j) 그래프 데이터베이스용으로 개발된 사이퍼(Cypher)다. 사이퍼는 2015년 하반기부터 별도의 오픈 소스 프로젝트로 개발됐으며 다른 여러 밴더가 각각의 제품을 위한 쿼리 시스템으로 도입했다(예: SAP HANA).

Scott의 친구인 모든 사람을 찾는 검색 결과를 반환하는 사이퍼 쿼리의 예는 다음과 같다.

MATCH (a:Person {name:’Scott’})-[:FRIENDOF]->(b)
RETURN b


화살표 기호((->))는 사이퍼 쿼리에서 그래프의 방향성 관계를 나타내는 데 사용된다.
많이 사용되는 또 다른 그래프 쿼리 언어인 그렘린(Gremlin)은 아파치 팅커팝(TinkerPop) 그래프 컴퓨팅 프레임워크용으로 개발됐다. 그렘린 구문은 일부 언어의 ORM 데이터베이스 액세스 라이브러리에 사용되는 구문과 비슷하다.

그렘린의 “Scott의 친구” 쿼리 예는 다음과 같다.

g.V().has(“name”,”Scott”).out(“friendof”)

많은 그래프 데이터베이스는 내장 또는 서드파티 라이브러리를 통해 그렘린을 지원한다.
그 외의 쿼리 언어로 스파클(SPARQL)이 있다. 스파클은 원래 W3C에서 자원 기술 프레임워크(RDF, Resource Description Framework) 형식으로 저장된 데이터를 쿼리하기 위해 개발한 언어다. 달리 말하자면 스파클은 그래프 데이터베이스 검색용으로 고안된 언어는 아니지만 사용은 가능하다. 전체적으로는 사이퍼와 그렘린이 더 광범위하게 사용된다.

스파클 쿼리에서 SELECT 및 WHERE 절과 같은 일부 요소는 SQL을 연상시키지만 그 외의 나머지 구문은 SQL과 완전히 다르다. 스파클은 SQL과도, 또한 다른 그래프 쿼리 언어와도 전혀 관계가 없다.

인기 있는 그래프 데이터베이스
그래프 데이터베이스는 비교적 틈새 사용 사례에 해당하므로 관계형 데이터베이스만큼 종류가 많지는 않다. 대신 눈에 띄는 제품을 그만큼 쉽게 찾고 토론할 수 있다.

네오4j(Neo4j)
네오4j는 일반적인 용도로 단연 가장 성숙하고(11년째) 가장 잘 알려진 그래프 데이터베이스다. 이전의 그래프 데이터베이스 제품과 달리 SQL 백엔드를 사용하지 않는다. 네오4j는 수십만 개의 관계를 반환하는 쿼리와 같이 대규모 그래프 구조를 지원하기 위해 내부에서 만들어져 나온 네이티브 그래프 데이터베이스다.

네오4j는 무료 오픈 소스와 유료 엔터프라이즈 에디션으로 제공되며 후자는 데이터 집합의 크기에 제한이 없다(그 외에도 여러 기능이 있음). 또한 연습을 위한 몇몇 샘플 데이터 집합이 포함된 샌드박스를 통해 온라인으로 네오4j를 실험할 수 있다.

마이크로소프트 애저 코스모스 DB(Cosmos DB)
애저 코스모스 DB 클라우드 데이터베이스는 야심 찬 프로젝트다. 목표는 일관적인 API 집합으로 여러 종류의 데이터베이스(전통적인 테이블, 문서 지향, 컬럼 패밀리 및 그래프 데이터베이스)를 하나의 통합 서비스를 통해 에뮬레이트하는 것이다.

그런 면에서 그래프 데이터베이스는 코스모스 DB의 다양한 작동 모드 중 하나일 뿐이다. 그렘린 쿼리 언어와 그래프 형식 쿼리를 위한 API를 사용하며, 아파치 팅커팝용으로 만들어진 그렘린 콘솔을 부가적 인터페이스로 지원한다.

코스모스 DB의 또 다른 큰 특징은 인덱싱, 확장, 지역 복제(geo-replication)가 사람의 개입 없이 애저 클라우드에서 자동으로 처리된다는 점이다. 마이크로소프트의 올인원 아키텍처가 성능 측면에서 네이티브 그래프 데이터베이스와 비교해 어느 정도일지는 아직 확실치 않지만 코스모스 DB는 확실히 쓸모가 있는 유연성과 규모의 조합을 제공한다.

야누스그래프(JanusGraph)
야누스그래프는 타이탄DB(TitanDB) 프로젝트에서 분리돼 나왔으며 현재 리눅스 재단의 관할 하에 있다. 여러 가지 지원되는 백엔드(아파치 카산드라, 아파치 H베이스(HBase), 구글 클라우드 빅테이블(Bigtable), 오라클 버클리DB(BerkeleyDB))를 사용해서 그래프 데이터를 저장하며 그렘린 쿼리 언어를 지원하고(아파치 팅커팝 스택의 다른 요소도 지원) 아파치 솔라(Solr), 아파치 루신(Lucene) 또는 엘라스틱서치(Elasticsearch) 프로젝트를 통해 전체 텍스트 검색도 수용할 수 있다.

야누스그래프 프로젝트의 후원사 중 하나인 IBM은 IBM 클라우드에서 호스팅 버전의 야누스그래프인 컴포즈 포 야누스그래프(Compose for JanusGraph)를 제공한다. 컴포즈 포 야누스그래프는 애저 코스모스 DB와 마찬가지로 자동 확장 및 고가용성을 제공하며 가격은 리소스 사용량을 기준으로 한다. editor@itworld.co.kr


X