Blog · lee. ui dam

이번 글에서는 아랑고DB를 세팅하는 방법에 대해 알아보려고 한다. 로컬(본인 컴퓨터나 노트북)에서 작업해도 좋고 개발용 서버가 있다면 서버에서 해도 좋다. 나는 AWS에서 제공하는 프리티어 EC2를 사용 중이다.

1. 설치하기

설치는 매우 간단하다. 아랑고DB 공식 홈페이지에 있는 커뮤니티 버전 중, 본인 환경에 맞는 것을 설치하면 된다. 여기서는 Ubuntu 버전을 설치한다.

// 아래 curl 명령어가 오류난다면 권한 문제일 경우가 많다. sudo를 붙이거나 폴더의 권한을 바꿔주자.
curl -OL https://download.arangodb.com/arangodb38/DEBIAN/Release.key
sudo apt-key add - < Release.key
                                
echo 'deb https://download.arangodb.com/arangodb38/DEBIAN/ /' | sudo tee /etc/apt/sources.list.d/arangodb.list
sudo apt-get install apt-transport-https
sudo apt-get update
                                
// 약 300mb 정도의 여유 공간이 필요하다
// 설치 화면이 나타나면, root 권한의 비밀번호를 설정하게 된다. 꼭 기억해두자.
// 자동 업데이트나 업데이트 시 백업 여부는 개발용이기 때문에 No,No로 해두었다.
sudo apt-get install arangodb3=3.8.2-1

이제 설치가 완료되었다. arangosh 명령어를 통해 라이브된 아랑고DB 쉘에 접속할 수 있고, 혹은 service arangodb3 status 명령어를 통해 서비스에 등록되어 정상 설치된 것을 확인할 수 있다.

2. 설치 경로에 관한 이야기

우분투에서 프로그램이 설치되는 경우, 주로 찾아보는 경로를 잠깐 정리해보자면, 아래와 같다. 이 경로들은 대부분 다른 프로그램들에서도 공통으로 쓰이며, 대개 /etc 경로의 해당 config 파일을 열어보면 자세한 설정들이 나와있다.

/etc/arangodb3/ : 각종 설정 파일이 저장된 공간
/var/lib/arangodb3 : 아랑고DB의 파일들이 저장되는 곳
/var/log/arangodb3 : 아랑고DB의 로그가 쌓이는 곳

3. 설정 파일과 Web UI 세팅하기

이제 아랑고DB의 설정 파일을 한 번 살펴보자.

cd /etc/arangodb3
sudo vim arangod.conf

여기서 server 항목을 살펴보면, endpoint가 tcp:127.0.0.1:8529로 설정된 것을 볼 수 있다. 실제로 아랑고DB의 Web UI에 접속하려면 브라우저에 본인의 서버 주소에 8529 포트를 붙여 접속할 수 있다. 예를 들어, EC2를 쓰는 내 경우 ec2-x-x-x-x.ap-northeast-2.compute.amazonaws.com:8529로 붙을 수 있다.

하지만 이때 접속이 되지 않는다면, 1) endpoint를 0.0.0.0:8529로 변경해본다. 이에 관한 자세한 내용은 여기를 읽어보기 2) 그래도 안 된다면 본인 서버의 보안을 확인한다. (EC2의 경우 보안그룹의 inbound traffic이 내 주소에 열려있는지..) 3) 그래도 안 된다면 아랑고DB의 가이드를 살펴본다.

위 과정을 거쳐서 다시 브라우저로 접속해보면 아랑고 Web UI가 설치된 것을 확인할 수 있다! 아랑고DB의 강력하고 편리한 기능이기 때문에 얼굴을 기억해두자.

초기 세팅했던 root 계정과 비밀번호로 접속하면 _system 데이터베이스로 접속할 수 있다. _system db는 다른 데이터베이스를 생성하고, 시스템 관련 설정을 할 수 있는 기본 데이터베이스라고 보면 된다.

4. 어디까지 왔나

다음 글에서는 아랑고DB의 데이터 구조에 대해 간단하게 알아보고, 아랑고 쉘에서 명령어를 통해 여러가지 CRUD 작업을 해서 실체를 익혀보려고 한다.

아랑고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를 써야한다고 본다.

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

3. Performance

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

4. 앞으로의 계획

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

<아랑고DB> 2. 아랑고DB 세팅하기 on Ubuntu