Introduction

MySQL, MariaDB, MongoDB, Redis...방금 리스트한 데이터베이스들을 두 가지로 분류하자면 어떻게 분류하는 게 가장 좋을까? 여러 방법으로 나눌 수도 있겠지만, 가장 큰 특징으로 접근하면, 첫 두 개의 데이터베이스는 SQL, 그리고 뒤의 두개는 NoSQL 형태의 데이터베이스라는 것이다. 개인적인 경험으로 사용해본 것은 SQL이고 한 프로젝트에서 백엔드 분이 NoSQL인 파이어베이스 스토리지를 사용하는 것을 어깨 너머 보았다. 더 나아가 다양한 데이터베이스를 사용해보고 싶기에 개념을 머리속에 정리해두는 시간을 가지고 싶었다. 한번 간단히 정리한 기억이 있지만, 이번에는 조금 자세히 들어가볼까 한다.

SQL

SQL 데이터베이스는 SQL (Structured query language)를 사용해 데이터를 정의하고 또 처리한다. SQL은 용도가 많고 또 많이 쓰이기 때문에 매우 매력적인 옵션이다. 복잡한 쿼리들을 처리하기 적합하고 또 리소스도 많고 사용된 시간이 길어 안전하기도 하다. 하지만 다른 측면에서 보면 SQL은 매우 제한적이다. SQL은 작업을 하기 전 정해진(엄격한) 스키마를 구상해 데이터의 구조를 결정해야 하고 모든 데이터는 같은 구조를 따르며 스키마에 따라 데이터베이스 테이블에 저장된다. 이 점은 준비에 많은 시간을 쏟게 하고 또 구조의 변화가 일어난다면 모든 시스템에 상당히 까다로운 작업을 통해 적용시켜야 한다. 데이터는 또 관계가 있다면, 관계를 통해 연결된 여러 개의 테이블에 분산되어 저장된다.

Strict Schema

데이터는 테이블에 레코드(record / 기록)으로 저장되고, 각 테이블에는 스키마에서 정의한 명확한 구조가 있다. 이 구조는 어떤 데이터가 어떤 테이블에 어떤 항목으로 들어가고 말지 정의하는 필드(field)의 집합을 의미한다. 구조를 처음 스키마에서 정의할 때는 필드의 이름과 데이터 유형의 조합으로 정의한다.

SQL 데이터베이스에서는 스키마에서 정의된 구조를 준수하지 않는 레코드를 추가 할 수 없고, 스키마를 수정하지 않는 이상 없던 필드를 추가하거나, 확장시킬 수 없다.

Relation

관계는 SQL과 NoSQL 데이터베이스를 differentiate 하는 중요한 요소 중 하나이다. 관계 설정을 통해서 데이터들을 여러 개의 테이블에 나누어서 데이터들의 중복을 피할 수 있고 중복없이 하나의 데이터만을 관리하기에 다른 테이블에서 부정확한 데이터를 다룰 위험이 없다.

NoSQL

NoSQL 데이터베이스는 구조화 되어 있지 않은 데이터를 위해, 틀에 얽매이지 않은 스키마를 가지고 데이터를 다양한 방식으로 저장한다. 컬럼별로, 문서별로 (NoSQL은 레코드를 문서(document)라고 부른다), 그래프 기반으로, 그리고 키 - 값으로 정리되어 데이터를 저장할 수 있다. 이러한 유연성을 지녔기 때문에 NoSQL 데이터베이스는 먼저 구조를 정의하지 않고 문서 작성을 시작할 수 있고, 문서마다 유니크한 구조를 지닐 수 있으며 데이터베이스마다 구문이 다르고 프로젝트를 진행하면서 필드를 추가해 확장해 나갈 수 있다.

NoSQL 데이터베이스는 스키마도 없고(있다면 유연한 스키마), 관계도 없다. 잠깐 언급했듯이 NoSQL에서는 레코드를 문서라고 부르는데 SQL이 정해진 스키마를 따르지 않으면 데이터를 추가하지 못하는 점에 비해, NoSQL에서는 다른 구조의 데이터를 같은 컬렉션(SQL에서의 테이블)에 추가할 수 있다.

관계형 데이터베이스에서는 테이블에 나누어 저장했다면, 비관계형 데이터베이스에서는 관련이 있는 데이터를 동일한 컬렉션에 넣는다. 이름, 나이 별로 테이블이 있는게 아니라, 유저라는 컬렉션에 JSON 데이터 처럼 저장을 해주는 것이다. 따라서 관계에 따라 Join을 해줄 필요가 없이 이미 한 문서 안에 필요한 정보들을 모두 지니고 있기에 Join이라는 개념이 존재하지 않는다. 조인을 원하면 직접 해당 외래키를 검색하여 사용할 수는 있지만, 일반적이지 않다. 대신 데이터를 가져올 때, 컬렉션에 있는 데이터를 복제하여 필요한 데이터의 일부만 그때그때 가져온다.

이렇게 컬렉션 별로 데이터를 저장해준다면 데이터가 중복되기에 데이터 업데이트 시 특정 데이터를 누락하지 않게 조심해야한다. 그럼에도, 비관계형 데이터베이스는 조인을 하지 않기에 관계 설정을 하지 않고, 이 점은 복잡한 과정을 건너뛸 수 있다. 필요한 데이터는 이미 컬렉션별로 각각 저장이 되어 있어 자주 변경되지 않는 데이터일때 그 빛을 낸다.

Scalability (확장성 / 범위성)

Scalability의 의미는 처리할 작업량이 늘어날때마다, 늘어나는 요구에 맞춰 크기를 키우거나 기능을 확장시킬 수 있는 시스템, 네트워크 혹은 과정은 능력을 말한다. 데이터베이스의 확장은 크게 두가지로 구별되는데, 수직적과 수평적으로 구별된다.

• 수직적 확장
  수직적 확장 (Vertical Scalability)는 CPU나 RAM 같은 부품이나 하드웨어를 추가해주거나 교체를 해 전체적인 성능을 향상시키는 것을 의미한다. 그래서 소프트웨어의 설계나 구조에 변화를 주거나 시간을 따로 쏟을 필요가 없다. 단순하게 데이터베이스 서버의 성능을 향상시킨다.
• 수평적 확장
  수평적 확장 (Horizontal Scalability)은 더 많은 서버를 추가해서 데이터베이스를 전체적으로 분산시키는 것을 의미한다. 하나의 데이터베이스는 작동하지만 여러 호스트에서 작동한다.
  

Quick Summary

보통 시스템이 커져가면서 DB를 증설해야 하는 시점이 오면 SQL의 경우, 수직적으로 확장, 즉 Scale-up의 형태로 DB를 증설하기에 관리가 어려워질 수 있는데 NoSQL의 경우 수평적으로 확장, 즉 Scale-Out의 형태로 증설을 하기에 숫자는 무한대로, 서버를 계속 분산시켜 DB를 증설할 수 있다. SQL은 '샤딩(Sharding, 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법)'을 통해서 수평적 확장을 흉내낼 수 있지만 구현하기가 어렵다는 단점이 있다. 수평적인 확장을 위해서는 비관계형 데이터베이스가 이미 기본적으로 지원하기에 여러 서버에서 데이터베이스를 쉽게 분리 할 수 있다.

Your Choice?

일단 지금까진 SQL과 NoSQL의 간단한 정보를 알아보았다. 관계형과 비관계형 데이터베이스는 어느 한개가 더 좋다! 이런 개념보다는 어떤 데이터를 다루는지, 또 어떤 상황에서 사용되는지에 따라서 결정되어야 한다.

SQL

장점

• 확실하고 명확하게 정의된 스키마,
• 구조의 완전성을 보장할 수 있다.
• 관계를 설정하기에, 데이터는 중복없이 한번만 저장된다.

단점

• 유연하지 못하다. 스키마를 사전에 시간 들여 철저하게 짜야 하고 나중에 수정하기 번거롭다 (엄격한 스키마).
• 관계를 맺어 데이터를 저장하기에, 중복되지는 않지만, 조인을 많이 해야할 경우 매우 복잡한 쿼리를 작성해야 할 수 있다.
• 수평적 확장이 가능하지만 어렵기 때문에 성장 한계가 오는 시점이 온다.

관계를 맺고 있는 데이터가 자주 변경되는 경우, 또 명확한 스키마가 사용자와 데이터에게 중요한 경우 관계형 데이터베이스를 사용하는게 좋다. 금융 산업과 같은 시스템의 형태가 급격하게 변하지 않으면서 그 안의 데이터가 계속 바뀌는 보수적인 시스템에서 유리하다.

NoSQL

장점

• 스키마가 없기에, 훨씬 더 유연하다. 언제든지 데이터를 추가할 수 있다 (필드 추가).
• 어떠한 형식으로도 데이터를 저장할 수 있기에, 필요한 대로 저장해 읽어오는 속도가 빨라진다.
• 수직 및 수평 확장 모두 가능해 데이터베이스가 애플리케이션에서 발생시키는 모든 읽기 / 쓰기 요청을 처리할 수 있다.

단점

• 유연성에 의해, 데이터 구조 결정을 계속 미룰 수 있다.
• 데이터를 중복되게 필요한 컬렉션 마다 저장할 수 있어, 필요한 컬렉션마다 돌면서 여러 개의 레코드를 다 업데이트해줘야 한다. 누락할 시, 데이터가 최신이 아닐 수 있다.
• 수정 시, 모든 컬렉션에서 다 수정해줘야 한다.

비관계형 데이터베이스는 정확한 데이터 구조를 알 수 없거나 변경 / 확장 될 수 있는 경우 (수평적으로), 읽기 처리는 많이 하지만, 데이터를 자주 변경하지 않는 경우 사용하면 유리하다. 스타트업이 짧은 시간안에 구조등을 계속 발전시키며 변화를 줘야 할 때 사용하면 좋다. 읽기를 많이 하고 많은 양의 정보를 저장해야하는...채팅 정보를 저장하면 유리할 것 같다! 읽어오기만 하면 되니까!

Conclusion

SQL과 NoSQL 데이터베이스는 각자의 장단점들이 있다. 또 각 종류에서 수많은 데이터베이스의 종류가 있기 때문에 깊게 들어가 일일히 따져보면 자신의 프로젝트에 맞는 적합한 데이터베이스를 고를 수 있을 것이다. 현재 나는 관계형만 직접 작성하고 비관계형을 실제로 작성한적이 없기 때문에 써보고 싶은 마음이 있다. MongoDB 이야기를 하도 많이 들어서, 한번 사용해보고 싶은 마음이 있다.

기본적인 개념을 탑재 했기에, 다양한 데이터베이스를 사용해보고싶다!

참고
https://brunch.co.kr/@kooslab/181
https://siyoon210.tistory.com/130
https://www.thorntech.com/2019/03/sql-vs-nosql/
https://www.xplenty.com/blog/the-sql-vs-nosql-difference/