NoSQL 유형 별 개념 및 특성 정리/ MongoDB 선정 이유와 후기

 

 

개요

작년 말 조직개편으로 다른 분이 진행하던 프로젝트를 떠맡게 되었다ㅠㅠ
우리 회사 빌링시스템의 여러 모듈은 Oracle 공통 DB를 바라보고 있는데,
여기에서 일부 업무를 분리하여 MongoDB로 전환하는 프로젝트이다.
안정적으로 운영하고 있는 Oracle에서 MongoDB로 전환하는 것에 대한 윗분들의 걱정이 크셔서
윗분들을 설득하기 위해(내가 제안한게 아니라서 나도 설득 필요 ㅠㅠ) RDB부터 NoSQL까지 데이터베이스 유형별 비교가 필요하여 정리한다.
주요 내용은 "7 데이터베이스, 에릭 레드몬드, 짐 R. 윌슨"을 참조하였다.
일단 내가 맡은 프로젝트는 대략 아래와 같은 특성과 목표를 가지고 있다.

1. 공통 DB(Oracle)의 다양한 테이블을 조인하여 MongoDB에 한 개의 Collection으로 Write 하는 배치작업(기존 Oracle에서 하던 작업을 MongoDB로 이관하여 부하를 분산하고 처리 성능을 올리고자 함)
2. 이 Collection은 다른 Colleciton과 조인이 거의 필요 없다.(아주 없진 않다)
3. 고객 레벨의 Document안에 총 44종의 Document가 중첩되는 구조로 만들어진다.
   • 총 44종의 Document는 향후 비즈니스 변화에 따라 Document 추가되거나 변경될 수 있음.(있다고 믿음)
   • 각 Document는 다른 형식을 가지고 있지만, 같은 Document에 대해서는 고객별로 차이가 있지 않다.
   • 새로운 Document 형식을 추가할 여지가 있다.
4. 해당 Collection은 이후 MongoDB 안에서 조회하여 또 다른 Collection을 생성해야 하므로 조회 성능도 포기할 순 없다.(멀티 인덱스 필요함)
5. 대량의 배치작업이므로 가용성은 크게 중요하지 않다. 장애 발생 시 복구가 오래 걸리면 다 밀어버리고 새로 작업하는 게 빠를 수 있다.
6. 매월 반복되는 배치작업으로 필요한 데이터를 사용한 후에는 삭제해도 무방하다.(그래서 데이터가 지속적으로 크게 늘어나지는 않아서 scale-out은 당장의 요건은 아니다.)
   
   

데이터베이스의 유형

그럼 이제 부터 다양한 데이터베이스 유형을 알아보기로 하자

1. 관계형(RDBMS)

• 특징
  • 설명이 필요한가??
  • 행(row)과 열(column)으로 구성된 2차원 테이블로 구현된다.
  • SQL로 쿼리를 작성하여 사용한다.
  • 숫자, 문자, 날짜 등 데이터는 정해진 타입에 맞춰 처리한다.
  • RDBMS에서는 테이블의 Join으로 더 복잡한 테이블 또는 View를 만들 수 있다.
  • 트랜잭션은 *ACID를 준수한다.
    • *ACID(Atomic(원자성), Consistent(일관성), Isolated(독립성), Durable(지속성) 
    • 서버에 장애가 발생하더라도 Commit 된 트랜잭션은 안전하며, Commit 되지 않은 트랜잭션은 Rollback 하여 데이터 간 Relation이 깨지는 것을 막을 수 있다.
  • 저장 프로시저, 트리거, 뷰 등 사용 가능하다
  • like문이나 정규식을 통해 텍스트 검색이 가능하다 (한글도)
  • 스키마의 설계가 필요하지만, 데이터를 사용하는 방법에 대해서는 다른 DBMS보다 훨씬 뛰어나다
  • Oracle, MySQL, PostgreSQL
• 장점
  • 모든 컴퓨팅 분야에 걸친 장기간의 연구와 사례
  • 조인, 필터, 뷰, 인덱스를 사용하는 유연한 쿼리 능력
  • 일관성과 지속성이 있는 데이터 보장
• 단점
  • Scale-up(하나의 서버 머신을 더욱 고성능으로 확장함)이 아닌 Scale-out(횡적으로 여러 개의 분산처리 서버 머신과 데이터 스토어를 늘려서 전체적인 성능을 확장)이 필요한 경우에는 적합하지 않다.
    • 관계형 DB는 RAC구조에서 Read는 분산이 되지만 Write는 분산이 어렵다.
  • 데이터 요구사항이 너무 융통성이 강해서 엄격한 스키마 요구사항에 맞출 수 없는 경우에는 적합하지 않다
  • 데이터가 증가할수록 스키마 변경 시 부담이 늘어난다.(MySQL의 경우 Alter 실행될 때마다 table rebuild가 필요하며, 스키마 변경 테이블만큼의 공간이 추가로 필요. 단, Oracle은 이런 문제가 없다.)
  • 대용량의 BLOB(Binary Large Object, 미디어 데이터 , 정제되지 않은 대량의 텍스트 등) 데이터를 필요로 하는 경우에 적합하지 않다.

2. Key-Value 스토어

• 키와 값을 한쌍으로 저장하는 형식
• 저장된 키를 순환 처리하는 방법을 제공하기도 한다.
• 자체적으로 필요로 하는 자원이 거의 없어서 성능면에서 매우 우수하다
• 복잡한 쿼리나 집합 연산이 필요한 경우 도움이 안 된다.
• Voldmort, Redis, Riak 등

3. 칼럼형(Columnar)

• 2차원 테이블의 열(칼럼)을 중심으로 데이터가 저장되도록 설계가 되었다.
• (관계형은 행을 중심으로 데이터를 유지/관리)
• 칼럼형 데이터베이스에서 열의 추가는 비용이 저렴하며 행단 위로 처리된다.
• 각행은 서로 다른 열을 가지거나 아예 없을 수도 있다.
• 따라서 null값을 저장하는데 들어가는 비용 없이 테이블을 유지할 수 있다.
• cassandra는 확장성이 뛰어나며 일부 노드에 문제가 생기더라도 가용성이 보장되는 반면, 중앙에서 관리하는 서버가 별도로 존재하지 않기 때문에 데이터 정합성에 이슈가 있을 수 있다. 해당 이슈는 설정값을 통해 보완할 수 있기는 합니다. (속도 이슈 있을 수 있음)
• HBase는 마스터 노드가 별도로 있어 마스터 노드를 통해 데이터 정합성을 보장하고 있다.
• Cassandra는 CQL이라는 쿼리문을 사용하는데, SQL과 유사하여 사용이 편리
• Cassandra, HBase, Hypertable 등

4. 문서형(Document)

• 문서란 어떤 다양한 타입도 될 수 있는 고유한 id필드와 값들로 이루어진 해시이다.
• 문서는 중첩 구조를 포함할 수 있으므로 가변적인 도메인을 허용하는 고수준의 유연성을 보여준다.
• 문서형 데이터베이스는 입력 데이터에 대한 제약이 거의 없다. (단 이미 만들어진 스키마에서 변경/삭제는 RDB와 마찬가지로 어렵다)
• MongoDB, CouchDB 등
• 장점
  • 확장성/유연성
  • RDB대비 빠른 성능
• 단점
  • Index 생성이 매우 오래 걸린다. (Oracle은 parallel로 빠르게 처리 가능)
  • 파티션이 없으므로 파티션 별 drop 등의 작업을 할 수 없다.
  • delete 시 용량 회수가 안되어 계속 장비가 추가되어야 한다.
  • MongoDB는 MQL이라는 언어를 사용하는 데 매우 생소함

5. 그래프형(Graph)

• 노드와 노드 간의 관계로 구성된다.
• 상호 연관된 데이터의 처리에 뛰어나다
• 노드의 관계를 따라서 각 노드를 순회 처리하는 것이 가능하다
• Neo4 j 등

6. 폴리그랏 퍼시스턴스(Polyglot Persistence)

• 여러 유형의 데이터베이스를 함께 사용하는 것
  
  

MongoDB 선정 사례

다음은 MongoDB 선정 사례를 알아보았다.

1. FLO

www.blog-dreamus.com/post/flo-tech-mongodb-%EB%8F%84%EC%9E%85%EA%B8%B0

MongoDB - 도입기

2. LINE

www.bloter.net/archives/355753

라인은 왜 몽고DB를 도입했을까

 

MongoDB vs Oracle

여러 가지 NoSQL DBMS의 특징을 살펴보았지만, 우리 프로젝트는 MongoDB를 선정했다.
Redis는 In-Memory DB로 데이터 유실 가능성이 있다는 것이 가장 큰 약점이었고,
Cassandra는 조회 성능을 포기할 수 없는 프로젝트 특성상 multi-index가 안되어서 제외했다.
(구글 검색해보면 된다는 얘기도 있긴 한데..)

Neo4j 같은 GraphDB는 업무 특성에 맞지 않다고 보았다.
다들 장단점이 있지만, MongoDB가 다양한 기능을 제공하고 있어서 RDB를 대체할 가능성이 높아 보였다.
(다른 NoSQL보다 개발 중에 "오라클은 되는데 이거는 안돼요..ㅠㅠ" 이런 상황이 덜 발생할 것 같았다)

그래서 MongoDB를 선정했고, 기존 시스템에서 사용하던 Oracle과 비교를 하였다.

단, 직접적으로 어느 것이 낫다는 식의 비교는 어렵다.
Oracle에서 제공하고, 업무적으로 필수적인 기능이 보장되는지가 중요하고, 설사 기능이 Oracle보다 떨어지거나 기능이 보장되지 않아도 업무적으로 극복이 가능한지가 중요하다.

	MongoDB	Oracle(RDBMS)
다중인덱스	가능(NoSQL 계열에서는 가장 뛰어나다	가능
Read/Write 성능	빠르다. 특히 Insert에 특화되어 있다.	파티션/인덱스 등을 잘 활용하면 준수하다
*CAP	CP(scale-out은 당장의 니즈는 아니다.) ★업무 특성상 Availability도 아주 중요하지는 않다. (여차하면 재작업 하면 됨)	CA
트랜잭션 보장	*BASE ★그런데, MongoDB 4.0부터 ACID도 보장한다고 한다.	ACID(기본)
빅데이터	가능하지만, 당장 우리시스템에 필요하지 않다.	수억건 정도까지는 가능하니.. 정말 빅데이터가 아니면 데이터용량 때문에 Oracle을 쓸 필요는 없다.
확장성	schemaless 향후 확장성을 고려할 때 필요하지만.. 정말로 그렇게 확장할 일이 있을까?	schema 확장성이 없긴 하지만, 수십년간 쌓인 노하우로 매우 잘 짜여진 스키마를 가지고 있다.
비용	Community 버전은 무료이지만, Enterprise버전은 Oracle보다 비쌈 ★운영이 안정화 되는 것을 보고 Community버전으로 전환 검토	비싸기로 유명
회사의 역량	약 1년간 교육 중	수십년의 운영경험
디스크 용량	RDBMS 대비 30% 정도의 절감 효과가 있다고 함 그러나 Delete 시에 용량 회수가 안되고 지속적으로 Scaleout이 필요함 ★우리는 update가 발생하는 일은 거의 없으며, 매달 Collection을 삭제하고 새로 생성하므로 이 부분 영향이 적음.	업무 자체는 Document 구조가 맞아서, Null값이 차지하는 공간이 너무 크다.
백업/복구 시간	MongoDB에서 제공하는 opsmanager를 사용하는 경우 Oracle보다 약 6~7배의 시간이 더 걸리는 것으로 확인했다. ★우리 업무는 한달중 10일 정도 배치작업으로 이루어지므로 영향이 크지 않음. 작업마다 다르지만, 재작업을 하는 것이 복구보다 빠를 수 있음.	기준
트렌드	MSA나 Polygrot Persistence는 신기술이라고 부르기도 창피하다. 당장의 필요가 없더라도 IT역량 확보차원에서 진행이 필요하다.	여전히 전세계 시장의 80%이상을 차지하지만.. 어느정도의 지분은 NoSQL 진영에 내줄수 밖에 없다.

※ 2022.09.13 - [데이터베이스/데이터베이스 일반] - [Database] ACID, BASE, CAP

 

결론

- 임원: 굳이 MongoDB를 써야 하냐?
- 나: 아닙니다. 기존에도 RDB 잘 써왔는데, MongoDB를 안 쓴다고 무슨 일 안 생깁니다.
- 임원: 그런데, 왜 쓰나?
- 나: 사업부서가 매번 "아이디어를 내도 IT가 못 따라온다"는 얘기하는 거 그만 듣고 싶습니다.
그리고, MongoDB가 그렇게 안정성을 걱정할 만큼 최신 기술도 아니고요.
그냥 한번 해보고 싶습니다.

진짜 저렇게 얘기하지는 않았고, 표면적인 장단점만 이야기했지만, 진심은 저거였다.
그리고, 어차피 작년에 시작한 프로젝트를 물려받은 것이라서 지금 와서 안 할 수는 없고.. 일단 계속 진행하기로 했다.
혹시나 발생할 문제를 대비해서 여러 가지 장치도 개발하기로 했고..
제발 성공하자 ㅠㅠ

 

후기('22.9.21)

늦었지만, 후기를 작성한다. 이미 1년전 쯤 프로젝트는 문제없이 마무리가 되었다. MongoDB 측에서 적극적으로 문제 해결에 나서 준 것이 인상깊었다. 다만, 역시 지나고 나니 굳이 MongoDB를 쓸 필요가 있었나 하는 생각이 든다. 라이선스 비용도 만만치 않고, 기존에 RDMBS에서 수십년 운영해 왔기 때문에 추가적인 확장성을 요구하는 일이 지난 1년간 발생하지 않았다. 그렇다고 문제도 없었고, 안정적으로 잘 운영되고 있다.
다만, 아무래도 RDBMS에 익숙한 운영자들이 불편해 하기는 한다.