프로젝트 진행 중 RefershToken을 저장하기 위해 Redis를 사용하였다. 그냥 사용해봤다가 아닌 Redis에 대한 깊은 이해를 위해 정리해보고자 한다.
이후에는 프로젝트에서 어떻게 인증처리를 했는 지까지 정리해보는 것이 목표이다. 그래서 이번에는 Redis를 바로 알아보기 보단 NoSQL이 무엇인지 왜 사용하는 지에 대해 알아보고자 한다.
NoSQL란 ?
Not Only SQL의 약자로, RDBMS의 한계를 극복하기 위해 고안된 데이터베이스이다. 스키마가 없거나 느슨한 스키마(비정형 데이터)를 제공하는 것이 가장 대표적인 특징이며, 이를 통해 분산 환경에서 대량의 데이터를 처리하는 데에 최적화되어 있는 데이터베이스이다.
왜 사용하고 등장하였는가?
앞써 RDBMS의 한계를 극복하기 위해 NoSQL이 탄생했다고 했다. 그럼 RDBMS의 한계는 무엇일까?
관계형 데이터베이스는 두 가지 특징을 가지고 있다.
- 데이터는 정해진 규칙을 가진 데이터 스키마를 따라 데이터베이스 테이블에 저장된다.
- 데이터는 관계를 통하여 연결된 여러 개의 테이블에 분산된다.
해당 특징때문에 관계형 데이터베이스는 데이터 무결성을 보장하고 관계를 통해 중복없이 한번만 저장하여 하게 되며 ACID로 인한 트랜잭션 처리가 가능해진다.
하지만 이런 특징때문에 관계형 데이터베이스는 아래와 같은 한계를 가지게 된다.
- 데이터 구조를 효율적으로 설계하기 어렵다는 단점이 생긴다.
- 일관성을 보장하는 관계형 모델의 특징에 의해 수평적인 확장이 어렵다.
- 스키마에 의해 미리 정의된 데이터 타입과 일치하는 구조화된 데이터만 관리할 수 있어 비정형 데이터에 대한 관리가 어렵다.
- 관계가 증가할 수 록 쿼리의 복잡도가 높아진다.
- 대량의 데이터를 입력할 경우나 조회할 경우 성능이 저하될 수 있고 샤딩과 레플리케이션을 구축하는 비용이 많이 든다.
- 리플리케이션은 퍼포먼스를 고려해야하고 샤딩의 경우 데이터의 관계가 무너질 수 있는 부담감이 있으며 이런 경우 신뢰성이 깨지는 리스크가 발생할 수 있다.
점차 증가하는 트래픽과 데이터양에 의해 대용량 데이터 읽기/쓰기 작업, 빠른 응답 시간, 높은 가용성이 필요해졌고 이런 요구 사항은 관계형 데이터베이스의 한계때문에 실현이 어려워지기 시작했다. 또한, 관계형 데이터베이스는 성능을 향상시키기 위해서는 수직적 확장만 가능했기 때문에 비용적으로도 비싸고 한계가 있었다.
이런 문제와 한계를 해결하고자 NoSQL이 등장하게 되었다.
NoSQL은 특정 데이터 모델에 대해 특정 목적에 맞추어 구축되는 데이터베이스로서, 현대적인 애플리케이션 구축을 위한 유연한 스키마를 갖추고 있다.
NoSQL은 대량의 분산 데이터를 저장/조회하는 데 특화되어 있으며, 개발의 용이성, 기능성, 및 확장성을 인정받고 있다.
특징
확장성
변환무쌍한 작업 부하에 대한 요구 사항을 효율적으로 충족시키는 능력
필요에 따라 서버를 추가하는 스케일 아웃 작업이 가능하다.
관계형 데이터베이스에서는 단일 데이터베이스 시스템을 구동하는 여러 서버를 관리하기 위해 데이터베이스 소프트웨어가 필요하며 복잡성과 운영 비용이 증가할 수 있다.
하지만 NoSQL은 클러스트 하나에서 서버 여러개를 이용하도록 설계되었다. 즉, 새로운 서버를 추가/삭제할 때 NoSQL DBMS는 사용 가능한 새 서버를 사용하도록 조정한다.
유연성
RDBMS는 관계형 데이터 모델을 사용해 해결 가능한 문제의 범위 "내에서는" 유연한 편이다. 하지만 데이터베이스 설계자는 프로젝트를 시작할 때 애플리케이션 지원에 필요한 모든 테이블과 컬럼을 파악해야 할 뿐만 아니라 대부분의 테이블에 값이 채워져있어야 한다.
그에 반해 NoSQL 데이터베이스는 고정된 테이블 구조가 필요하지 않다. 즉, 데이터베이스 설계를 변경하지 않고도 필요한 새로운 속성을 동적으로 추가할 수 있다.
비용
주로 NoSQL 데이터베이스들은 오픈 소스 형태로 제공되기 때문에 비용을 낼 필요가 없다.
또한, 스케일 아웃이 스케일 업보다 대체적으로 비용이 낮다.
가용성
NoSQL 데이터베이스는 저렴한 비용으로 서버를 여러개 이용할 수 있도록 설계되었다.
서버 하나가 중지되거나 서비스를 일시 중지해야할 경우 클러스터 내 다른 서버가 작업량 전체를 떠맡을 수 있다.
또한, 내고장성을 가진 NoSQL은 클러스트 내에서 몇 개의 노드가 망가지더라도 정상적인 서비스가 가능하다.
몇몇 NoSQL은 가용성을 보장하기 위해 데이터 복제(레플리케이션)을 사용하기도 한다.
동일한 데이터를 다중 노드에 중복 저장하여 그 중 몇 대의 노드가 고장나도 데이터가 유실되지 않도록 하며 아래와 같은 복제 방법이 있다.
- Master - Slave 복제 방법 : 동일한 데이터를 가진 저장소를 하나 더 생성
- Peer - to - Peer 복제 방법 : 데이터 단위로 중복 저장
고성능
특정 데이터 모델 및 액세스 패턴에 대해 최적화되어 있기 때문에 대용량 데이터를 처리하는 성능이 뛰어나다.
또한 조인이 필요없기 때문에 관계형 데이터베이스보다 빠르다.
일관성
NoSQL을 사용한다면 데이터의 일관성이 느슨하게 처리되어 동일한 데이터가 나타나지 않을 수 있따.
여기서 느슨하게 처리된다는 것은 데이터의 변경을 시간의 흐름에 따라 여러 노드에 전파하는 것을 말한다.
이러한 방법을 최종적으로 일관성을 유지된다고 하여 최종 일관성 또는 궁극적 일관성을 지원한다고 한다.
정리하자면, ACID 대신 Eventual Consistency를 허용한다.
- ACID : SQL의 모든 트랜잭션이 만족해야 하는 특징
- Eventual Consistency : 실제 최신은 아니더라도 업데이트 전까지는 최신 데이터를 반환하겠다는 특징
NoSQL의 데이터 모델 분류
NoSQL의 또 다른 특징이자 장점은 다양한 데이터 모델을 제공한다는 점이다.
이 때문에 도메인의 요구 사항에 걸맞는 데이터 모델을 고르고 DBMS를 설계할 수 있다.
즉, NoSQL은 데이터 자체보다는 그 데이터로 무엇을 하고 싶은가에 초점을 두는 것이다.
Key-Value
가장 기본적인 형태의 NoSQL이며 키 하나로 데이터 하나를 저장하고 조회할 수 있는 단일 키-값 구조를 갖는다.
- 복잡한 조회 연산을 지원하지 않는다.
- 고속 읽기와 쓰기에 최적화된 경우가 많다.
- 하나의 서비스 요청에 다수의 데이터 조회 및 수정 연산이 발생하면 트랜잭션 처리가 불가능하여 데이터 정합성을 보장할 수 없다.
위와 같은 특징 때문에 사용자의 프로필 정보, 웹 서버 클러스터를 위한 세션 정보, 장바구니 정보, URL 단축 정보 저장 등에 사용되며 Redis, DynamoDB, Orcale NoSQL Database가 해당된다.
Document
키 - 값 모델을 개념적으로 확장한 구조로 하나의 키에 하나의 구조화된 문서(JSON, YAML, XML 등)를 저장하고 조회한다. 하나의 키에 하나의 구조화된 문서를 저장하고 조회하는 격이다. 키는 문서에 대한 ID로 표현되며 저장된 문서를 컬렉션으로 관리하며 동시에 문서 ID에 대한 인덱스를 생성한다. 문서 ID에 대한 인덱스를 사용하여 O(1) 시간 안에 문서를 조회할 수 잇다.
대부분의 문서 모델 NoSQL은 B트리 인덱스를 사용하여 2차 인덱스를 생성한다. B트리는 크기가 커지면 커질수록 새로운 데이터를 입력하거나 삭제할 때 성능이 떨어지게 된다. 그렇기 때문에 읽기와 쓰기의 비율이 7:3 정도일 때 가장 좋은 성능을 보인다. 그렇기에 중앙 집중식 로그 저장이나 타임라인 저장, 통계 정보 저장 등에 사용된다.
RDBMS는 일반적으로 정의한 별도의 테이블에 데이터를 저장하며 단일 개체를 여러 테이블에 분산시킨다. 반면에 Document DB에서는 주어진 객체에 대한 모든 정보를 데이터베이스의 단일 인스턴스에 저장하며 저장된 모든 객체는 서로 다를 수 있다. 즉, 테이블 스키마가 정적이지 않고 유동적이며 레코드마다 다른 스키마를 가질 수 있다는 것이다.
즉, 복잡한 계층 구조 표현에 유리하다는 장점이 있다.
MongoDB, IBM Domino, CouchDB가 대표적이다.
Column
RDBMS에서는 데이터를 row 단위로 저장한다면, column model은 column 단위로 저장한다. 각 column은 column family로 묶이고, 이 family들은 또 다른 column이 될 수 있다.
하나의 키에 여러 개의 컬럼 이름과 컬럼 값의 쌍으로 이루어진 데이터를 저장하고 조회하며 모든 컬럼은 항상 타임 스탬프 값과 함께 저장된다.
또 하나의 특징이 데이터를 row 별로 연속적으로 저장한다는 점이다. 이에 따라 아래와 같은 특징을 가지게 된다.
- 데이터 수정 시 전체 row가 아닌 특정 row만 로드하면 되기 때문에 불필요한 I/O작업이 줄어든다.
- 데이터는 하나의 연속적인 entry로 취급되며, 따라서 조회 시 다른 row로 이동하는 등의 불필요한 작업이 필요없어 조회가 굉장히 빠르다.
- 하나의 row에 삽입되는 데이터의 형태가 동일하기 때문에 DB의 블록 하나에는 한 유형의 데이터만 존재하고, 따라서 압축이 가능하여 디스크 공간을 절약할 수 있다.
대부분의 컬럼 모델 NoSQL은 쓰기와 읽기 중에 쓰기에 더 특화되어 있다. 데이터를 먼저 커밋 로그와 메모리에 저장한 후 응답하기 때문에 빠른 응답속도를 제공한다. 그렇기 때문에 읽기 연산 대비 쓰기 연산이 많은 서비스나 빠른 시간 안에 대량의 데이터를 입려갛고 조회하는 서비스를 구현할 때 가장 좋은 성능을 보인다. 채팅 내용 저장, 실시간 분석을 위한 데이터 저장소 등의 서비스 구현에 적합하며 BigTable, AWS Redshift 등이 있다.
Graph
Graph 모델은 데이터 뿐만 아니라 데이터 간 관계도 데이터 취급한다.
데이터들의 관계를 중요시해서 저장된 데이터들이 에지로 직접 연결될 수 있어 데이터 질의시 특정 노드와 관련된 데이터를 한 번의 연산으로 획득이 가능하다.
또한, 고도로 연결된 데이터세트를 사용하는 애플리케이션을 쉽게 구축하고 실행하는 데에 유리하다. 주로 소셜 네트워킹, 추천 엔진, 사기 감지 및 지식 그래프 등에 사용되며 Neo4j, Giraph 등이 있다.
SQL VS NoSQL
SQL의 장점
- 고정적인 스키마, ACID로 인한 트랜잭션 및 데이터 무결성 보장
- 관계는 각 데이터를 중복없이 한번만 저장
- 하나의 테이블에서 중복 없이 하나의 데이터만을 관리하기 때문에 다른 테이블에서 부정확한 데이터를 다룰 위험이 없어진다.
- 데이터 중복이 없어서 데이터 update 용이
SQL의 단점
- 스키마를 사전에 계획하기 때문에 덜 유연하다.
- 데이터가 테이블로 분리되어있어 조인으로 인한 성능 저하
- 대체적으로 수직적 확장만 가능하다.
- 샤딩 방식이 있지만 구현하기가 어렵다.
NoSQL의 장점
- 스키마가 없어서 유연하다. 언제든지 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있다.
- 데이터는 애플리케이션이 필요한 형태로 저장된다. 데이터를 읽어오는 속도가 빨라진다.
- 수직 및 수평적 확장이 용이하다.
NoSQL의 단점
- 데이터 중복을 계속 업데이트 해야한다.
- 스키마가 정해져 있지 않아, 데이터에 대한 규격화가 되어 있지 않다.
- 데이터베이스 일관성이 약하다. 이 일관성을 가용성, 분할 용인 속도와 맞바꾸었다.
- 분할 용인 : 지역적으로 분할된 네트워크 환경에서 동작하는 시스템에서 두 지역 간의 네트워크가 단절되거나 네트워크 데이터의 유실이 일어나더라도 각 지역 내의 시스템은 정상적으로 동작해야 함을 의미
- 데이터가 여러 컬렉션에 중복되어 있어서 데이터를 UPDATE 하는 경우 모든 컬렉션에서 수행해야 하기 때문에 느리다.
어떤 DBMS를 선택해야 할까?
RDBMS(SQL)
- 데이터 구조가 명확하며 변경될 여지가 없으며 명확한 스키마가 중요한 경우
- 중복된 데이터가 없어(데이터 무결성) 변경이 용이하기 때문에 관계를 맺고 있는 데이터가 자주 변경이 이루어지는 시스템
NoSQL
- 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우
- Update가 많이 이루어지지 않는 시스템
- 대량의 데이터를 저장해야 해서 데이터 베이스를 스케일 아웃을 해야 하는 시스템
- 조회가 많고 데이터 변경은 자주 없는 경우
결론적으로, 굳이 NoSQL을 사용해야할 이유가 명확하지 않다면, 관계형 데이터베이스를 사용하는 것이 더 안전하다. 특히, 데이터 간 관계가 확실한 경우에는 오히려 더 비효율적인 결과를 일으킬 수도 있다
개발하고자 하는 서비스의 데이터 모델을 선택할 때 답해보아야하는 질문은 아래와 같이 정리해볼 수 있다
- 어떤 데이터를 다루는가?
서비스에서 주로 사용하는 데이터의 구조, 관계, 그리고 사용 방법에 대해서 정확하게 정의해야한다 - 주요 서비스가 무엇인가?
같은 도메인 내에서도 어떤 서비스를 제공하는 지에 따라 DB 관리 방향이 완전히 달라질 수 있다
주요 기능을 정리하고, 해당 기능을 구조적으로 가장 잘 지원하는 모델을 선택해야 한다
결론
이번 프로젝트 이외에는 RDBMS만 써왔는 데 무조건 RDBMS가 정답이 아니라는 것을 알게 되었다.
결국 NoSQL이 나온 이유도 RDBMS의 한계를 극복하고 데이터 자체보다는 그 데이터로 무엇을 하고 싶은가에 초점을 두는 것이기 때문에 현재 프로젝트의 데이터와 상황에 맞는 데이터베이스를 선택하는 것이 더 효율적이라는 것을 깨닫게 되었다.
아직까진 NoSQL를 적극적으로 사용할만한 프로젝트를 경험해보진 못했지만 NoSQL의 특성에 맞는 프로젝트를 만나게 된다면 RDBMS와 비교해보면서 사용해보고 싶다.
Reference
'Back-End > Database' 카테고리의 다른 글
| [왜 Redis를 사용했는가?] 03. Redis란? (1) | 2022.10.17 |
|---|---|
| [왜 Redis를 사용했는가?] 02. In-Memory DB (1) | 2022.10.08 |
댓글