Database, DBMS and SQL
RDBMS와 NoSQL에 대해 알아보기 전에 몇 가지 기본적인 사항을 확인하고 가자.
우선 데이터베이스(Database)에 대해서는 여러 가지 정의가 있지만, 일반적으로 여러 사람이 공유하여 사용할 목적으로 체계화되어 통합 관리되는 데이터의 집합이며, 텍스트, 숫자, 이미지, 영상, 일반 파일 등 모든 유형의 데이터를 포함한다.
그리고 DBMS는 DataBase Management System(데이터베이스 관리 시스템)의 약어로, 사용자와 데이터베이스 사이에서 다수의 사용자들이 데이터베이스 내의 데이터에 접근할 수 있도록 사용자 혹은 다른 프로그램의 요구를 처리하고 응답하는 시스템이다. 데이터를 만들고 저장하고 관리하는 기술로 이해하면 될 것이다.
마지막으로 SQL은 Structured Query Language(구조적 쿼리 언어)의 약어로, 관계형 데이터베이스 관리 시스템(RDBMS)에서 데이터를 추출하고 조작하는 데 사용되는 데이터 처리 언어이다. 데이터의 검색과 관리, 데이터베이스 스키마 생성 및 수정, 데이터베이스 객체 접근 조정 관리 등의 기능을 수행한다.
RDBMS(Relational DataBase Management System)
개요
관계형 데이터베이스 관리 시스템(이하 RDBMS)은 데이터를 스키마(Schema)로 정의된 2차원 테이블 형태로 표현하는 데이터베이스이다. 각 테이블은 1개 이상의 레코드(Record)로 구성되어 있으며, 각 레코드는 1개 이상의 속성(Attribute)으로 이루어져 있다. 간단히 레코드를 행, 속성을 열로 이해하면 쉽다.
레코드는 한 객체에 대한 정보로서, 예를 들어 '학생' 테이블이 있을 때 '홍길동'이라는 학생 각체에 대한 정보를 의미한다. 그리고 홍길동이라는 학생의 학번, 학과, 학년, 키, 몸무게 등의 정보가 있다면 각각이 속성에 해당한다. 그리고 각 속성이 취할 수 있는 값, 예를 들어 몸무게라는 속성이 취할 수 있는 '실수'라는 값의 집합을 도메인(Domain)이라고 한다.
RDBMS는 1개 이상의 테이블로 구성되며, 각 테이블이 다른 테이블과 관계를 갖는다는 것이 가장 큰 특징이다. 그리고 이러한 관계를 나타내기 위해 외래 키(Foriegn key)라는 것을 사용한다.
여기서 간단히 기본 키(Primary key)와 외래 키에 대해 짚고 넘어가자.
'기본 키'는 테이블 내에서 각각의 레코드에 대해 유일성과 최소성을 갖는 키로, 유일성은 각 레코드를 다른 레코드와 구분할 수 있도록 하는 성질이며, 최소성은 유일성을 얻기 위해 최소한의 속성만 필요하다는 성질이다. 앞선 학생 테이블의 예에서 '학번'은 다른 학생과 홍길동이라는 학생을 구분할 수 있도록 해 주며, 학년이나 몸무게 등의 다른 속성 없이도 학번만으로 홍길동이라는 학생을 구분할 수 있으므로 최소성을 갖는다. 즉, 학번이 기본 키에 해당한다고 할 수 있다.
반면 외래 키는 다른 테이블의 기본 키를 참조하여 추가한 키이며, 이를 이용해 다른 테이블과의 관계성을 추가하는 것이 RBMS의 가장 큰 특징이다. '학과'라는 테이블이 존재하고, 국문학과, 영문학과, 수학과 등등의 레코드가 학과 테이블 내에 존재한다고 하자. 앞서 홍길동 학생의 소속이 국문학과라고 한다면, '학과' 테이블의 '국문학과' 레코드에 존재하는 '학과 번호'라는 기본 키를 참조하여 해당 정보를 '학생' 테이블의 '학과 번호' 속성에 추가할 수 있다. 그리고 이때 '학생' 테이블의 '학과 번호'가 외래 키가 되는 것이다.
RDBMS의 장단점
RDBMS는 테이블 간의 관계를 설정하여 데이터를 관리함으로써 다음과 같은 장점을 갖는다.
- 표준화된 언어인 SQL을 사용하여 데이터 분석 및 검색이 용이하다.
- 대규모의 데이터 처리에도 뛰어난 성능을 보인다.
- 동시에 여러 사용자가 사용하더라도 데이터의 일관성 및 무결성을 유지하는 데 용이하다.
이러한 특징으로 인해 현재 가장 많이 사용되는 DMBS 중 하나가 바로 RDBMS이다.
반면 단점도 존재한다.
- 한번 생성한 DBMS의 스키마(테이블의 속성 및 각 속성별 도메인의 데이터 타입 등을 정의하는 모델)을 변경하는 것이 쉽지 않다(스케마 변경 시 모든 데이터를 스키마에 맞추어 업데이트해야 한다).
- 데이터의 ACID(원자성, 일관성, 고립성, 지속성) 특징을 유지하기 위해 트랜잭션을 사용하며, 따라서 데이터베이스의 수평적 확장이 어렵다.
※ 데이터의 ACID와 트랜잭션은 추후 별도로 다룬다. - 테이블 간의 관계가 복잡해질수록 조인 연산이 많이 필요하며, 따라서 쿼리가 복잡해진다.
NoSQL(Not Only SQL)
개요
NoSQL은 비관계형 데이터베이스로서 RDBMS 방식으로는 처리하기 어려울 정도로 복잡하고 큰 데이터가 등장함에 따라 점차 사용량이 늘어나고 있는 데이터베이스이다. NoSQL은 테이블 간의 관계를 정의하지 않으므로 테이블 간 Join이 불가하며, 정해진 스키마 없이 자유롭게 데이터를 저장할 수 있다.
NoSQL의 데이터 표현 방식
다양한 형태(4가지)의 데이터 모델을 사용해 데이터를 표현한다.
1. Key-Value Database
- 데이터를 Key와 Value의 쌍으로 저장하는 방식
- Key는 데이터에 접근하기 위한 용도로 사용되며, Value는 어떠한 형태의 데이터라도 담을 수 있다.
- 데이터를 질의하는 속도가 매우 빠르다.
- Document Database
- Key와 Document 쌍의 형태로 데이터를 저장하는 방식
- Key-Value Database와 마찬가지로 검색에 최적화된 방식
- Value가 계층적인 형태인 Document로 저장되므로 객체-관계 매핑이 불필요함
- 사용이 다소 번거롭고, 질의 결과가 JSON 혹은 XML의 형태로 출력되므로 쿼리가 SQL과 다르고 최종 질의 결과의 사용법에도 차이가 있다.
- Graph Database
- 데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용해 표현하고 저장하는 방식
- 관계형 모델이라고 할 수 있으며, 데이터 간의 관계가 탐색의 키일 경우 적합한 방식이다.
- 소셜 네트워크의 네트워킹 데이터, 혹은 연관 데이터를 추천하는 추천 엔진이나 패턴 인식 등의 데이터를 저장하는 경우 적합한 형태이다.
- Wide Column Database
- Column-family Model 기반의 데이터베이스로, 앞서 세 모델과 달리 '키'에서 필드를 결정하는 방식
- 키는 Row(키 값)와 column-family, column-name을 가진다.
- 연관된 데이터들은 같은 column-family 내에 속하며 각자의 column-name을 가짐
NoSQL의 장단점
NoSQL은 다음과 같은 장점을 갖는다.
- 유연성 : 스키마가 없으므로 자유로운 데이터 구조를 가질 수 있다.
- 고성능 : 대용량 데이터 처리 성능이 뛰어나며 RDBMS에 비해 더 대용량의 데이터를 저장할 수 있다.
- 확장성 : 데이터 분산이 용이하며, 성능 향상을 위하여 Scale-out이 가능하여 서버 확장이 용이하다.
- 가용성 : 여러 대의 백업 서버를 구성할 수 있으며, 이에 따라 일부 서버의 장애 발생 시에도 무중단 서비스가 가능하다.
반대로 다음과 같은 단점도 있다.
- 데이터의 중복이 발생할 수 있으며, 중복된 데이터의 변경 시 모든 컬렉션에서 수정이 이루어져야 한다.
- 스키마가 없으므로 명확한 데이터 구조를 보장하지 않으며, 데이터 구조의 설계 및 결정이 어려울 수 있다.
- 데이터가 여러 컬렉션에 중복되어 있어 데이터 업데이트 시 속도가 느리다.
- Key 값에 대한 입출력만을 지원한다.
RDBMS vs NoSQL
| RDBMS | NoSQL | |
|---|---|---|
| 데이터 저장 모델 | table | JSON document / Key-value / Graph 등 |
| 스키마 | - 명확한 데이터 구조 보장 - 데이터의 유연성은 낮음 | - 스키마가 없어 자유로운 데이터 구조 - 명확한 데이터 구조를 보장하지 않아 데이터 구조의 설계 및 결정은 어려움 |
| 확장성 | - Scale-up만을 지원해 비용이 많이 듦 | Scale-up과 Scale-out을 모두 지원하여 데이터 분산이 용이함 |
| 데이터 처리 | - 부하 발생 시 처리는 어려움 - 데이터의 Update는 빠름 | - 많은 양의 데이터 처리, 저장 가능 - 데이터의 Update는 비교적 느림 |
| 사용 | - 데이터의 구조가 명확하여 변경 여지가 없고 명확한 스키마가 중요한 경우 - 데이터의 Update가 잦은 시스템의 경우 | - 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장될 수 있는 경우 - 데이터의 Update가 많이 이루어지지 않는 시스템 - 데이터의 양이 많아 데이터베이스의 Scale-out이 필요한 시스템 |
MySQL Replication
MySQL을 사용할 때 Master-Slave 구조의 이중화 구성을 하는 경우가 많다. 이는 데이터베이스에 문제가 생겼을 때 데이터가 유실될 가능성을 줄이기 위한 것인데, 여기에 필요한 것이 Replication이다.
Replication은 말 그대로 DB의 데이터를 물리적으로 다른 곳에 복제해 두는 것을 의미한다.
Master와 Slave
Master와 Slave를 각각 DB 서버라고 생각하고 각자의 역할을 이해해 보자.
MySQL에서는 오직 Master만이 데이터의 등록/수정/삭제 작업을 수행할 수 있다. Master는 상기 쿼리 요청이 발생할 경우 이를 수행하고 해당 로그를 Binary log라는 곳에 기록하는데, 이때 기록 방식은 세 가지가 있다.
- Statement-based type
MySQL 3.23 이후 도입된 방식으로, 실행된 SQL을 그대로 Binary log에 기록하는 방식이다. Binary log의 크기는 작으나, SQL에 따라 결과가 달라질 수 있다. - Row-based type
MySQL 5.1부터 도입된 방식으로, 변경된 행을 BASE64로 인코딩하여 Binary log에 기록한다. 이 경우 특정 SQL이 변경하는 행의 수가 많을 경우 Binary log의 크기가 비약적으로 커질 수 있다. - Mixed type
기본적으로는 Statement-based type으로 기록하되, 경우에 따라 Row-based type으로 기록하는 방식이다.
Replication Mechanism
- Client가 쓰기 쿼리 작업을 요청하면, 이 쿼리 요청은 Master DB가 받는다.
- Master DB는 이 요청(변경 요청)을 Binary log에 기록하고, 그 다음 Master DB에 반영(commit)한다.
- Master DB는 관련 이벤트를 Slave DB(들)에 전달한다.
- Slave I/O thread에서 이벤트를 캐치하면 Binary log를 Slave DB 각각의 Relay log에 저장한다.
- Slave SQL thread에서 Relay log를 읽고 Slave DB를 업데이트한다.
- 읽기 쿼리 작업 요청이 올 경우 이 쿼리 요청은 Slave DB가 받는다.
Master-Slave 구조의 장점
Master-Slave 구조로 DB를 구성할 경우 가장 먼저 '읽기 쿼리'에 대한 트래픽을 분담함으로써 서버의 트래픽 부담을 줄일 수 있다. 또한 앞서 설명한 대로 시스템에 장애가 발생할 경우 미리 백업 용도로 사용했던 Slave DB로 대체하여 시스템을 운영할 수 있다는 장점도 있다.
다만 데이터의 동기화가 제대로 되지 않을 수도 있다는 단점이 있다. 따라서 정합성과 실시간성이 보장되어야 하는 쿼리는 Master DB로, 정합성이 다소 떨어져도 괜찮은 읽기 등의 쿼리는 Slave DB로 분산시켜야 한다.
참고 자료
