SQL DB와 No-SQL DB의 정의, 종류, 특징, 차이

RDB(관계형 데이터베이스, Relation Database)

- key와 value들의 간단한 관계를 테이블화 시킨 데이터 베이스

- 1970년 에드거 F.커드가 제안

 

관계형 모델

- 데이터를 column과 row(= record, tuple)를 이루는 하나 이상의 table(또는 relation)로 정리

- primary key로 각 row를 식별

- 일반적으로 table은 하나의 entity type을 대표

- row는 entity 종류의 instance를 대표

- column은 instance의 속성이 되는 값을 대표

 

RDBMS(관계형 데이터 베이스 관리 시스템, relation database management system)

- RDB를 관리하기 위한 SW 또는 System

 

종류

- Oracle의 DBMS

- MS의 MS SQL Server, MS Access

- MySQL

 

SQLite

- 파일 기반 데이터 베이스 관리 시스템

- 서버가 아니라 응용프로그램에 넣어 사용하는 비교적 가벼운 데이터 베이스

- API는 단순히 라이브러리를 호출하는 것만 존재

- 데이터를 저장하는 데 하나의 파일만 사용

- 관계형 데이터베이스에 속함

- 구글 안드로이드 OS에 기본 탑재된 DB

- C언어로 구현됨

- 소스코드를 어떤 목적으로든 자유롭게 사용 가능

- 최신 릴리즈 : 버전 3.33.0 (2020년 08월 14일)

 

SQLite VS MySQL

	SQLite	MySQL
아키텍처	- 공개 도메인에서 사용할 수 있는 오픈소스 - 서버가 없는 데이터베이스(= 임베디드 데이터베이스) - DB 엔진이 앱의 일부로 실행	- 오라클이 소유한 오픈소스 - 네트워크를 통해 상호작용을 하려면 클라이언트와 서버 아키텍처가 필요
지원하는 데이터 타입	blob, integer, null, text, real 등	tinyint, smallint, midint, int, bigint, double, float, real, number, timestamp, date, datetime, char, varchar, year, tinytext, blob, text, set, enum 등
storage 및 휴대성	- 라이브러리 크기 : 약 250KB - 정보를 한 파일에 직접 저장하므로 복사가 쉬움 - 구성이 필요하지 않고, 최소한의 자원을 사용하여 프로세스 k를 수행	- 서버 : 약 600MB - MySQL을 복사하거나 내보내기 전에 단일 파일로 압축해야함 - 대규모 DB일 경우 시간이 많이 소요
access 및 확장성	- 사용자 관리 기능이 없으므로 다중 사용자 액세스에 적합하지 않음 - 데이터베이스가 커질수록 SQLite를 사용하는 동안 메모리 요구량도 커지기 때문에 작은 데이터 베이스에 적합 - 성능최적화가 어려움	- 여러 사용자를 처리하고, 다양한 수준의 권한을 부여할 수 있는 사용자 관리 시스템 존재 - 쉽게 확장 가능, 더 큰 데이테베이스를 적은 노력으로 처리 가능
보안 및 설정 용이성	- 내장된 인증 메커니즘 없음 (누구나 DB 파일 접근 가능) - 쉽게 구성 설정 가능	- 내장된 보안기능 존재 (사용자 이름, 암호 및 SSH 인증) - 보다 더 많은 구성이 필요하며, 더 많은 설정 가이드 사용 가능
적절한 사용예	- 소규모 독립 실행형 애플리케이션 개발 - 확장성이 크게 필요하지 않은 소규모 프로젝트 -디스크에서 직접 읽고 쓸 필요가 있는 경우 - 기본 개발 및 테스트	- 앱에 대한 다중 사용자 접근 - 사용자에게 강력한 보안 및 인증 기능이 필요한 경우 - 분산 시스템 - 더 큰 데이터베이스가 필요한 앱 - 확장성이 필요한 프로젝트 - 웹 기반 응용 프로그램 - 맞춤형 솔루션 개발

NoSQL(non SQL, non relational)

- 2000년대 후반에 개발

- scaling, 빠른 쿼리, 빈번한 애플리케이션 변경 허용, 개발자의 프로그래밍 단순화를 초점으로 개발

- RDB보다 덜 제한적인 일관성 모델을 이용하는 데이터의 저장 및 검색을 위한 매커니즘

- 디자인의 단순화, 수평적 확장성, 세세한 통제가 필요하여 생겨남

- 단순 검색과 추가 작업을 위한 매우 최적화된 key-value 저장 공간

- 빅데이터와 실시간 웹 애플리케이션의 상업적 이용에 널리 쓰임

 

종류

• 와이드 컬럼 스토어: H베이스, 아큐물로, 카산드라

• 도큐먼트: 몽고DB, 카우치베이스

• 키 값: 다이나모, 리악, 레디스, 캐시, 프로젝트 볼드모트

• 그래프: Neo4J, AgensGraph, 알레그로그래프, 버투오소

 

장점

- 유연한 데이터 모델

- 수평적 확장

- 빠른 질의

- 개발자가 쉽게 사용 가능

 

단점

- ACID(atomicity, 정합성) 트랜잭션을 지원하지 않는 것

- NoSQL DB의 데이터 모델은 일반적으로 쿼리에 최적화 되어있고, 데이터 중복을 줄이는 데에는 최적화가 되어있지 않음 => SQL DB보다 클 수 있음 (그러나 스토리지가 매우 저렴하고, 일부 NoSQL DB는 압축도 지원하여 아주 사소한 단점으로 생각되는 중)

- 유형에 따라 단일 DB에서 모든 사용 사례를 달성하지 못할 수 있음 => 사용 사례를 고려해서 MongoDB와 같은 범용 DB를 선택하는 것이 더 나을 수 있음

ex) Graph DB의 범위 데이터 조회 질의 (제공하지 않음)

 

 

SQL VS NoSQL

	SQL	NoSQL
데이터 저장 모델	고정된 row와 column으로 이루어진 table	- Document : JSON document, - Key-Value - Wide-column : row와 동적인 column을 가진 table - Graph: node와 edge
개발 역사	중복 데이터를 제거하는 것에 초점을 두어 1970년 대에 개발	scaling과 애자일 방식, DevOps 수행을 통해 급변하는 애플리케이션을 위해 2000년 대에 개발
기본 목적	일반 목적	- Document: 일반 목적 - Key-value: 단순 조회 쿼리를 사용하는 대량 데이터 - Wide-column: 예측가능한 쿼리 패턴이 있는 대량의 데이터 - Graph: 연결된 데이터 간의 관계 분석 및 traversing
스키마	고정	유연
scaling	- vertical - 더 큰 서버로 확장	- horizontal -
Multi-record ACID 트랜잭션	지원	MongoDB는 지원
Joins	일반적으로 필요	일반적으로 필요하지 않음
Data와 Object Mapping	ORM(Object-relational mapping) 필요	- 대부분 ORM 필요 없음 - MongoDB의 document는 프로그래밍 언어의 data structure로 바로 매핑
종류	Oracle, MySQL, Microsoft SQL Server, and PostgreSQL	- Document: MongoDB, CouchDB - Key-value: Redis, DynamoDB - Wide-column: Cassandra, HBase - Graph: Neo4j, Amazon Neptune

 

출처

https://ko.wikipedia.org/wiki/%EA%B4%80%EA%B3%84%ED%98%95_%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4

https://ko.wikipedia.org/wiki/SQLite

https://www.sqlite.org/index.html

https://www.hostinger.com/tutorials/sqlite-vs-mysql-whats-the-difference/

https://ko.wikipedia.org/wiki/NoSQL

https://www.mongodb.com/nosql-explained/nosql-vs-sql