[DB 선택 가이드 🗺️] 이번 프로젝트, DB 뭐 써야하지? | DBMS 종류 장단점 정리
프로젝트를 처음 시작하면 언어, 프레임워크 등 다양한 것들을 고민하게 됩니다. 그리고 언어와 프레임워크가 정해지면 또 하나의 고민을 하게 되죠.
아, 이번 프로젝트 디비 뭐 쓰지?
아마 이 글을 보시는 분들은 DB에 대한 고민이 많으실 겁니다. 저 또한 매번 하는 고민이기도 하고요. 🤔
오늘은 DB의 종류 7가지를 정리해보고, 어떤 상황에 어떤 DB를 선택하면 좋을지 가이드를 작성해보려고 합니다. 결론만 보고 싶으신 분들이라면마지막 챕터인 'DB 선택 가이드 - 총 정리'를 확인해주세요.
Recommended- 이런 분들에게 추천드려요. - 평소 MySQL이나 Oracle등 유명한 RDB만 쓰시는 분들. - DB 종류 별 장단과 해당하는 DBMS가 궁금하신 분들. - 결론적으로 어떨때 어떤 DB를 사용해야 하는지 고민이신분들.
(* 해당 글은 21년 12월에 썼던 글을 다듬어 재발행한 글입니다.)
💥 데이터베이스 종류
DB를 선택하기 위해선 우선 데이터베이스의 종류에 대하여 알아야 합니다.
흔히 아는 RDB와 NoSQL DB 말고도 다양한 종류의 DB가 있습니다.
(1) 계층형 데이터베이스 (2)네트워크형 데이터베이스 (3) 관계형 데이터베이스 (4) 객체지향 데이터베이스 (5) 객체관계형 데이터베이스 (6) NoSQL 데이터베이스 (7) NewSQL 데이터 베이스
7가지라니 생각보다 많죠? 현재 많이 사용하지 않는 계층형과 네트워크형부터, 주를 이루고 있는 객체관계형과 NoSQL, 새로 나온 NewSQL까지 정리해보았습니다.
1. 계층형 데이터베이스 (Hierachicl DB)
계층형 데이터베이스는 데이터를 트리 구조로 정의하고 부모와 자식 형태를 갖습니다. (1:N)
데이터베이스에 있는 하나의 테이블이 뿌리 역할을 하며, 부모는 여러 자식을 가지지만 자식은 오직 하나의 부모만을 가질 수 있습니다.
장점
- 데이터 검색이 빠릅니다. (테이블 구조 사이에 명시적 링크(Explicit Link)가 있습니다.)
- 참조 무결성이 내장되어 있으며 자동적으로 시행됩니다.
단점
- 복잡한 관계 표현이 어렵습니다.
- 중복 데이터 문제가 발생합니다. - 1:N 기준에 맞지 않는 일반적인 관계를 구현하기 어렵습니다.
자식은 하나의 부모를 가질 수 있는 1:N 관계만을 지원하기 때문에 자식 노드가 여러 상위 노드와 연결되어야 할 때 동일한 데이터를 여러 위치에 중복 저장해야 합니다. 과목이 있고, 한 학생이 여러 과목을 수강한다면 과목 아래 학생 정보를 중복 저장해야 하는 것이죠.
이런 문제를 해결하기 위해 만들어진 것이 바로 네트워크형 데이터베이스입니다.
2. 네트워크형 데이터베이스 (Network DB)
네트워크형 데이터베이스는 레코드 간의 다양한 관계를 그물처럼 갖는 구조로 M:N 관계를 유지합니다.
계층형의 중복 데이터 문제를 해결한 구조로, M:N 관계를 지원하기 때문에 중복 저장 없이 여러 레코드가 연결될 수 있습니다.
장점
- 계층 구조에 링크를 추가하여 유연성과 접근성이 우수합니다. - 데이터 추출이 빠르고 효과적입니다.
단점
- 유지보수 비용이 많이 듭니다.
하지만 계층형, 네트워크형 데이터베이스는 대규모 데이터를 다루기에는 적합하지 않습니다. IBM IMS와 IDMS 등의 남아있는 DBMS가 있긴 하지만 현재는 거의 사용되지 않고, RDB나 NoSQL DB로 이전하는 추세입니다.
3. 관계형 데이터베이스 (Relational DB)
흔히 표현하는 행과 열로 구성된 Table 간의 관계를 나타낼 때 사용하는 데이터베이스입니다. 가장 많이 사용되는 데이터베이스로 MySQL, Oracle이 RDB에 속합니다.
장점
- 범용적이고 고성능을 보여줍니다. -데이터의 일관성을 보장합니다. - SQL이 존재하며 유연하게 질의할 수 있습니다. -참고 자료들이 풍부합니다.
단점
-갱신이 발생한 테이블의스키마 변경이 어렵습니다. (무결성과 일관성을 중시하기 때문에 컬럼 확장이나 수정이 어렵습니다.) - 비정형 데이터 처리에 한계가 있습니다.
RDB는 데이터의 완전성이 중요한 상황일 때 적합합니다.RDBMS 종류 별 설명은해당 글을 읽어보시는 걸 추천드려요.
4. 객체지향 데이터베이스 (Object-oriented DB)
객체지향 데이터베이스는 객체지향 언어의 개념을 데이터베이스에 접목해 만들어진 데이터베이스입니다.
데이터베이스에 사용자 정의 데이터와 멀티미디어 데이터 등에 대한 요구가 커지면서, 객체지향을 프로그래밍의 개념을 반영한 데이터베이스 모델이 등장하게 된 것입니다.
장점
- 사용자 정의 타입을 지원합니다. - 프로그램 내의 정보 구조와 데이터베이스 스키마 구조가 거의 유사합니다.
단점
- 트랜잭션 처리, 동시 사용자 처리, 백업과 복구 등 RDBMS보다 성숙도가 낮습니다. - SQL이 없으며 대신 OQL(Object Query Language) 등의 객체 질의어를 사용합니다. - 생태계와 도구, 커뮤니티가 제한적입니다.
현재 관계형 데이터베이스와 ORM 기술이 발전하고 ORDBMS가 등장하면서 현재는 거의 사용되지 않습니다. 해당 기사에서 객체지향 데이터베이스에 대한 내용을 보실 수 있습니다.
5. 객체 관계형 데이터베이스 (Object-Relational DB)
객체지향 데이터베이스는 관계형 데이터베이스를 기반으로 하면서, 객체지향 개념을 일부 통합한 데이터베이스입니다.
사용자 정의 타입을 지원합니다. (UDT) - 주소라는 타입을 만들어 우편번호, 도로명, 상세주소를 묶어서 하나의 열로 사용할 수 있습니다. 참조 타입을 지원합니다. (REF) - 객체 간 참조 관계를 만들 수 있어, 테이블 간 Join 없이도 객체처럼 접근 가능하게 합니다. 중첩 테이블을 지원합니다. - 테이블 내부에 또 다른 테이블이 들어갈 수 있어 복잡한 구조를 자연스럽게 표현합니다. SQL3를 지원합니다. - SQL 표준 중 객체지향 기능(사용자 정의 타입, 컬렉션 타입 등)을 포함한 확장 버전입니다.
장점
-복잡한 객체의 생성, 조회, 삭제의 성능이 기존 RDB보다 월등히 우수합니다. -프로그램 내의 정보 구조와 데이터베이스 스키마 구조가 거의 유사합니다.
단점
-표준 개념이 미흡하며 ODMG 활동으로 보완중이라고 합니다.
객체 관계형 데이터베이스로는 PostgreSQL, Oracle Database 12c 등이 있습니다.
PostgreSQL은 RDBMS를 기반으로 하면서 객체지향 기능도 내장한 ORDBMS입니다.(사용자 정의 타입, 테이블 상속, 함수 오버로딩, 복합 타입, 배열 타입 등 객체지향 기능을 제공합니다.) 일반적인 상황에선 객체지향 기능을 많이 활용하지 않는 경우도 많습니다.
💡 RDB를 사용하는데도 객체지향 언어(Java, Python)과 잘 호환된다고 느꼈을 수도 있습니다. 이는 ORM 기술 덕분으로 객체지향 언어와 RDB간의 구조적 차이를 자동으로 매핑해주는 기술입니다. 대표적으로는 Java의 JPA가 있습니다.
6. NoSQL 데이터베이스 (Not only SQL DB)
NoSQL은 정형화된 테이블 구조를 따르지 않는 데이터베이스입니다. 유연한 스키마 구조를 가지고 있으며, 데이터 간의 관계를 명시적으로 정의하지 않기때문에 비정형 및 반정형 데이터를 효과적으로 처리할 수 있습니다.
정형 데이터: 행과 열이 있는 표 형태로 저장되는 데이터입니다. ex 엑셀, 데이터베이스 테이블
반정형 데이터: 구조는 있지만 고정된 스키마는 없는 데이터입니다. ex JSON, XML (필드가 자유롭게 변함)
비정형 데이터: 구조가 없고 분석하기 어려운 데이터입니다. ex 이미지, 영상, 오디오, 자유 양식 텍스트
장점
- 대용량 데이터 처리에 효율적입니다. - 데이터가 애플리케이션이 필요한 형식으로 저장되기때문에 읽기, 쓰기 속도가 빠릅니다. - 데이터 모델링이 유연합니다. (스키마가 없기에 유연합니다. 언제든지 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있습니다.) - 수직 및 수평 확장이 가능합니다.
하나의 서버의 능력을 증강하기 때문에 수직적입니다. 성능이나 용량 증가를 목적으로 하나의 서버에 램을 추가하거나 CPU를 추가합니다. 단순하지만 확장에 한계가 있고(RAM 뱅크가 꽉 차면 램을 더 꽂을 수 없습니다.), 경우에 따라 특정 제조사 전용 장비만 써야 한다는 단점이 있습니다.
하지만 어플리케이션을 수정할 필요가 없다는 장점이 있습니다.
수평 확장은기존의 서버와 같은 사양 또는 비슷한 사양의 서버 대수를 증가시키는 방법으로 처리 능력을 향샹시키는 것을 말합니다.
1개의 처리 능력을 가진 서버에 동일한 서버 4대를 더 추가하여 총 5의 처리 능력을 만드는 것입니다. 로드 밸런싱(부하 로드를 분산밸런싱 해주는 장치 또는 기술)이 필수적입니다. 어플리케이션 수정이 필요한 경우가 있지만 하드웨어 종속성이 덜합니다.
Scale-up만을 지원하는 RDB와 다르게 NoSQL DB는 Scalue-up 뿐만 아닌 Scale-out 또한 가능합니다.
단점
- ACID 트랜잭션에 제약 사항이 있습니다. - 데이터 업데이트에 오랜 시간이 소요됩니다. - 데이터의 일관성을 보장하지 않습니다.
ACID 트랜잭션은 데이터베이스 트랜잭션이 수행되도록 보장하기 위해 필요한 4가지 속성을 의미합니다.
원자성(Atomicity)
일관성(Consistency)
격리성(Isolation)
영속성(Durability)
ACID 트랜잭션을 보면 NoSQL은 트랜잭션을 사용할 수 없을 것 같지만 MongoDB 4.0 버전부터 다중 도큐먼트 ACID 트랜잭션, 4.2 버전부터 다중 컬렉션 ACID 트랜잭션 등이 추가되었습니다. 하지만 제약 사항이 존재하므로 주의해야합니다.
NoSQL은 자주 변경되고 확장되는 데이터 구조가 필요할 때 사용합니다. 또한 읽기를 위주로 하고 데이터를 자주 변경하지 않는 경우 사용하는 게 좋습니다.
ex) 인터넷에 있는 기사를 긁어오는 스크랩 코드를 구현했다면 url + @을 key로, 하나의 페이지를 value로 저장한다면 빠르고 쉽게 저장/접근이 가능합니다.
NoSQL은 데이터 저장 방식에 따라 Document DB, Wide Column DB, Key Value DB, Graph DB로 나눌 수 있습니다. 👇
1) Document DB (문서형) 문서 지향 데이터베이스로 데이터를 JSON, XML같은 문서 형식으로 저장합니다. 일반적으로 많이 알려진 NoSQl이며 문서마다 구조가 달라도 되기 때문에 유연한 저장이 가능합니다. RDB에서의 행(Row)이 하나의 문서(Document)가 되는 개념입니다. 장점 - 스키마가 유연하므로 필드 추가와 삭제가 자유롭습니다. 단점 - 문서마다 구조가 다를 수 있기 때문에 데이터 일관성 유지가 어렵습니다. 복잡한 JOIN 쿼리나 도큐먼트 간 연산이 제한적입니다. 추천 상황 - 스키마가 자주 변경되는 서비스에 사용하면 좋습니다. 로그 등 다양한 형식의 대용량 저장이 필요할 경우 사용합니다. (정확성보다 양이 중요할 경우) 종류 - MongoDB, CouchDB, Firebase Firestore, Amazon DocumentDB, Azure Cosmos DB
2) Wide Column Database (분산형) 데이터를 행과 열로 구성하지만, RDB와는 달리 열 단위로 데이터를 저장합니다. 행마다 각기 다른 값, 다른 수의 스키마를 가질 수 있습니다. 저장 예시를 보시고 이해하시면 쉬우실 겁니다. key(사용자 이름) 값에 스키마들은 각각 다르게 저장될 수 있습니다. 장점 - 쿼리 동작 속도가 매우 빠르고 확장성이 뛰어납니다. 뛰어난 확장성으로 대규모 분산 환경에 적합합니다. 빅데이터 분석에 구조가 최적화되어 있습니다. 단점 - 소규모로 사용할 때 많은 비용이 듭니다. 초기 세팅과 운영 비용이 큽니다. 추천 상황 - 대규모 데이터 수집 및 분석을 할 때 유용합니다. 시간에 따른 로그나 사용자 동작 추적에도 사용할 수 있습니다. 종류 - Apache Cassandra, HBase, Google BigTable, ScyllaDB, Vertica
3) Key Value Database key, value가 하나의 묶음으로 저장되는 단순한 구조로 빠르고 분산 저장에 용이합니다. 장점 - 동일 데이터에서 메모리를 훨씬 덜 사용합니다. 키를 통해 값을 빠르게 검색할 수 있어 응답 속도가 빠릅니다. (읽기/쓰기 빠름) 단점 - Join이 불가능합니다. 복잡한 질의 처리에는 부적합합니다. 추천 상황 - 세션 저장, 캐신 시스템 등에 많이 사용됩니다. 속도가 중요시되는 게임 순위나 실시간 피드 등에도 사용할 수 있습니다. 종류 - Redis, Amazon DynamoDB, Riak, Oracle NoSQL, Voldemort
4) Graph Database 데이터를 노드(Node)로, 데이터 간 관계를 엣지(Edge)로 표현합니다. 관계 중심의 구조로 복잡한 연결 관계를 빠르게 탐색할 수 있습니다. (엣지란 객체들의 관계를 표시해주는 관계선입니다.) 노드는 사용자, 엣지는 "팔로우한다" "친구이다" "좋아요했다" 등이 될 수 있습니다. 장점 - 노드 간 연결 관계를 즉시 탐색하므로 빠릅니다. 복잡한 관계에 대한 질의가 RDB보다 빠릅니다. 단점 - 데이터 규모가 커지면 성능 조율이 필요합니다. 수평 확장이 쉽지 않습니다. 추천 상황 - 추천 시스템이나 연관 분석, 경로 탐색시 적합합니다. (연관관계가 많은 경우 적합) SNS에서 내 친구의 친구를 찾는 질의, 연관된 데이터를 추천해주는 추천 시스템 등에 사용할 수 있습니다. 종류 - Neo4j, ArangoDB, OrientDB, TigerGraph, BlazeGraph
7. NewSQL
NewSQL은 2011년에 처음 나온 개념으로 RDB와 NoSQL을 합친 데이터베이스입니다. SQL 기반 문법을 사용합니다.
장점
- 데이터 무결성 처리를 위해 지원하는 트랜잭션 동시 제어 잠금 처리와 관련해 기존 방식과 다른 비잠금 동시성 제어를 지원합니다. - 읽기 및 쓰기 작업 모두에서 높은 성능을 제공합니다. - 시스템이 무너졌을때, 데이터를 복구하고 상태를 유지하는 기능이 있습니다. (Crash Recovery)
Sharding은 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법입니다.
ex) 전 세계의 고객 데이터를 저장하는 DB를 분산할 수 있습니다. 아시아면 샤드A, 유럽이면 샤드B... 이런식으로 저장됩니다.
단점
- 기본적으로 아키텍처가 복잡해 학습에 어려움이 있을 수 있습니다. - 성숙도가 부족합니다. - 오픈소스인 NoSQL과 비교했을 때 비용이 많이 나올 수 있습니다.
NewSQL은 고성능 트랜잭션이 필요한 경우 사용할 수 있고, 기존 RDB의 트랜잭션 JOIN SQL 등이 필요하면서도 대용량 처리와 분산 환경에 잘 맞는 시스템이 필요할 때 사용할 수 있습니다. 정보의 양이 많지는 않지만 구글 Gmail 서비스에서도 NewSQL 데이터베이스를 사용하고 있습니다. JPA에서 스패너 사용에 대한 문서입니다.
NewSQL은 Google Spanner, CockroachDB, TiDB, VoltDB 등이 있습니다.
현재 가장 많이 사용되는 RDB부터 대용량 처리에 유리한 NoSQL과 새롭게 나온 NewSQL까지 DB 종류를 정리해보았습니다.
그래서 이 데이터베이스들, 언제 어떤 걸 사용하는 게 좋을지 총정리를 해볼까요?
🗺️ DB 선택 가이드 - 총 정리
우선 SQL을 사용하는 데이터베이스와 NoSQL 중 무엇을 사용할 것인지 고르는 걸 추천드립니다. 각 종류별로 특징이 뚜렷히 나뉘기 때문에 큰 방향을 결정한 뒤 그에 속하는 세부 DB들을 선택하는 게 프로젝트에 더 적합한 DB를 고르는데 도움이 됩니다. (추천: AWS - NoSQL 설명 및 SQL DB와 비교글)
만약...
- 테이블마다 값들이 있을 수도 있고 없을 수도 있다면 (A 테이블 레코드에 이름이 있을 수도, 없을 수도 있다.)
- 업데이트보다 조회나 생성 동작이 많다면
- 한 번도 NoSQL을 사용해 본 적이 없다면
=> NoSQL DB를 추천합니다. 사실 정말 좋은 경험이라고 생각합니다. 재미도 있기 때문에 한 번 쯤 try try 해 봐야 한다고 생각합니다. 가장 자료도 많고 배포도 쉬운 MongoDB 어떠신가요?
만약...
- 무결성이 중요한 작업이라면
- 테이블 간 관계가 무척 많다면
- 안정성이 중요하다면
=> SQL DB를 추천합니다. 사실 NoSQL을 사용하면서 불안정하다고 느낀 적이 많았습니다. 역시 무결성 참 중요하다니까 느낀 적이 많았습니다. 평소 안정성을 중요하게 생각하고, 프로젝트가 부동산이나 금융 쪽처럼 무결성과 원자성이 중요한 경우는 SQL DB를 사용하는 게 좋습니다.
복잡한 쿼리를 요구하고, insert 위주 대규모 서비스인 경우에는 PostgreSQL을 추천드립니다. RDB의 대표주자 MySQL과 ORDB의 대표주자 PostgreSQL는 Join 방식 등 다양한 차이가 있고 장단이 명확하기 때문에 프로젝트에 맞는 것을 선택하는 게 중요합니다.
개인적으로 적합한 기능이 있다면 GraphDB를 사용해보고 싶습니다. 메인 DB로 가져가는 것보다 서브 DB로 사용하게 된다면 많은 이점이 있을 것 같다고 생각했습니다.
그리고 '스키마가 자주 변경되는 데이터 구조'일 때 NoSQL을 추천하는 글들이 많은데, 사실 그것또한 잘 생각해봐야 하는 것 같습니다. 오히려 스키마가 자주 변경되면 RDB를 선택하는 게 좋다고 생각하기도 합니다. RDB는 강제적으로 스키마가 변경될 때 무결성을 지켜야 하기 때문입니다. 그래서 스키마가 자주 변경된다는 이유로 NoSQL을 선택하기 보다는, '무결성'이 중요한지 여부를 따지는 게 좋을 것 같습니다.
해당 글에선 DB 종류를 정리해보고 프로젝트에서 DB를 선택하는데 도움이 될만한 글을 작성해보았는데, 많은 분들의 선택에 도움이 되었으면 좋겠습니다.
