👨‍💻MySQL SQLite MongoDB

이전에 프로젝트를 진행하면서
SQLite, MySQL, MongoDB 이렇게 3가지 데이터베이스를 사용해보았습니다.
각 데이터베이스의 스펙과 장단점을 알아보겠습니다.

🕛 MySQL

참고: https://smoh.tistory.com/m/369

Oracle에서 소유하고 있는 Open Database입니다. 웹 개발을 하신다면 쉽게 접할 수 있는 대표적인 데이터베이스 솔루션입니다.

📌특징

MySQL의 가장 큰 특징은 표준 SQL을 지키지 않는 다는 것입니다. 속도를 가장 우선순위를 두었기 때문에 읽기속도가 빠르다는 장점이 있지만, SQL을 정확히 지켜야 하는 쿼리문에서는 간혹 오류가 날 수 있기 때문입니다.

📌장점

1. 속도가 빠르다
   • 앞서 말한 것과 같이 표준 SQL 준수보다 속도에 집중했기 때문에 읽기속도가 매우 빠릅니다.
2. 가장 인기있는 오픈소스 RDBMS인 만큼, 대규모 커뮤니티를 보유하고 있습니다. 따라서 MySQL을 처음 시작한다 하더라도 가이드라인이 넘치기 때문에 시작하기 편합니다. 또한 사용자가 많은 DB인 덕분에 타사 애플리케이션이나 도구, 라이브러리까지 영향을 주었습니다.
3. 보안 수준이 높다
   • 암호 보안 수준 설정 가능
   • 루트 사용자 암호 정의
   • 사용자 별 엑세스 권한 별도 부여 가능
   • 익명 계정을 제거하고 모든 사용자가 접근할 수 있는 기본 데이터베이스를 제거하여 보안을 향상하는데 도움되는 스크립트 포함된 설치
4. 복제 기능 지원
   • 데이터 백업 솔루션 설정이 가능하여 수평적 확장에 유용
     • 안정성, 내결함성, 가용성 향상을 위해 두 개 이상의 호스트에서 정보를 공유하는 방식으로 여러 유형 복제 기능 지원

📌 단점

1. 표준 SQL을 지키지 않기 때문에 사용하지 못하는 몇가지 기능이 존재함
   • ex. FULL JOIN
2. 라이선스 및 독점 기능에 대한 제약
   • 독점 라이선스에 따라 출시된 여러 유료 상용 에디션이 존재하여 일부 기능은 해당 에디션에서만 가능함

📌총평

👍MySQL을 쓰면 좋은 경우

• 분산 작업이 필요한 경우(MySQL의 복제기능)
• 읽기 속도에 집중된 애플리케이션 개발의 경우(웹 사이트, 웹 애플리케이션)
• 속도가 빠르고, 장기적으로 봤을 때 서비스 확정성에 용이하다ㅣ

👎MySQL을 쓰면 안 좋은 경우

• SQL준수가 엄격한 경우
• 동시성과 대용량 데이터 볼륨이 요구되는 경우.
  - 일반적으로 읽기가 많은 작업에서 잘 수행되지만, 읽기와 쓰기가 동시에 작업이 일어나는 경우 문제가 될 수 있음. -> PostgreSQL과 같은 다른 RDBMS가 더 나은 선택이 될 수 있다.

🕐SQLite

📌특징

1. 독립형 파일 기반의 RDBMS. 따라서 시스템이 충돌하거나 정전이 발생해도 DB의 트랜잭션은 ACID를 준수합니다.
2. Serverless Database
3. DB에 엑세스 하는 모든 프로세스가 데이터베이스 디스크 파일을 직접 읽고 쓰게 됩니다.
4. 오픈 RDBMS

📌장점

1. 매우 가볍다. 사용하는 공간은 경우에 따라 다르지만 600kb미만의 공간을 차지
2. 완전히 독립형으로 작동하기 위해 시스템을 설치해야하는 외부 종속성이 없음
3. 사용자 친화적 RDBMS. 즉시 사용될 수 있는 Zero-configuration데이터베이스
   • serverless인 만큼 시작, 재시작, 중지 과정이 없고, SQLite설치에서 애플리케이션 통합까지의 과정이 간소화됨
4. 이식성이 뛰어남
   • 데이터를 분리된 파일의 커다란 배치로 저장하는 다른 일반적 DB와 달리, SQLite는 파일에 전체 DB가 저장됨디렉터리 계층의 어디에나 위치할 수 있으며, 이동식 디스크 또는 파일 전송 프로토콜을 통해서도 전송이 가능

📌 단점

1. 동시성 제한
   • 동시에 여러 프로세스가 SQLite에 액세스하고 쿼리가 가능하지만, 주어진 시간에 하나의 프로세스만이 데이터베이스를 변경할 수 있음.
   • 즉, SQLite는 대부분의 다른 임베디드 DB 관리 시스템보다 더 큰 동시성을 지원하긴 하지만, MySQL PostgreSQL만큼 클라이언트-서버 구조를 가진 RDBMS만큼은 아니다
2. 사용자 관리가 없다.
   • DB시스템은 DB 및 테이블에 대해 사전에 정의된 액세스 권한을 가진 사용자에게 권한을 주지만 SQLite는 디스크 파일 형태이기에, 액세스 가능한 권한은 오직 기본 운영 체제의 일반적인 액세스 권한 뿐이 없다. 따라서 특별한 액세스 권한이 요구되는 환경에서는 좋지 못하다.
3. 2번의 이유로 보안에 취약하다.
   • SQLite와 같은 serverless DB보다 서버를 사용하는 것이 클라이언트 애플리케이션 버그로 부터 더 안전할 수 있습니다.
     • ex. 서버를 사용하는 경우
       - 클라이언트의 잘못된 포인터는 서버 메모리의 손상을 일으킬 수 없습니다.
     • 서버는 하나의영구적인 프로세스이기 때문에, 클라이언트-서버 DB는 serverless DB 더 정밀하게 액세스를 제어할 수 있습니다. 이 말은 serverless DB보다 더 세밀한 잠금기능과 동시성을 제공할 수 있다는 말과 같습니다.

📌총평

👍SQLite 쓰면 좋은 경우

• 임베디드 애플리케이션에 적합.
  - 이식성이 좋고, 향 후 확장이 필요없기 때문
• 애플리케이션이 파일을 디스크에 직접 읽고 써야하는 경우
  - SQLite를 사용하는 것이 SQLite에서 제공되는 추가 기능과 SQL 단순성을 위해 더 유용
• 테스트 환경에서 유용.
  - 애플리케이션 배포 전 추가 서버를 구성할 필요가 없기에 DBMS로 빠르게 테스팅 하기에 좋다

👎SQLite 쓰면 안 좋은 경우

• 많은 데이터가 요구되는 경우
  - SQLite는 디스크 드라이브와 파일 시스템이 지원한다면 140TB까지 기술적으로 지우너이 가능 하나, SQLite 공식문서는 어떤 DB든 1TB에 근접해지면 중앙 집중형 클라이언트-서버 DB에 보관할 것을 권장합니다.
• 높은 볼륨 쓰기가 요구되는 경우
  - 지정된 시간에 하나의 쓰기 작업만 수행할 수 있으므로, 처리량이 크게 제한됨
• 네트워크 액세스가 필요한 경우
  - serverless이기에 직접적인 네트워크 액세스가 불가함

🕐MongoDB

📌특징

1. NoSQL 오픈소스 Database이다. 그 중에서도 도큐먼트 DB

   NoSQL ?

   Not Only SQL 또는 Nonrelational Operational Database SQL의 약자
   표준화된 구조적 질의 언어가 없는 데이터베이스 또는 관계를 갖지 않는 데이터베이스들을 뜻합니다.
   키-벨류 / 도큐먼트 / 컬럼 패밀리 / 그래프 DB 등 4가지 종류의 NoSQL이 있습니다.

   Document DB ?

   필드와 값 형태로 구성된 데이터를 JSON 포맷으로 관리하는 데이터베이스 입니다.

2. NoSQL의 특징을 가집니다.

   • 유연성: 스키마 선언 없이 필드의 추가 및 삭제가 자유로은 Schema_-less구조
   • 확장성: 스케일 아웃에 의한 서버 확장이 용이
   • 고성능: 고성능의 대용량 데이터를 처리
   • 가용성: 여러 대의 백업 서버 구성이 가능하여 장애 발생 시에도 무중단 서비스가 가능

3. 비 트랜잭션

   • 트랜잭션을 지원하지 않고 각각의 도큐먼트 단위로 처리
   • 트랜잭션을 지원하지 않으므로 Commit 또는 Rollback 개념이 없으며 모두 AutoCommit으로 처리

4. 데이터 입출력시 JSON(JavaScript Object Notation)형태, 데이터 저장시 BSON(JSON데이터를 이진 형식으로 인코딩한 포멧)형식을 사용

   • 검색속도가 빠름
   • 인코딩 디코딩이 필요함

5. 고유의 DML(데이터 조작어)를 갖고있다(Javascript 기반 명령어 & JSON을 도큐먼트 인자로 사용)

6. 별도의 스키마 선언 없이 도큐먼트의 필드를 자유롭게 추가 및 삭제할 수 있다(유연성 & 스키마 메타데이터가 없다)

📌장점

1. Schema-less로 얻는 유연성
   • 다양한 데이터 저장 가능
   • 데이터 모델의 유연한 변화 가능(모델 변경, 필드 확장 용이
2. Read/Write 성능이 뛰어남
3. Scale out 구조
   • 많은 데이터 저장 가능
   • 장비 확장이 간단
4. JSON 구조: 데이터 직관적 이해 가능
5. 사용방법이 쉽고, 개발이 편리함

📌 단점

1. 데이터 업데이트 중 장애 발생 시, 데이터 손실 가능
2. 많은 인덱스 사용시, 충분한 메모리 확보 필요
3. 데이터 공간 소모가 RDB<S에 비해 많음(비효율적인 Key 중복 입력)
4. 복잡한 JOIN 사용시 성능 제약, 데이터 일관성 보장이 안됨
5. 메모리 공간을 오버할 경우 급격한 성능 저하
6. CASCADE 못함

📌총평

👍MongoDB 쓰면 좋은 경우

• 쌓아놓고 삭제가 없는 데이터의 경우 적합(수정x)
• 충분한 메모리를 갖고있고, Read/Write에 특화된 경우
• 대량의 데이터를 빠른 속도로 처리하는 경우(빅데이터 산업)
• 로그성 데이터를 기록하는 경우
• 압도적인 퍼포먼스가 필요한 경우(RDB대비 100배 이상 차이, memory mapped file)

👎MongoDB 쓰면 안 좋은 경우

• 트랜잭션이 필요한 애플리케이션에는 부적합(금융권, 결제, 회원정보 등)
• 엄격한 데이터 타입 검사나 연관관계가 중요한 경우
• 데이터 무결성이 중요한 사례