시작하며
저번 편에서는 Key-Value DB와 Document DB를 정리해봤고 이번 편에서는 Column Family DB와 GraphDB에 대해 정리해보려한다.
Column Family DB나 GraphDB는 실제로 사용해본 적이 한 번도 없어서 어떤 녀석들인지 자세히는 모르지만 책 내용 위주로 정리해보도록 하겠다.
Column-Family DB
Column-Family DB는 한 Row에 무수히 많은 Column을 Schema가 강제되지 않은 형태로 이용할 수 있는 NoSQL의 한 종류이다. Wide column DB, Wide column store, Columnar DB 등의 다른 다양한 명칭들도 존재는 하지만 책에서는 좀 더 여러 컬럼을 묶어서 생각할 수 있는 점이 강조되는 Colum-Family DB라는 용어를 이용했다고 한다.
Column-Family DB는 다른 일반적인 NoSQL과 관계형 데이터베이스의 사이의 그 무언가 같은 느낌인데 이는 NoSQL임에도 관계형 데이터베이스와 비슷한 몇 가지 특징들이 있기 때문이다.
- SQL과 유사한 쿼리 언어를 제공하기도 한다.
- Row와 Column 등의 개념이 존재한다.
그 외의 특징은 다음과 같다.
- 자주 함께 사용되는 Column들을 묶어 Column family로 이용할 수 있다.
- Column family는 약간 RDB에서의 하나의 Table 같은 느낌으로 볼 수도 있다.
- 개인적으로는 Column family DB에서 하나의 Row에 해당하는 데이터들은 이미 JOIN이 수행된 데이터들의 모임 같다.
- 사실 2차원적인 테이블이 아닌 중첩된 맵 구조이다.
SortedMap<Row Key, SortedMap<Column Key, Column Value>>같은 느낌으로 볼 수 있다.
- 단일 Row에 대한 전체 데이터들은 디스크에 저장될 때 서로 인접하지 않을 수도 있다.
- 하지만 하나의 Column-Family에 대한 데이터들은 인접해서 저장된다.
- Schema가 강제되진 않음.
- JOIN을 지원하지 않는 것 같다.
- 엄청나게 많은 데이터, 높은 확장성, 높은 가용성에 특화된 듯하다.
- 컬럼값들의 버전 관리가 가능하다.
확장과 가용성에 특화된 DB이다보니 마스터가 SPOF (단일 실패 지점)이 될 수 있는 형태를 지양한 듯하고, Column-Family DB는 P2P 형태로 어느 누구 하나가 마스터이지 않고 평등하다.
따라서 클러스터 내 서버들의 상태 공유, 데이터 최신화 및 복제 등 기존에 마스터가 수행하던 작업을 동료 Node들끼리 알아서 수행해야하고 그를 위한 커뮤니케이션이 필요한데 이때 동료 Node들이 많아질 수록 커뮤니케이션이 기하급수적으로 늘어날 수 있다. 이런 커뮤니케이션을 효율적으로 하기 위한 프로토콜들도 생겨나게 됐다. 간략히만 정리해보자면 그 중 하나가 “가십 프로토콜”이며, “각 노드가 다른 모든 노드들의 상태를 직접 체크하는 게 아니라 각자가 몇 몇 노드의 상태를 직접 체크하고 나머지 노드의 상태는 서로 주고 받은 정보를 참고한다” 정도로 정리해볼 수 있을 것 같다.
Column-Family DB는 주로 빅데이터 분야에서 많이 쓰이는 것 같고, 빅데이터를 다룰 때에는 다음과 같은 작업들이 필요하다.
ETL(Extract, Transfrom, Load) - 데이터의 추출, 적절한 형태로 가공, 적재- 데이터 분석
- DB 성능 모니터링
Column-Family DB는 위와 같은 기능들을 잘 제공하고 있다. 반면 주로 제품(비즈니스) 로직을 위한 데이터 저장은 관계형 데이터베이스, Key-Value DB, 문서 DB를 많이 이용하는 것 같기는 하다.
하지만 간단히 정리하려다가 다시 궁금증이 생겨서 자료를 좀 찾아보던 중 컬럼 패밀리를 제품 로직에서 사용하는 케이스에 관해 eBay의 상품 좋아요 기능을 Cassandra를 기준으로 데이터 모델링하는 것 관련 좋은 글을 발견하게 되어 이 글을 참고해보면 좋을 것 같다. 요약은 다음과 같다.
- 요구되는 조회 패턴을 근거로 올바른 수준의 비정규화를 하는 것이 중요하다.
- 너무 정규화 되어있으면 필요한 정보를 찾기 위해 한 번 더 조회가 필요할 수 있고 비효율적이다.
- 너무 비정규화 되어있으면 불필요하게 수많은 데이터가 중복되게 되고, 수정 사항 반영이 쉽지 않을 수 있다.
Graph DB
GraphDB는 로우, 컬럼 등을 바탕으로 데이터를 모델링하는 대신에 노드(혹은 정점, Vertex)와 관계(Relation 혹은 Edge)를 통해 데이터를 모델링한다. 이때 Edge는 방향이 있을 수도 있고, 없을 수도 있다.
서로 많은 관계를 맺는 케이스에 사용하기 좋은 듯한데, 예를 들면 SNS의 유저 간의 친밀도, 네트워크에서 도시 간의 소요 시간 등을 나타내기 좋다.
Graph DB에서 모델링할 수 있는 그래프와 그 예시는 다음과 같다.
- 방향 그래프 - 조직 구성원의 상하 관계
- 무방향 그래프 - 조직 구성원의 협력 관계
- 유동 네트워크 (Flow network) - 도로 시스템, 교통 네트워크. (잘 모르겠습니다.)
- 이분 그래프 - 각 연결 관계들을 따라 가면 두 개의 집합으로 번갈아 표현되는 그래프
- e.g. 유저 - 게시글의 좋아요 관계
- 유저 - 게시글 - 유저 - 게시글 - …
- e.g. 선생님과 학생의 관계
- 선생님 - 학생 - 선생님 - 학생 - …
- e.g. 유저 - 게시글의 좋아요 관계
- 다중 그래프 - vertex ↔ vertex 간에 여러 edge가 존재할 수 있는 경우
- e.g. 네비게이션
- 가중 그래프 - edge에 가중치가 존재하는 경우
- e.g. 최단 경로 찾기
그래프 DB를 언제 사용할 수 있을까?
항상 어떤 DB를 사용할 지, 어떻게 모델링할지는 사용하려는 패턴, 특히 조회 패턴에 근거해서 고려되어야한다.
예를 들어 다음과 같은 조회 패턴을 가진 경우 그래프 DB를 사용하면 좋다.
- 정점 A에서 정점 B로 가는 엣지는 몇 개인가?
- 정점 A에서 정점 B로 가는 엣지 중 비용이 100 미만인 엣지는 몇 개인가?
- 정점 A에서 정점 B로 가는 가장 효율적인 경로는 무엇인가?
좀 더 실생활과 밀접한 예시는 다음과 같다.
- 유저 A와 친밀도가 높은 유저들은 누구인가?
- 유저 A와 유저 B가 함께 아는 친구가 존재하는가?
- 지역 A에서 지역 B까지 이동할 수 있는 경로가 존재하는가?
이렇게 특정 엔티티를 기준으로 해당 엔티티와 엔티티와 다른 엔티티들의 연결 관계를 바탕으로 조회를 하는 경우 그래프 DB를 사용하면 좋다.
반면, 다음과 같이 엔티티나 테이블 전체에 걸친 질의는 적합하지 않다.
- 오늘 받은 좋아요가 가장 많은 게시글은 어떤 게 있는가?
- 가장 연결된 경로가 많은 지역은 어디인가?
실제로는 Graph DB를 이용하는 유즈케이스는 다음과 같은 운송 회사가 있을 수 있다.
“제한 시간 내에 운송 가능한 최소 비용 경로를 찾기”
- 운송 소요 시간을 가중치로 한 출발 시설 ↔ 도착 시설 간의 연결 관계가 존재
- 경로를 거쳐가던 중 제한 시간을 초과하게 되면 그 경로는 제외됨.
- 그 외의 가능한 경로 중 가장 저렴한 경로를 채택!
참고해보면 좋을 것 같은 링크
- 카산드라 데이터 모델링 part.2 - eBay의 좋아요 모델링 - http://hochul.net/blog/cassandra-data-modeling-best-practices-part-1/
- Data modeling 관련 카산드라 문서 - https://cassandra.apache.org/doc/latest/cassandra/data_modeling/index.html
- 시간 나면 읽어보면 좋을 것 같다.
마치며
간단하게 Column-Family DB와 Graph DB에 대해 정리해봤다. 책 내용 외에도 위에 첨부한 eBay의 Cassandra 모델링 이야기가 꽤 재미있고, 평소 궁금했던 내용을 잘 알려준 것 같다. 책을 읽으면서 알게 됐지만 무심코 지나친 내용들이나 까먹은 내용들이 꽤 있었던 것 같은데 리뷰를 기회 삼아 한 번씩 다시 되돌아 볼 수 있는 것 같다.
다음 책도 리뷰해보면 좋을 것 같다!
이걸로 2022년 첫 책 리뷰 끝~!