작년 이맘 때 쯤이었을까?
CTO님께서 SQL만 몰랐던 내게 NoSQL에 대해서 설명해주신 적이 있었다.
그 당시에는 설명을 듣고, 뭔 말인지 모르겠으니까 나중에 꼭 써봐야겠다. 라고 생각했었다.
그리고 얼마 안가서 사이드 프로젝트를 하면서 NoSQL을 사용했었다.
그 때는 SQL이랑 별 다를께 없는데? 라고 생각했는데 지금 돌이켜보면 NoSQL스럽게 사용하지 못했던거 같다.
CTO님이 보셨으면 NoSQL을 쓰는 내 모습은 이랬지 않았을까?
그로부터 또 한참이 지난 지금 기술에 대한 시야가 조금은 넓어졌고 관련된 영상들도 찾아보면서 이번 기회에 정리해보면 재밌겠다 싶었다.
칼은 물건을 자르기 위해서, 망치는 못을 박기 위해서 만들어졌다.
칼로 못을 박을 수는 있지만 이는 전혀 용도에 맞게 사용 되고 있지 않다.
이 글도 마찬가지로 좋다 나쁘다가 아 각각의 데이터베이스들을 특징과 용도에 맞춰 설명한다.
0. 7 Database Paradigms
이번 글에서 총 7가지의 데이터베이스들을 구분하여 살펴볼 예정이다.
각각의 데이터베이스의 종류는 다음과 같다.
1.
Key-Value Database
2.
Wide Colume Database
3.
Document Database
4.
Relational Database
5.
Graph Database
6.
Search Database
7.
Multi Model Database
1. Key-Value Database
첫번째로 살펴 볼 데이터베이스는 KEY-VALUE 데이터베이스이다.
일반적으로 가장 잘 알려진 KEY-VALUE는 Redis와 Memcached가 있다.
KEY-VALUE 데이터베이스의 데이터 구조는 유니크한 Key와 그에 대응하는 Value로 이루어져 있다.
이는 Javascript의 Object나 Python의 Dictionary와 매우 유사하다.
< Redis Cli 사용 예시 >
위의 예시처럼 Key와 Value로 이루어진 한쌍의 값을 SET 명령어를 통해서 저장하고, Key값과 GET명령어를 통해 값을 가져 온다.
이러한 단순한 구조 때문에 Key-Value DB는 어떤 데이터베이스와도 다른 특별한 저장 방식을 가지고 있다.
< Key-Value DB Server 구조 >
일반적인 데이터베이스는 많은 데이터와 구조에 대한 정보를 관리하기 위해 DISK에 작성한다.
하지만 Key-Value DB는 용도 자체가 구조가 단순하고 적은 양의 데이터를 빠르게 가져오기 위해 설계 되어 있다.
이 때문에 데이터를 RAM ( In-Memory )에 저장한다.
때문에 다음과 같은 장단점을 가진다.
장점
1.
아주 빠른 속도
단점
1.
제한된 저장 공간
2.
복잡한 구조의 데이터를 처리하기 힘듬
이와 같은 이유로 다음과 같은 문제를 해결하기 위해 사용된다.
Best For
1.
Caching
2. Leaderboards
3. Pub/Sub
참고 주소 : 젤리 버튼의 레디스 도입 사례
만약 AWS와 같은 클라우드 서비스를 이용한다면 다음과 같이 DISK DB의 요청 중 일부는 ElasticCache의 In-Memory서비스를 이용하여 성능등을 개선하는 모습들을 볼 수 있다.
2. Wide-Column Database
두번째로 살펴 볼 데이터베이스는 Wide-Column 데이터베이스이다.
일반적으로 가장 잘 알려진 Wide-Column는 Cassandra와 Hbase가 있다.
Wide-Column 데이터베이스의 데이터 구조는 유니크한 Key와 하나 이상의 정렬 가능한 Columns들로 이루어져 있다.
이 때 Column들은 모델링(정해진 구조)이 없다. 이를 Schemaless 하다고 표현하는데, 이 때문에 Column은 row마다 어떤 길이나 형식으로 들어가도 상관없다.
중첩된 정렬 맵과 유사하다고 생각해도 좋을 것 같다.
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
TypeScript
< Cassandra Cli 사용 예시 >
Cassandra는 SQL과 유사한 CQL (Cassandra Query Language)라는 문법을 이용한다.
CQL을 통해서 예시처럼 정렬이나 조건처리등을 할 수 있다.
이러한 특성 때문에 Wide-Column는 다음과 같은 장단점을 가진다.
장점
1.
Schema-Less한 Table구조
2.
NoSQL이 가지는 확장성(Scale-UP)
3.
SQL보다 빠른 데이터 송수신 처리
단점
1.
Join 사용 불가로 인한 복잡한 쿼리 요청 불가능
2.
Transaction 사용 불가로 금융 거래등 ACID이 요구되는 요청 처리 이슈
3.
Schema-Less 하지 않기 때문에 예상할 수 없는 데이터의 구조
이와 같은 이유로 다음과 같은 문제를 해결하기 위해 사용된다.
Best For
1.
Time Series
2.
historical record
3.
많은 읽기와 수정보다 많은 쓰기에 특화된 문제
⇒ 결론은 로그 같은 데이터
3. Document
세번째로 살펴 볼 데이터베이스는 Document 데이터베이스이다.
일반적으로 가장 잘 알려진 Document Oriented DB는 mongoDB와 firestore, DynamoDB가 있다.
Document Oriented DB는 Document를 가지고 있다. 각각의 Document는 Key와 Value로 이루어진 비정형화된(SchemaLess한) 값을 가진다. 각각의 Document는 같은 목적을 가지는 Collection으로 Group되어진다.
Document Oriented DB는 각각의 Collection이 계층적인 관계를 가질 수 있다.
하지만 SQL과 다른 점은 Document Oriented 혹은 NoSQL DB는 비정규화(Denomalized) 되어 있기 때문에, 읽기는 빠르나 쓰기나 수정은 복잡하다.
정리하자면 Document Oriented는 다음과 같은 장단점을 가진다.
장점
1.
Schema-Less한 데이터
2.
NoSQL이 가지는 확장성(Scale-UP)
3.
SQL보다 빠른 데이터 송수신 처리 ( 읽기에 특화 )
4.
Wide-Column와 달리 Group간 Realational-ISH Query 가능
단점
1.
Join 사용 불가로 인한 복잡한 쿼리 요청 불가능
2.
Transaction 사용 불가로 금융 거래등 ACID이 요구되는 요청 처리 이슈
3.
Schema-Less 하지 않기 때문에 예상할 수 없는 데이터의 구조
4.
데이터 쓰기, 수정시 복잡함
이러한 이유 때문에 다음과 같은 산업에 선택되어진다.
Best For
Not Recommand
1.
대부분의 App
2.
Games
3.
IOT
1.
Graph
⇒ SNS
4. Relational
네번째로 살펴 볼 데이터베이스는 Relational 데이터베이스이다.
Relational DB는 현재 사용하는 Database 기술 중에 가장 오래된 역사를 지닌다. ( 오래 살아 남은 기술은 이유가 있다. )
1970년 IBM의 에드거 프랭크 테드 커드의 프로젝트 < 대규모 공유 데이터뱅크를 위한 데이터 관계형 모델 > 에 의해 SQL과 함께
개발되었다. SQL(Structured Query Language)는 JSX(React의 문법)와 같은 Declarative한 언어이다. 이 때문에 가독성, 재사용성, 오류 복구등과 같은 Declarative한 언어의 장점을 가졌다.
일반적으로 가장 잘 알려진 RelationalDB는 MySQL과 PostgreSQL이 있다.
RelationalDB는 여러개의 Column과 각각의 Row들로 이루어져 있다. ( 엑셀처럼 말이다. )
이 때, 각각의 Row들을 대표할 Primary Key를 가지는 Column이 필수 적이다. 이들은 하나의 Table로 Group되어진다.
또 각각의 Table들은 Key들을 이용하여 다른 Table과 합칠 수 있다.
Relational DB는 SQL(Structured Query Language)이라는 언어를 지원한다.
SQL과 CQL의 가장 큰 차이점은 Join 을 통하여 하나 이상의 테이블을 합쳐서 조회할 수 있다는 점이다.
이러한 특징 때문에 Relational DB는 관심사를 Table별로 분리하여 관리한다.
좌측은 비행기를 만드는 테이블을 예시로 들었다.
각각의 비행기는 하나의 프로펠러와 엔진이 필요하다.
이 때 NoSQL과 다르게 비행기에 엔진과 프로펠러의
값을 모두 작성하지 않는다.
프로펠러와 엔진은 유니크한 ID(Primary Key)를 가지는 키를 가지고, 이를 비행기는 Foreign Key ( 왜래키 )만을 통해서 프로펠러와 엔진의 테이블과 연결해서 조회할 수 있다.
뿐만 아니라 SQL은 NoSQL과 달리, Schema Required하다. 각각의 테이블에 어떤 타입의 값이 어떤 식으로 들어갈 수 있는지 모델링되어 있기 때문에 값의 안정성을 보장 받을 수 있다. ( Schema Required 하다 )
또한 높은 수준의 트랜잭션을 지원하고, 이런 특징 때문에 ACID와 같은 개념들이 중요하게 여겨진다.
정리하자면 Relational DB는 다음과 같은 장단점을 가진다.
장점
1.
Schema Required한 정형화 된 데이터
2.
Join 사용을 통한 Graph한 복잡한 쿼리 요청
3.
높은 수준의 트랜잭션 지원 때문에 데이터의 안전성 보장
4.
Declarative한 언어인 SQL의 지원
단점
1.
NoSQL보다 읽기 속도가 느린 편
2.
복잡한 데이터 구조화 데이터의 제약사항
3.
확장성(Scale-up)이 낮음. ( 매우 복잡한 편 )
이러한 이유 때문에 다음과 같은 산업에 선택되어진다.
Best For
1.
대부분의 App
2.
금융 등 데이터의 안전성이 최우선시 되는 기관
3.
SNS와 같은 복잡한 관계의 데이터 Graph를 가지는 서비스
Not Recommand
1.
로그 수집 등 복잡하지 않거나 비정형화, 구조적이지 않아도 괜찮은 데이터
2.
빠른 속도의 읽기가 중요한 서비스
3.
빅데이터등 확장성이 중요한 서비스
5. Graph
다섯 번째로 살펴 볼 데이터베이스는 Graph 데이터베이스이다.
Graph Database는 Join 사용할 수 없는 기존의 NoSQL에게 Node와 Edge라는 개념을 통해 문제를 해결했다.
각각의 노드(Node)들은 값인 Properties를 가지고 있다. 그리고 노드들은 간선(Edge)을 통해서 Node사이의 Relationship을 연결 할 수 있다.
그리고 Node들은 Label이라는 단위로 Group되어 진다.
이 때문에 Join을 하는 과정 역시 Relational Database와 차별점을 가진다.
RDB에서는 many-to-many Join시에 두 테이블을 연결할 Mapping 테이블이 필요하다.
하지만 Graph DB에서는 별도의 Key를 통해 Relationship을 가지는 것이 아니라 별도의 Edge를 이용하기 때문에, 이러한 Mapping 테이블이 필요없다.
Graph DB는 Cyper라는 언어를 지원한다.
이는 SQL과 같이 Declarative한 언어이다.
Cypher is ASCII art 라는 컨셉으로 언어가 마치 하나의 그림처럼 표현되어 비 개발자들도 이해하기 쉽게 디자인되었다.
우측의 예시는 Person이 속한 Deperture를 Join하는 질의문이다.
MATCH (p:Person)-[:WORKS_AT] -> (d:Dept)
//매칭한다 (사람을) - [:어디에 다니는지] -> (회사의)
Bash
Graph DB의 이러한 특징을 통해 다음과 같은 장단점을 예상할 수 있다.
장점
1.
SQL의 장점과 NoSQL의 장점을 섞음.
단점
1.
아직 검증되지 않는 사례, 활성화되지 않은 커뮤니티
추천 사용사례는 다음과 같다.
Best For
1.
Graphs
2. Knowledge graphs
3. Recommendation engines
6. Search
여섯 번째로 살펴 볼 데이터베이스는 Search 데이터베이스이다.
Full Text Search DB 라고도 부르는데 이는 문자열 검색에 강점을 가지는 특징 때문인거 같다.
대표적인 Search DB는 ElasticSearch, Solr, Algolia, Meilisearch가 있다.
데이터 구조는 각각의 Document(Row)에 데이터를 Field(Column)에 맞춰 저장한다.
이러한 Document는 Type( Table 수준 )으로 Group 되어지고 Type들은 Index( Database수준 )의 개념으로 다시 Group되어 진다.
많은 데이터를 처리하는 만큼 Partition에 대한 개념도 중요시한다. ElasticSearch에서는 Shard로 표현한다.
이러한 Search 에 강점을 가질 수 있는 이유는 Inverted Index( 역방향 인덱스 ) 라는 개념이다.
마치 책의 부록 처럼, 단어들이 어떤 페이지에 존재하는지 인덱싱을 만들어 준다.
이러한 방식은 우리가 책을 모두 살펴보지 않아도, 원하는 Keyword가 어느 페이지에 설명되고 있는지 곧바로 찾을 수 있게 된다.
이러한 특징을 통해 다음과 같은 장단점을 얻는다.
장점
1.
대량의 비정형 데이터 보관 및 검색 가능
2.
전문 검색(Full-text Search)에 뛰어남
3.
SchemaLess
4.
멀티 테넌시(Multi-tenancy)
5.
확장성과 가용성이 뛰어남등 NoSQL의 장점들
단점
1.
Transaction, Rollback등의 기능 지원을 안함.
2.
실시간(Real Time)의 색인된 데이터가 내부적으로 커밋(Commit)과 플러시(Flush)와 같은 과정을 거쳐야 하기 때문.
3.
데이터를 업데이트 할 수 없음. 이 때문에 데이터 업데이트는 삭제 및 생성을 통해 해야해서 그에 대한 비용이 발생함
추천 사용사례는 다음과 같다.
Best For
1.
검색 엔진
2. Typeahead(자동 검색 완성)
3. 로그 분석
7. MULTI-MODEL
마지막으로 살펴 볼 Database는 Multi-Model 데이터베이스다.
Multi-Model DB는 클라이언트-서버리스 애플리케이션을위한 데이터 API라고 소개한다.
GraphQL을 통하여 web-native interface를 지원하는 부분을 보면 느낄 수 있는데, 마치 데이터베이스가 Web Interface와 하나가 된 느낌을 받았다.
이는 웹 개발자에게 더 빠르고 쉽게 데이터를 조회하는 API를 제공할 수 있다.
데이터 구조 자체는 NoSQL의 Document 데이터 구조와 유사하다. 또한 GraphQL API를 통해 Relational한 관계를 지원한다.
DashBoard를 보면 GraphQL을 언어로써 지원하는 것을 볼 수 있다.
데이터들은 Collections에 저장되는 등 NoSQL과 유사하다.
장점
1.
NoSQL이 가지는 장점
2.
GraphQL로 데이터 간의 Graph 처리
3.
Persistence Layer와 Network Layer가 하나의 서비스가 되면서 쉽고 빠르게 API를 만들 수 있다.
단점
1.
아직 검증되지 않는 사례, 활성화되지 않은 커뮤니티 ( 국내 사례는 거희 전무 )
이 외에도 FaunaDB에서는 많은 장점들을 나열하고 있다. 또한 점차 Graph API가 트렌드가 되어가는 시점에서 GraphQL을 지원하는 모습 역시 기대가 된다.
이 때문에 미래엔 대부분의 많은 어플리케이션에게 가장 좋은 솔루션이 될 수도 있을 수도 있다.
하지만 아직 검증된 사례가 너무 없기 때문에 현재는 일반적인 경우에는 사용하기엔 하기 쉽지 않다.
마치며
7 가지 데이터베이스들을 살펴보았다.
각각의 데이터베이스들은 비교 불가능한 그들만의 패러다임을 가지고 있었음을 확인 할 수 있었다.
또한 어떤 데이터베이스는 아주 뛰어나 보이지만 검증되지 않았고, 어떤 데이터베이스는 속도등의 측면에 아쉬운 부분이 있지만 오랜 기간동안 사용됬기 때문에 믿고 사용할 수 있음을 확인했다.
이처럼 기술의 탄생은 그 때의 상황과 해결해야할 문제가 다 달랐기 때문에
좋다 나쁘다로 비교하기 보다는 기술이 추구하는 가치를 이해하고 그에 맞게 사용하는게 중요하다.