<아랑고DB> 1. 아랑고DB 알아보기

1. 아랑고DB란? 언제 사용해야할까?

ArangoDB, 아랑고DB는 데이터베이스의 한 종류로써 Native Multi-Model Database를 표방하고 있다. 멀티 모델이란 키-값, 도큐먼트, 그래프 형태 등 다양한 모델을 지원하는 모델인데, 이를 단일 엔진에서 구현하기 때문에 native라는 표현을 썼다고 한다. 자세한 내용은 여기를 읽어보자.

그럼 왜 아랑고DB를 써야할까? 이 질문은 왜 그래프DB를 써야할까?라는 질문에 대한 답을 먼저 해야 할 것 같다.

그래프DB는 데이터를 점(Vertex)과 점을 잇는 선(Edge)으로 표현한 데이터베이스다.

• 그래프 구조로 되어있기 때문에 두 객체 사이의 관계를 표현하기에 최적화되어있다.
• 객체끼리 엣지로 연결되어 있기 때문에 여러 컬렉션에 흩뿌려진 데이터에 접근하기가 쉽다.
• 그래프를 횡단하기 위한 직관적인 그래프 명령어가 존재한다.
• 그리고 그래프 횡단을 통해 기존 RDBMS와 NoSQL 데이터베이스에서는 매우 비효율적이거나, 절대 쿼리로 만들 수 없었던 데이터들을 뽑아낼 수 있다.

그럼 그래프DB 중에서, 왜 아랑고DB인가?

• 커뮤니티 에디션에서 다중 데이터베이스를 제공한다 (Neo4J는 1개의 DB밖에 생성을 못한다… 여기 참고)
• 그래프 쿼리인 AQL이 직관적이며 간편하다
• WebUI를 제공한다
• 빠르게 그래프 개념을 익히기 좋다

그래프DB의 1등은 Neo4J이다. 하지만 커뮤니티 에디션이 단일 데이터베이스밖에 지원하지 않기 때문에 이것저것 테스트하기가 번거로웠다.

그래서 나는 그래프DB의 개념을 익히고, 재밌게 연습하기에는 아랑고DB가 최적이라고 생각한다. AQL도 상당히 직관적이기 때문에 배우는 데 진입장벽이 낮기 때문이다.

2. 아랑고DB의 사용 예시

아랑고DB는 아래와 같은 상황들에서 제 힘을 발휘한다. 공통적으로 볼 때, 여러 컬렉션을 모두 돌면서 데이터를 탐색하는 상황에서 아랑고DB는 가장 강력하다.

다른 RDBMS나 NoSQL에서 많은 테이블/컬렉션을 하나의 쿼리에 탐색하는 상황을 역으로 생각해보면 얼마나 번거롭고 비효율적인 일인지 알 수 있을 것이다.

예시 1 - 어제 방문한 유저 중, 오늘 재방문한 유저 찾기

관계형DB를 사용한다면, 아래 t1에 t2를 unique_id로 left join하여 값이 매치하는 경우 어제도 방문했다고 결론지을 수 있을 것이다.

• t1 = 오늘 방문한 유저의 unique id 목록
• t2 = 어제 방문한 유저의 unique id 목록

예시 2 - 지난 한 달간 방문한 유저 중, 오늘 재방문한 유저 찾기

그럼 여기서 더 나아가, 어제가 아닌 지난 한 달 동안 방문한 유저들을 대상으로 한다면 어떻게 될까? t2가 조회해야 하는 데이터 양은 1일 -> 30일로 30배가 늘어났다. 시간단위로 파티셔닝을 해두었다면 이는 t2 테이블을 읽는 데에만 훨씬 더 많은 시간이 소요됨을 의미한다. 보통 이렇게 되면 이전 30일치의 유저 unique_id를 따로 캐싱해두고 빠르게 꺼내는 방식을 택하는 게 나을 것이다.

예시 3 - 예시2의 유저들의 최초 유입 경로 찾기

그럼 여기서 더 깊은 분석을 한다고 가정해보자. 지난 한 달 간 방문한 적이 있는 유저 중, 오늘 재방문한 유저들이 최초로 이 웹사이트에 방문한 경로를 알고싶다. 여기서부터 머리가 복잡해지기 시작한다. t1과 t2를 join하여 타겟 유저 그룹을 분리해내는 것까지는 시간이 오래 걸릴 뿐 별 문제가 없었는데, 이제 이 타겟 유저 그룹의 개별 유저마다 최초의 유입 경로를 찾아야 한다. 마찬가지로 DB가 시간 단위로 파티셔닝 되어있다면, 도대체 조회 기간을 언제부터 산정해야할까?

이러한 종류의 쿼리들은 관계형DB에서도 구현은 가능하지만, 실제 프로덕션 수준으로 끌어오기까지는 꽤나 설계가 필요할 것이다. 나는 이러한 경우에 그래프DB를 써야한다고 본다.

1. 데이터의 출발점이 특정 인덱스/파티션에 한정(위 예시에서는, 조회하는 기간)되는게 아니고 여러 컬렉션에서 출발할 수 있고,
2. 내가 필요한 데이터 점들을 횡단(traverse)하여 원하는 값을 구성해낼 수 있고
3. 이 과정에서 필요한 점들만을 효율적으로 방문할 수 있기 때문이다.

3. Performance

아랑고DB의 성능 벤치마크는 여기서 확인할 수 있다. 사실 그래프DB에서 깊은 뎁스로 횡단을 하다보면 생각만큼 효율이 나지 않을 때도 많다. 기회가 된다면 이런 경우에 대해 어떻게 쿼리 최적화를 했는지도 공유해야겠다.

4. 앞으로의 계획

앞으로의 글들은 아래의 순서로 진행될 것 같다. 쓰고보니 많아보이지만 핵심 위주로만 슥슥 넘어가려고 한다. 블로그의 첫 개시인데, 게으름피우지 않고 부지런히 써봐야겠다!

1. (지금 보고있는 글)아랑고DB란? 왜 쓰는가?
2. 아랑고DB 세팅하기 on Ubuntu
3. 아랑고DB 쉘로 붙어서 명령어 체험해보기, 실체 파악해보기
4. AQL(Arango Query Lang) 배워보기 1
5. AQL(Arango Query Lang) 배워보기 2 - RETURN / UPDATE
6. AQL(Arango Query Lang) 배워보기 3 - REPLACE / UPSERT / REMOVE
7. 그래프 개념잡기
8. 그래프 횡단하기 Graph Traversal
9. 데이터 모으기 COLLECT / AGGREGATE / MIN_BY, MAX_BY
10. 프로젝트. 그래프를 통한 영화 추천시스템 만들어보기 1
11. 프로젝트. 그래프를 통한 영화 추천시스템 만들어보기 2 (최종편)