MySQL vs NoSQL

관계형 데이터베이스 (MySQL)

데이터 모델

관계형 모델은 데이터를 행과 열로 구성된 테이블이라고 하는 테이블 형식 구조로 정규화한다. 스키마는 테이블, 열, 인덱스, 테이블 간 관계 및 기타 데이터베이스 요소를 정의한다.

ACID 속성

기존의 RDBMS(관계형 데이터베이스 관리 시스템)는 약어인 ACID(원자성, 일관성, 격리성, 내구성)로 정의된 일련의 속성 세트를 지원한다. 원자성은 트랜잭션이 완전히 실행되거나 전혀 실행되지 않는 "모두 실행 또는 전혀 실행되지 않음"을 의미한다. 일관성은 트랜잭션이 실행되면 데이터가 데이터베이스 스키마를 준수해야 함을 의미한다. 격리성은 동시에 일어나는 트랜잭션이 다른 트랜잭션과 별도로 실행되어야 함을 의미한다. 내구성은 예기치 못한 시스템 장애 또는 정전으로부터 마지막으로 알려진 상태로 복원하는 기능이다.

성능

성능은 일반적으로 디스크 하위 시스템에 따라 다릅니다. 최고 성능을 달성하기 위해서는 쿼리, 인덱스 및 테이블 구조를 최적화해야 한다.

확장 가능

더 빠른 하드웨어로 "확장"이 간편해 진다.  분산 시스템을 확장하기 위해서는 관계형 테이블에 대해 추가적인 투자가 필요하다.

API

구조화 질의어(SQL)를 준수하는 쿼리를 사용하여 데이터를 저장 및 검색하기 위한 요청이 전달된다. 이러한 쿼리는 RDBMS(관계형 데이터베이스 관리 시스템)에 의해 구문 분석 및 실행된다.

도구

SQL 데이터베이스는 일반적으로 데이터베이스로 구동되는 애플리케이션의 배포를 간소화하기 위해 다양한 도구 세트를 제공한다.

NoSQL 데이터베이스 (NoSQL)

데이터 모델

비관계형(NoSQL) 데이터베이스는 일반적으로 스키마를 강제 적용하지 않는다. 파티션 키는 값, 열 세트, 반정형 JSON, XML 또는 관련 항목 속성을 포함하는 다른 문서에 일반적으로 사용된다.

ACID 속성

NoSQL 데이터베이스는 종종 수평으로 확장되는 더 유연한 데이터 모델용 기존 RDBMS(관계형 데이터베이스 관리 시스템)의 일부 ACID 속성을 교환한다. 이러한 특성은 기존 RDBMS가 성능 병목 지점, 확장성, 운영상의 복잡성, 늘어나는 관리 업무 및 지원 비용 문제가 복합적으로 발생할 경우 이를 해결하기 위한 구조적 문제에 직면하면 NoSQL 데이터베이스가 탁월한 선택을 할 수 있도록 지원한다.

성능

성능은 일반적으로 기본 하드웨어 클러스터 크기, 네트워크 지연 시간 및 호출 애플리케이션의 기능이다.

확장 기능

지연 시간을 늘리지 않고 처리량을 향상시키기 위해 저비용 하드웨어의 분산 클러스터를 사용하여 "확장"하도록 설계되었다.

API

객체 기반 API를 통해 앱 개발자가 인 메모리 데이터 구조를 쉽게 저장 및 검색할 수 있다. 파티션 키를 사용하면 앱에서 키 값 페어, 열 세트 또는 일련의 앱 객체 및 속성을 포함하는 반정형 문서를 검색할 수 있다.

도구

NoSQL 데이터베이스는 일반적으로 클러스터 관리 및 조정을 위한 도구를 제공한다. 애플리케이션은 기본 데이터에 대한 주요 인터페이스이다.

NoSQL의 장점

RDBMS는 데이터 일관성과 중복 최소화를 위해서 schema를 구성할 때, 여러 테이블로 나누어서 구성하는 것이 기본이다. 따라서 데이터들을 많은 수의 서버로 분산하여 나누는 data sharding을 RDBMS 자체에서 지원하는 것이 어렵다.
보통 RDBMS에서는 서버의 수를 늘리는 확장(Scale Out)은 3-5대가 최대 수준이며, 서버를 더 대형으로 교체하는 확장(Scale Up)이 필요하게 된다. Scale up은 Scale Out에 비해서 비용과 서비스 중단 시간 측면에서 교체 부담이 훨씬 크다.

NoSQL은 RDBMS의 이런 단점을 극복하고 Scale Out이 잘 될 수 있도록 설계되었으므로 많은 서버로 확장하는 것이 가능하다.

장점 1. NoSQL에서는 많은 서버로 확장(Sclae-out)이 가능하다.

NoSQL에서는 서버 확장성을 위해서 데이터 중복이 생기더라도 가급적 테이블들을 쪼개지 않고 하나의 큰 테이블(Big Table이라는 이름이 생긴 이유?)에 모두 담아서 저장한다. 그래서 한 테이블을 여러 서버에 나누어 저장하는 Sharding이 쉬워진다.

좀 더 구체적으로 설명하면 NoSQL에서 주로 사용하는 데이터 모델은 key -> value 형태 즉 map 방식이다. 예를들어 user라는 테이블에서 user_id = 12를 key 값으로 가지는 데이터는 12 -> { james, man, 34, manager} 와 같이 저장된다. 이 때 value에 해당하는 { ... } 내에 들어가는 내용은 각 user별로 그 순서와 포맷이 달라도 된다. 사실 NoSQL은 value 내부의 포맷은 상세하게 관리하지 않고 RDBMS에 비해서 단순하게 처리하는 것이라고 할 수도 있다. 이렇게 구현하였기 때문에 오히려 key값에 따른 Sharding이 더 쉽게 된다.

그런데, 개발자들은 value내에 원하는 대로 데이터를 저장할 수 있는 유연성에서 RDBMS에서 누리지 못하던 유연성을 덤으로 얻게 되었다. 특히 최근에 서비스 내용 업데이트 주기가 빨라지고 SNS처럼 다양한 데이터 유형을 다루는 서비스가 증가하면서 데이터 유연성이 더욱 장점으로 부각되게 되었다.

장점 2. NoSQL에서는 가변적인 구조로 데이터를 저장할 수 있다.

NoSQL의 단점

앞에서 설명한대로 데이터 중복이 있고 포맷이 가변적인 커다란 table의 특징 때문에 NoSQL에서는 여러 테이블간의 Join이 불가능하다. 또 테이블 내의 어떤 값에 대해서 indexing 하는 것도 어렵다. 따라서 NoSQL에서의 데이터 쿼리는 Key값을 기준으로 value를 read하거나 write하는 단순한 방식이며, RDBMS 처럼 복잡한 쿼리는 불가능하다.

단점 1. NoSQL에서는 다양하고 복잡한 데이터 쿼리는 불가능하다.

NoSQL는 sharding 방식을 사용해서 큰 테이블을 여러 서버에 나누어 저장한다. 또 fault tolerancy를 위해서 데이터는 두 개 이상의 서버에 저장된다. 어떤 데이터의 값에 update가 발생한 경우, NoSQL는 중복 저장된 모든 서버들에 해당 업데이트가 다 될 때까지는 조금 시간이 걸린다.(서버가 아주 많을 수 있다는 점을 생각하자.)

RDBMS에서는 최대 서버수가 기껏 3~5대이기 때문에 모든 서버를 업데이트되기 전까지는 해당 데이터 또는 table에 lock을 걸어서 읽기를 금지한다. 따라서 데이터를 읽어갈 때는 어떤 서버에서 읽더라도 항상 같은 값이 보장된다. 하지만 NoSQL에서는 lock을 하게될 경우 전체 속도가 너무 느려지게 되므로 RDBMS와 같은 lock을 하지 않는다. 따라서 NoSQL의 일부 서버에서는 아주 잠시 동안은 old data가 제공될 수 있다. 물론 시간이 좀 지나면 모든 서버는 결국 같은 값을 가지게 된다. (= Eventual consistency)

단점 2. NoSQL에서는 데이터 일관성이 항상 보장되지 않는다.