2020.07.27

"데이터가 방대하고 복잡할수록" 그래프 데이터베이스에 주목할 이유

Isaac Sacolick | InfoWorld
20년 전, 필자가 있었던 개발 팀은 채용, 자동차, 부동산 광고에서 검색 가능한 범주를 스캔하는 자연어 처리 엔진을 만들었다. 데이터 관리 문제가 어렵다는 점은 알고 있었다. 광고 형태마다 달라서 데이터가 비교적 간단하다면 자동차 제조사와 모델을 쉽게 알아낼 수 있었지만, 스킬 목록을 기반으로 직업 범주를 파악하는 작업처럼 더 많은 추론이 필요한 경우도 있었다.
 
검색 가능한 모든 용어를 캡처하는 메타데이터 모델을 개발했지만 자연어 처리 엔진을 위해서는 유의미한 메타데이터 관계를 드러낼 모델이 필요했다. 관계형 데이터베이스의 데이터 포인트 간의 임의적인 연결로 메타데이터 모델을 설계하기는 복잡했으므로 객체 데이터베이스를 사용해서 모델을 관리하는 방안을 살펴봤다.
 
ⓒ Getty Images Bank

당시 우리가 객체 데이터베이스로 했던 작업을 지금은 그래프 데이터베이스로 더 효과적으로 할 수 있다. 그래프 데이터베이스는 정보를 노드와 데이터로 저장해서 다른 노드와의 관계를 명시한다. 그래프 데이터베이스는 복잡한 관계를 가진 데이터를 저장하는 용도로 적합성이 입증된 아키텍처다.
 
지난 10년 동안 기업이 다른 NoSQL 및 빅 데이터 기술에 관심을 가지면서 그래프 데이터 사용도 확실히 증가했다. 2018년 전 세계 그래프 데이터베이스 추정 시장 규모는 약 6억 5,100만 달러이며 2026년에는 37억 3,000만 달러에 이를 것으로 전망된다. 그러나 하둡, 스파크를 비롯한 다른 빅 데이터 관리 기술의 인기와 도입, 프로덕션 사용 사례는 그래프 데이터베이스에 비해 훨씬 더 크게 성장했다. 2018년 빅 데이터 기술 추정 시장 규모는 368억 달러이며 2026년에는 1,043억 달러까지 성장할 것으로 전망된다.
 
필자는 더 많은 기업이 그래프 데이터베이스를 고려하지 않는 이유가 궁금했다. 개발자는 일상적으로 객체 단위로 사고하고 XML과 JSON으로 된 계층적 데이터 표현을 사용한다. 인터넷이 하이퍼링크, 그리고 소셜 네트워크의 친구, 친구의 친구 같은 개념을 통해 상호 연결된 그래프라는 점을 감안하면 기술자나 비즈니스 이해관계자 모두 본질적으로 그래프를 이해하고 있다. 그렇다면 더 많은 개발 팀이 애플리케이션에서 그래프 데이터베이스를 사용하지 않는 이유는 무엇일까?
 

그래프 데이터베이스의 쿼리 언어 배우기

그래프 데이터베이스의 노드와 관계 모델링을 이해하기는 비교적 쉽다고 할 수 있지만 쿼리를 위해서는 새로운 방식과 기술을 익혀야 한다.
 
친구와 친구의 친구 목록을 계산하는 예제를 살펴보자. 15년 전에 필자는 여행 소셜 네트워크를 공동 창업했는데, 데이터 모델을 간소하게 유지하기 위해 모든 데이터를 MySQL에 저장했다. 사용자 목록이 저장된 테이블에는 친구를 표현하는 셀프 조인이 있었고, 친구의 목록을 추출하기 위한 쿼리도 비교적 간단했다. 그러나 친구의 친구 목록에 접근하기 위해서는 몹시 복잡한 쿼리가 필요했다. 제대로 작동은 했지만 사용자의 관계망이 클 경우 성능이 떨어졌다.

필자는 주요 그래프 데이터베이스 중 하나인 Neo4j의 최고 과학자 짐 웨버와 친구의 친구 쿼리를 작성하는 방법에 관해 대화를 나눴다. RDF(리소스 기술 프레임워크)와 그렘린(Gremlin)을 사용해서 Neo4j 그래프 데이터베이스를 쿼리하는 방법이 있지만 웨버에 따르면 고객의 90% 이상은 사이퍼(Cypher)를 사용한다고 한다. 친구와 친구의 친구를 추출하는 사이퍼 쿼리는 다음과 같다.

MATCH (me:Person {name:'Rosa'})-[:FRIEND*1..2]->(f:Person)
WHERE me <> f
RETURN f


이 쿼리의 원리는 다음과 같다.

-    레이블이 Person이고 속성 이름이 ‘Rosa’인 노드가 있는 패턴을 찾아서 이를 변수 “me”에 바인딩한다. 쿼리는 “me”에 Person 레이블이 있는 다른 노드와 깊이 1 또는 2에서 외향(outgoing) FRIEND 관계가 있다고 지정하고 일치 항목을 변수 “f”에 바인딩한다.
-    “me”가 “f”와 동일하지 않음을 확인한다. (나는 내 친구들의 친구이므로!)
-    모든 친구와 친구의 친구를 반환한다.
 
이 쿼리는 명쾌하고 효율적이지만 SQL 쿼리에 익숙한 사람이 익히려면 시간이 필요하다. 바로 여기에 그래프 데이터베이스를 추구하는 조직이 직면하는 첫 번째 과제가 있다. SQL은 광범위하게 보급된 보편적 스킬셋이지만 사이퍼를 비롯한 기타 그래프 쿼리 언어는 새로 배워야 하는 기술이라는 점이다.
 

그래프 데이터베이스로 유연한 계층 설계하기

제품 카탈로그, 콘텐츠 관리 시스템, 프로젝트 관리 애플리케이션, ERP, CRM, 모두 계층을 사용해서 정보를 범주화하고 태그를 지정한다. 여기서 문제는 계층적이지 않은 정보가 있음에도 정보 아키텍처를 구조화하기 위한 일관적인 접근 방법을 만들어야 한다는 점이다. 이 과정은 매우 힘들 수 있다. 특히 정보 구조화를 두고 내부적으로 논쟁이 있는 경우, 또는 애플리케이션 최종 사용자에게 필요한 정보가 계층의 다른 부분이 있어 해당 사용자가 정보를 찾을 수 없는 경우 이와 같은 문제가 두드러진다.

그래프 데이터베이스는 임의 계층을 가능하게 할 뿐 아니라, 개발자가 다양한 필요에 따라 다양한 계층 뷰를 만들 수 있게 해준다. 예를 들어 그래프 데이터베이스에 관한 이 기사는 데이터 관리를 위한 콘텐츠 관리 시스템, 새로운 기술, 그래프 데이터를 사용할 가능성이 높은 업종, 일반적인 그래프 데이터베이스 사용 사례 또는 기술 역할의 계층 아래에 표시될 수 있다. 그러면 추천 엔진은 훨씬 더 풍부한 데이터 집합을 사용해서 콘텐츠와 사용자 관심을 연결할 수 있게 된다.
 
필자는 건설 일정 플랫폼인 그릿(Grit)을 포함해 건설 업계를 위한 기술을 판매하는 컨스트럭시브(Construxiv)의 공동 창업자인 마크 클루자와 이야기를 나눴다. 민간 건설 프로젝트 일정을 보면 여러 개의 거래와 장비, 부품, 모델에 대한 참조가 나온다. 하나의 작업 패키지에 프로젝트 계획에 종속되는 수백 개의 일이 포함되는 경우가 흔하다. 이와 같은 계획은 ERP, 건물 정보 모델링 및 기타 프로젝트 계획의 데이터를 통합해서 일정 책임자와 프로젝트 관리자, 하도급 업체에 보여줘야 한다. 클루자는 “그릿의 그래프 데이터베이스를 사용해서 누가, 언제, 어디서, 어떤 장비와 재료로 무엇을 하는지에 관해 훨씬 더 풍부한 관계를 만들 수 있다. 이를 통해 뷰를 개인 맞춤화하고 작업 일정 충돌을 더 효과적으로 예측할 수 있다”고 설명했다.
 
유연한 계층을 활용하기 위해서는 처음부터 그래프 데이터베이스를 사용해 애플리케이션을 설계하는 편이 유리하다. 그러면 애플리케이션 전체가 그래프를 쿼리하고 그래프의 노드, 관계, 레이블, 속성을 활용하도록 설계된다.
클라우드 배포 옵션으로 운영 복잡성 감소
데이터 관리 솔루션을 데이터 센터에 배포하는 일은 간단치 않다. 인프라와 운영 측면에서 보안 요구 사항을 반영하고, 성능 고려 사항을 검토해 서버와 스토리지, 네트워크의 규모를 정해야 하며 재해 복구를 위해 복제 시스템도 운영해야 한다.
 
그래프 데이터베이스를 도입해 실험 중인 기업은 현재 여러 가지 클라우드 옵션을 선택할 수 있다. 엔지니어는 GCP, AWS, 애저에 Neo4j를 배포하거나 Neo4j의 서비스형 데이터베이스인 오라(Aura)를 활용할 수 있다. 타이거그래프(TigerGraph)는 고객 360, 사기 탐지, 추천 엔진, 소셜 네트워크 분석, 공급망 분석과 같은 사용 사례를 위한 시작 키트와 클라우드 상품을 제공한다. 또한 퍼블릭 클라우드 벤더에도 AWS 넵튠(Neptune), 애저 코스모DB의 그렘린 API, 오픈 소스인 GCP 재너스그래프(JanusGraph on GCP), 또는 오라클 클라우드 데이터베이스 서비스의 그래프 기능 등 그래프 데이터베이스 기능이 있다.
 
처음의 질문으로 돌아가 보자. 여러 흥미로운 사용 사례와 시중의 성숙한 그래프 데이터베이스 플랫폼, 그래프 데이터베이스 개발을 배울 수 있는 풍부한 기회와 클라우드 배포 옵션이 제공되는 지금, 더 많은 기술 기업이 그래프 데이터베이스를 사용해야 하지 않을까? editor@itworld.co.kr 


2020.07.27

"데이터가 방대하고 복잡할수록" 그래프 데이터베이스에 주목할 이유

Isaac Sacolick | InfoWorld
20년 전, 필자가 있었던 개발 팀은 채용, 자동차, 부동산 광고에서 검색 가능한 범주를 스캔하는 자연어 처리 엔진을 만들었다. 데이터 관리 문제가 어렵다는 점은 알고 있었다. 광고 형태마다 달라서 데이터가 비교적 간단하다면 자동차 제조사와 모델을 쉽게 알아낼 수 있었지만, 스킬 목록을 기반으로 직업 범주를 파악하는 작업처럼 더 많은 추론이 필요한 경우도 있었다.
 
검색 가능한 모든 용어를 캡처하는 메타데이터 모델을 개발했지만 자연어 처리 엔진을 위해서는 유의미한 메타데이터 관계를 드러낼 모델이 필요했다. 관계형 데이터베이스의 데이터 포인트 간의 임의적인 연결로 메타데이터 모델을 설계하기는 복잡했으므로 객체 데이터베이스를 사용해서 모델을 관리하는 방안을 살펴봤다.
 
ⓒ Getty Images Bank

당시 우리가 객체 데이터베이스로 했던 작업을 지금은 그래프 데이터베이스로 더 효과적으로 할 수 있다. 그래프 데이터베이스는 정보를 노드와 데이터로 저장해서 다른 노드와의 관계를 명시한다. 그래프 데이터베이스는 복잡한 관계를 가진 데이터를 저장하는 용도로 적합성이 입증된 아키텍처다.
 
지난 10년 동안 기업이 다른 NoSQL 및 빅 데이터 기술에 관심을 가지면서 그래프 데이터 사용도 확실히 증가했다. 2018년 전 세계 그래프 데이터베이스 추정 시장 규모는 약 6억 5,100만 달러이며 2026년에는 37억 3,000만 달러에 이를 것으로 전망된다. 그러나 하둡, 스파크를 비롯한 다른 빅 데이터 관리 기술의 인기와 도입, 프로덕션 사용 사례는 그래프 데이터베이스에 비해 훨씬 더 크게 성장했다. 2018년 빅 데이터 기술 추정 시장 규모는 368억 달러이며 2026년에는 1,043억 달러까지 성장할 것으로 전망된다.
 
필자는 더 많은 기업이 그래프 데이터베이스를 고려하지 않는 이유가 궁금했다. 개발자는 일상적으로 객체 단위로 사고하고 XML과 JSON으로 된 계층적 데이터 표현을 사용한다. 인터넷이 하이퍼링크, 그리고 소셜 네트워크의 친구, 친구의 친구 같은 개념을 통해 상호 연결된 그래프라는 점을 감안하면 기술자나 비즈니스 이해관계자 모두 본질적으로 그래프를 이해하고 있다. 그렇다면 더 많은 개발 팀이 애플리케이션에서 그래프 데이터베이스를 사용하지 않는 이유는 무엇일까?
 

그래프 데이터베이스의 쿼리 언어 배우기

그래프 데이터베이스의 노드와 관계 모델링을 이해하기는 비교적 쉽다고 할 수 있지만 쿼리를 위해서는 새로운 방식과 기술을 익혀야 한다.
 
친구와 친구의 친구 목록을 계산하는 예제를 살펴보자. 15년 전에 필자는 여행 소셜 네트워크를 공동 창업했는데, 데이터 모델을 간소하게 유지하기 위해 모든 데이터를 MySQL에 저장했다. 사용자 목록이 저장된 테이블에는 친구를 표현하는 셀프 조인이 있었고, 친구의 목록을 추출하기 위한 쿼리도 비교적 간단했다. 그러나 친구의 친구 목록에 접근하기 위해서는 몹시 복잡한 쿼리가 필요했다. 제대로 작동은 했지만 사용자의 관계망이 클 경우 성능이 떨어졌다.

필자는 주요 그래프 데이터베이스 중 하나인 Neo4j의 최고 과학자 짐 웨버와 친구의 친구 쿼리를 작성하는 방법에 관해 대화를 나눴다. RDF(리소스 기술 프레임워크)와 그렘린(Gremlin)을 사용해서 Neo4j 그래프 데이터베이스를 쿼리하는 방법이 있지만 웨버에 따르면 고객의 90% 이상은 사이퍼(Cypher)를 사용한다고 한다. 친구와 친구의 친구를 추출하는 사이퍼 쿼리는 다음과 같다.

MATCH (me:Person {name:'Rosa'})-[:FRIEND*1..2]->(f:Person)
WHERE me <> f
RETURN f


이 쿼리의 원리는 다음과 같다.

-    레이블이 Person이고 속성 이름이 ‘Rosa’인 노드가 있는 패턴을 찾아서 이를 변수 “me”에 바인딩한다. 쿼리는 “me”에 Person 레이블이 있는 다른 노드와 깊이 1 또는 2에서 외향(outgoing) FRIEND 관계가 있다고 지정하고 일치 항목을 변수 “f”에 바인딩한다.
-    “me”가 “f”와 동일하지 않음을 확인한다. (나는 내 친구들의 친구이므로!)
-    모든 친구와 친구의 친구를 반환한다.
 
이 쿼리는 명쾌하고 효율적이지만 SQL 쿼리에 익숙한 사람이 익히려면 시간이 필요하다. 바로 여기에 그래프 데이터베이스를 추구하는 조직이 직면하는 첫 번째 과제가 있다. SQL은 광범위하게 보급된 보편적 스킬셋이지만 사이퍼를 비롯한 기타 그래프 쿼리 언어는 새로 배워야 하는 기술이라는 점이다.
 

그래프 데이터베이스로 유연한 계층 설계하기

제품 카탈로그, 콘텐츠 관리 시스템, 프로젝트 관리 애플리케이션, ERP, CRM, 모두 계층을 사용해서 정보를 범주화하고 태그를 지정한다. 여기서 문제는 계층적이지 않은 정보가 있음에도 정보 아키텍처를 구조화하기 위한 일관적인 접근 방법을 만들어야 한다는 점이다. 이 과정은 매우 힘들 수 있다. 특히 정보 구조화를 두고 내부적으로 논쟁이 있는 경우, 또는 애플리케이션 최종 사용자에게 필요한 정보가 계층의 다른 부분이 있어 해당 사용자가 정보를 찾을 수 없는 경우 이와 같은 문제가 두드러진다.

그래프 데이터베이스는 임의 계층을 가능하게 할 뿐 아니라, 개발자가 다양한 필요에 따라 다양한 계층 뷰를 만들 수 있게 해준다. 예를 들어 그래프 데이터베이스에 관한 이 기사는 데이터 관리를 위한 콘텐츠 관리 시스템, 새로운 기술, 그래프 데이터를 사용할 가능성이 높은 업종, 일반적인 그래프 데이터베이스 사용 사례 또는 기술 역할의 계층 아래에 표시될 수 있다. 그러면 추천 엔진은 훨씬 더 풍부한 데이터 집합을 사용해서 콘텐츠와 사용자 관심을 연결할 수 있게 된다.
 
필자는 건설 일정 플랫폼인 그릿(Grit)을 포함해 건설 업계를 위한 기술을 판매하는 컨스트럭시브(Construxiv)의 공동 창업자인 마크 클루자와 이야기를 나눴다. 민간 건설 프로젝트 일정을 보면 여러 개의 거래와 장비, 부품, 모델에 대한 참조가 나온다. 하나의 작업 패키지에 프로젝트 계획에 종속되는 수백 개의 일이 포함되는 경우가 흔하다. 이와 같은 계획은 ERP, 건물 정보 모델링 및 기타 프로젝트 계획의 데이터를 통합해서 일정 책임자와 프로젝트 관리자, 하도급 업체에 보여줘야 한다. 클루자는 “그릿의 그래프 데이터베이스를 사용해서 누가, 언제, 어디서, 어떤 장비와 재료로 무엇을 하는지에 관해 훨씬 더 풍부한 관계를 만들 수 있다. 이를 통해 뷰를 개인 맞춤화하고 작업 일정 충돌을 더 효과적으로 예측할 수 있다”고 설명했다.
 
유연한 계층을 활용하기 위해서는 처음부터 그래프 데이터베이스를 사용해 애플리케이션을 설계하는 편이 유리하다. 그러면 애플리케이션 전체가 그래프를 쿼리하고 그래프의 노드, 관계, 레이블, 속성을 활용하도록 설계된다.
클라우드 배포 옵션으로 운영 복잡성 감소
데이터 관리 솔루션을 데이터 센터에 배포하는 일은 간단치 않다. 인프라와 운영 측면에서 보안 요구 사항을 반영하고, 성능 고려 사항을 검토해 서버와 스토리지, 네트워크의 규모를 정해야 하며 재해 복구를 위해 복제 시스템도 운영해야 한다.
 
그래프 데이터베이스를 도입해 실험 중인 기업은 현재 여러 가지 클라우드 옵션을 선택할 수 있다. 엔지니어는 GCP, AWS, 애저에 Neo4j를 배포하거나 Neo4j의 서비스형 데이터베이스인 오라(Aura)를 활용할 수 있다. 타이거그래프(TigerGraph)는 고객 360, 사기 탐지, 추천 엔진, 소셜 네트워크 분석, 공급망 분석과 같은 사용 사례를 위한 시작 키트와 클라우드 상품을 제공한다. 또한 퍼블릭 클라우드 벤더에도 AWS 넵튠(Neptune), 애저 코스모DB의 그렘린 API, 오픈 소스인 GCP 재너스그래프(JanusGraph on GCP), 또는 오라클 클라우드 데이터베이스 서비스의 그래프 기능 등 그래프 데이터베이스 기능이 있다.
 
처음의 질문으로 돌아가 보자. 여러 흥미로운 사용 사례와 시중의 성숙한 그래프 데이터베이스 플랫폼, 그래프 데이터베이스 개발을 배울 수 있는 풍부한 기회와 클라우드 배포 옵션이 제공되는 지금, 더 많은 기술 기업이 그래프 데이터베이스를 사용해야 하지 않을까? editor@itworld.co.kr 


X