이번에 개발팀에 서비스를 사용하는 사용자들에게 이벤트 알림과 다음 단계를 유도하는 SMS 전송 자동화 작업을 해달라는 요청이 들어왔다. 현재 우리가 사용하는 DB는 RDBMS MySQL인데 해당 작업을 위해 기존의 RDBMS와 아니면 NoSQL 중에 어떤 DB를 사용하는 게 좋을지 비교해보고 정하기로 해서 내가 리서치를 담당하게 되었다.
NoSQL이란?
NoSQL은 not only SQL의 약자이며 오라클에서는 다음과 같이 정의한다.
NoSQL이라는 용어는 비관계형 데이터베이스 유형을 가리키며 이 데이터베이스는 관계형 테이블과는 다른 형식으로 데이터를 저장합니다.
NoSQL은 간단히 말해 비 관계형 데이터베이스로 스키마를 사전에 정의하지 않고 사용할 수 있어서 확장성과 유연성이 뛰어난 이점이 있다고 한다.
반대로 SQL은 관계형 데이터베이스로 스키마를 사전에 정의하고 사용해야 하기 때문에 데이터의 명확한 데이터 구조를 보장하며 일관성을 유지하는데 좋다고 한다.
NoSQL 종류
1. Key-Value
- Key-Value의 단순한 구조로 구성되어 있다. 그렇다 보니 수평저 확장이 용이하다. 예를 들면 value 값으로 어떠한 형태의 데이터도 가능한데 이미지나 오디오 파일까지 가능하다.
- 간단한 API만을 제공하기 때문에 조작이 쉽고 질의의 속도가 빠른 편이라고 한다.
- 단점으로는 Value 값에 대한 쿼리가 불가능해서 value 값을 모두 불러온 다음 따로 코드 처리를 해주어야 하는 단점이 있다.
- 언제 사용하는 게 좋을까?
1. 성능 향상을 위해 관계형 데이터베이스에서 데이터 캐싱
2. 장바구니 같은 웹 애플리케이션에서 일시적인 속성 추적
3. 모바일 애플리케이션용 사용자 데이터 정보와 구성 정보 저장
4. 이미지나 오디오 파일 같은 대용량 객체 저장 - Examples: Memcached, Riak, Redis, Amazon Dynamo DB, LevelDB, Oracle Berkely
2. Document
- Document는 Key-Value 모델에서 확장적인 개념으로 Value를 계층적인 형태인 Document로 저장한다고 한다.
- 그래서 장점으로 생산성과 유연성이 좋고 필드에 쿼리가 가능하다는 장점이 있다.
- 단점으로는 사용이 번거롭고 쿼리를 사용할 수는 있으나 보편적으로 사용되는 SQL과 다르기 때문에 익숙해지는데 시간이 걸린다는 단점이 있다.
- 언제 사용하는 게 좋을까?
1. 대용량 데이터를 읽고 쓰는 웹 사이트용 백엔드 지원
2. 제품처럼 다양한 속성이 있는 데이터 관리
3. 다양한 유형의 메타데이터 추적
4. JSON 데이터 구조를 사용하는 애플리케이션
5. 비 정규화된 중첩 구조의 데이터를 사용하는 애플리케이션 - Examples: MongoDB, CouchDB, MarkLogic
3. Column-Family
- 집합-지향 모델로 간주되며 특이점으로 키에서 필드를 결정한다.
- 키는 Row와 Column-family, Column-name을 가지며 Row 키는 검색 시 사용되는 기본 키이고 Column은 키-값 쌍으로 항상 Timestamp 값이 함께 저장된다고 한다.
- 대량의 데이터의 압축, 분산처리, 집계 쿼리 (SUM, COUNT, AVG 등)및 쿼리 동작 속도 그리고 확장성이 뛰어나다.
- 언제 사용하는 게 좋을까?
1. 데이터베이스에 쓰기 작업이 많은 애플리케이션
2. 지리적으로 여러 데이터 센터에 분산되어 있는 애플리케이션
3. 복제본 데이터가 단기적으로 불일치하더라도 큰 문제가 없는 애플리케이션
4. 동적 필드를 처리하는 애플리케이션
5. 수백만 테라바이트 정도의 대용량 데이터를 처리할 수 있는 애플리케이션 - Examples: HBase, Cassandra, Hypertable
4. Graph
- 개체와 관계를 그래프 형태로 표현한 관계형 모델이다.
- 데이터 간의 관계가 탐색의 키일 경우에 적합하기 때문에 각 데이터들 간의 관계를 찾는데에 특화되어 있다.
- Examples: Neo4j, BlazeGraph, OrientDB
이렇게 NoSQL의 4가지 종류를 알아봤다. 사실 글로만 이렇게 정보를 접하다 보니 100% 이해하지 못하는 부분들이 있었다. 아님 내가 이해력이 부족해서 그럴 걸 수도..
아무튼 현재까지의 리서치를 통해서 나는 Key-Value NoSQL이 문자 자동화의 작업에 적합하다고 생각했다. 그 이유는 다음과 같다.
- 우리가 사용할 Notificaiton에 테이블의 구조는 복잡하지 않고 굉장히 단순한 구조일 것으로 예상된다.
- 알람의 조건이 완료되면 테이블에서 삭제 처리되기 때문에 일시적이다.
- 다양한 속성이 존재하지 않다. 현재 우리가 구상하는 Notification Type 종류가 한정적이다는 말이다.
- JSON 데이터 구조를 사용하는 것을 염두하고 있지 않다.
- 데이터베이스에 쓰기 작업보다는 읽기의 작업이 더 많다.
이제 그러면 어떤 Key-Value NoSQL 중에 어떤 것들을 쓸지를 결정해야 하는데 이것에 도움을 받은 사이트가 있었다. https://db-engines.com/en/ranking/key-value+store 이 사이트를 들어가면 NoSQL의 순위를 알 수 있는데 Redis가 압도적인 점수로 1위를 하고 있었다. 그래서 Redis를 사용하려고 했는데 인프라팀에 NoSQL 구축 의견을 물어봤는데 DynamoDB를 전에 한번 사용하기 위해 구축한 적이 있어 바로 사용이 가능하다는 답변을 받았다. 그리고 더 알아보니 우리는 미국에서 서비를 제공하고 있기 때문에 우리 회사와 HIPPA BAA를 체결한 AWS를 사용해야 한다고 하기도 했고 비용적으로나 시간적으로나 AWS DynamoDB가 좋을 것 같다는 의견이 많아서 DynamoDB를 사용하기로 결정했다. Redis를 사용해서 저렇게 높은 점수를 받는 이유를 한번 경험해 보고 싶었는데 다음에 기회가 된다면 사용해봐야겠다. 이제 다음으로 DynamoDB를 더 자세하게 알아봐서 최대한 활용하는 방법을 공부해야겠다.
