Database : Database란?
Database
Database가 존재하기 이전에는 파일 시스템을 이용하여 데이터를 관리하였습니다.(현재도 부분적으로 사용되고 있습니다.) Database는 데이터를 각각의 파일 단위로 저장하며 이러한 일들을 처리하기 위한 독립적인 애플리케이션과 상호 연동이 되어야 합니다.
Database의 기본개념
- 데이터의 집합 (a Set of Data)
- 여러 프로그램들의 통합된 정보들을 저장하고 운영할 수 있는 공용 데이터의 집합
- 효율적으로 저장, 검색, 갱신할 수 있도록 데이터 집합들끼리 연관시키고 조직화
Database의 특성
- 실시간 접근성(Real-time Accessability) : 사용자의 요구를 즉시 처리
- 계속적인 변화(Continuous Evolution) : 정확한 값을 유지하려고 삽입·삭제·수정 작업 등을 이용해 데이터를 지속적으로 갱신
- 동시 공유성(Concurrent Sharing) : 사용자마다 서로 다른 목적으로 사용하므로 동시에 여러 사람이 동일한 데이터에 접근하고 이용
- 내용 참조(Content Reference) : 저장한 데이터 레코드의 위치나 주소가 아닌 사용자가 요구하는 데이터의 내용, 즉 데이터 값에 따라 참조
DBMS(DataBase Management System)
다수의 사용자가 데이터베이스 내의 데이터에 접근할 수 있도록 해주는 소프트웨어입니다. DMBS가 등장하기 이전에는 개발자들이 파일의 데이터를 저장하고 읽어들이는 등의 기능을 모두 구현해야 했습니다. 이러한 불편함을 해결하기 위한 여러 가지 노력의 결과로 DMBS라는 소프트웨어가 등장하게 되었습니다.
DBMS에 대한 최초의 개념은 IBM에서 논문으로 나왔고 최초의 구현은 Oracle에서 하였습니다.
DBMS의 특징
-
데이터의 독립성
- 물리적 독립성 : Database 사이즈를 늘리거나 성능 향상을 위해 데이터 파일을 늘리거나 새롭게 추가하더라도 관련된 응용 프로그램을 수정할 필요가 없습니다.
- 논리적 독립성 : Database는 논리적인 구조로 다양항 응용 프로그램의 논리적 요구를 만족시켜줄 수 있습니다.
-
데이터의 무결성
여러 경로를 통해 잘못된 데이터가 발생하는 경우의 수를 방지하는 기능으로 데이터의 유효성 검사를 통해 데이터의 무결성을 구현하게 됩니다.
-
데이터의 보안성
인가된 사용자들만 Database나 Database 내의 자원에 접근할 수 있도록 계정 관리 또는 접근 권한을 설정함으로써 모든 데이터에 보안을 구현할 수 있습니다.
-
데이터의 일관성
연관된 정보를 논리적인 구조로 관리함으로써 어떤 하나의 데이터만 변경했을 경우 발생할 수 있는 데이터의 불일치성을 배제할 수 있습니다. 또한 작업 중 일부 데이터만 변경되어 나머지 데이터와 일치하지 않는 경우의 수를 배제할 수 있습니다.
-
데이터 중복 최소화
Database는 데이터를 통합해서 관리함으로써 파일 시스템의 단점 중 하나인 자료의 중복과 데이터의 중복성 문제를 해결할 수 있습니다.
Database의 종류
Database는 1960년대에 시작된 이후 계층 및 Network Database로 시작하여 1980년대에 객체 지향 Database를 거쳐 오늘 날에는 SQL 및 NoSQL Database와 Cloud Database로 발전해 왔습니다.
관계형(Relational) Database
키(key)와 값(value)들의 간단한 관계를 테이블화 시킨 매우 간단한 원칙의 데이터베이스입니다. 미리 정의된 범주에 맞는 데이터가 있는 테이블 집합으로 구성됩니다. SQL(Structured Query Language)은 관계형 데이터베이스에 대한 표준 사용자 및 응용 프로그램 인터페이스입니다. 관계형 데이터베이스는 확장하기 쉽고 모든 기존 응용 프로그램을 수정할 필요 없이 원래 데이터베이스 생성 후에 새 데이터 범주를 추가할 수 있습니다.
분산(Distributed) Database
분산 데이터베이스는 데이터베이스의 일부가 여러 물리적 위치에 저장되고 처리가 네트워크의 다른 지점 간에 분산되거나 복제되는 데이터베이스입니다.
분산 데이터베이스는 동종 또는 이기종일 수 있습니다. 동종 분산 데이터베이스 시스템의 모든 물리적 위치에는 동일한 기본 하드웨어가 있으며 동일한 운영 체제 및 데이터베이스 응용 프로그램을 실행합니다. 이기종 분산 데이터베이스의 하드웨어, 운영 체제 또는 데이터베이스 응용 프로그램은 위치마다 다를 수 있습니다.
장점
- 조직 구조의 반영 : 기업 등 부문별로 데이터베이스를 놓고 그들을 통합하여 분산 데이터베이스로 할 수 있습니다.
- 국소 자율성 : 각 부서는 자체 보유한 데이터를 제어할 수 있습니다.
- 중요한 데이터의 보호 : 화재 등의 재해가 발생했을 때 데이터가 분산되어 있으면 전체를 한 번에 잃는 것을 예방할 수 있습니다.
- 성능 향상 : 자주 사용하는 데이터는 가까운 위치에 있으면서, 전체가 병렬적으로 작동하기 때문에 데이터베이스의 부하 분산이 가능합니다. 일부가 과부하 되어도 분산 데이터베이스 전체에 미치는 영향이 작습니다.
- 경제성 : 거대한 고성능 컴퓨터보다 동일한 정도의 성능을 발휘하는 소형 컴퓨터 네트워크 쪽이 쌉니다.
- 모듈화 : 분산 데이터베이스의 다른 모듈(시스템)에 영향을 주지 않고 개별 시스템을 갱신, 추가, 삭제할 수 있습니다.
- 높은 신뢰성의 트랜잭션 : 복제(replication)로 이루어지기 때문입니다.
하나의 사이트에 장애가 발생해도 전체 기능은 손상되지 않습니다. 모든 거래는 ACID 특성에 따릅니다.
ACID : 원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 지속성(Durability)의 약어로 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 말합니다.
단점
- 복잡성 : 투명성을 보장하기 위해 구축에는 간단한 데이터베이스보다 기량을 요합니다. 또한 구성하는 시스템은 동일한 기종 것은 아닙니다. 접속이 끊어졌을 때의 동작도 고려할 필요가있습니다. 결합을 여러 시스템간에 할 경우 성능 저하가 발생할 수도 있습니다.
- 비용 : 시스템의 규모와 복잡성이 증가함에 따라 관리 비용도 증가합니다.
- 보안 : 개별 사이트의 보안을 확보하고, 사이트 간 네트워크의 보안도 확보하지 않으면 전체에 대한 보안을 말할 수 없습니다.
- 무결성 보장의 어려움 : 분산 데이터베이스 무결성을 보장하려면 많은 네트워크 자원이 필요합니다.
- 미성숙한 기술 : 분산 데이터베이스는 미성숙한 분야이며, 경험적 지식의 축적이 적습니다.
- 표준의 부족 : 중앙 DBMS를 분산 DBMS로 변환하기위한 도구와 방법론은 아직 존재하지 않습니다.
- 데이터베이스 설계의 복잡성 : 일반 데이터베이스 설계 이외에, 데이터를 각 사이트에 어떻게 배치하거나 복제를 어떻게 할 것인가 등 설계시에 고려해야 할 사항이 늘어납니다.
- 추가 소프트웨어를 필요로합니다.
- 운영 체제가 분산 컴퓨팅을 지원해야 합니다.
- 동시성 제어가 중요합니다.
클라우드(Cloud) Database
클라우드 데이터베이스는 하이브리드 클라우드, 퍼블릭 클라우드 또는 프라이빗 클라우드에서 가상화된 환경을 위해 최적화되거나 구축된 데이터베이스입니다. 클라우드 데이터베이스는 사용량에 따라 스토리지 용량 및 대역폭 비용을 지불할 수 있는 기능과 같은 이점을 제공하며, 고가용성과 함께 온디맨드 확장성을 제공합니다.
클라우드 데이터베이스는 또한 기업이 SaaS(Software-as-a-Service) 배포에서 비즈니스 애플리케이션을 지원할 수 있는 기회를 제공합니다.
클라우드 서비스를 제공하는 기업 입장에서는 안정성이 제일 중요하기 때문에 최근에는 분산 데이터베이스를 이용해 클라우드 서비스를 제공하는 경우가 많은 것 같습니다.
SaaS(Software-as-a-Service) : 사용자에게 클라우드 서비스 제공업체가 관리하는 소프트웨어 애플리케이션을 제공하는 서비스를 말합니다.
퍼블릭 클라우드 : 일반적으로 최종 사용자가 소유하지 않은 IT 인프라에서 생성되는 클라우드 환경을 말합니다.(AWS, Google Cloud 등)
프라이빗 클라우드 : 단일 최종 사용자 또는 그룹의 전용 클라우드 환경으로, 실행 시 대개 해당 사용자 또는 그룹의 방화벽으로 보호됩니다. 완전히 독립적인 액세스 권한이 있는 단일 고객만 기반 IT 인프라를 독점적으로 사용하는 경우 이러한 모든 클라우드를 프라이빗 클라우드라고 정의합니다.
하이브리드 클라우드 : 단일 IT 환경처럼 보이지만, 실제로는 여러 환경이 LAN(Local Area Network), WAN(Wide Area Network), VPN(Virtual Private Network) 및/또는 API를 통해 연결된 형태입니다. (2개 이상의 퍼블릭 클라우드, 1개 이상의 프라이빗 클라우드 + 1개 이상의 퍼블릭 클라우드 …)
NoSQL Database
NoSQL 데이터베이스는 대규모 분산 데이터 세트에 유용합니다. NoSQL 데이터베이스는 관계형 데이터베이스가 해결하도록 구축되지 않은 빅 데이터 성능 문제에 효과적입니다. 조직이 클라우드의 여러 가상 서버에 저장된 데이터 또는 비정형 데이터의 큰 청크를 분석해야 할 때 가장 효과적입니다.
종류마다 쓰기/읽기 성능 특화, 2 차 인덱스 지원, 오토 샤딩(DBMS에서 데이터를 나누는 것이 아니고 데이터베이스 자체를 분할하는 방식) 지원 같은 고유한 특징을 가집니다. 대량의 데이터를 빠르게 처리하기 위해 메모리에 임시 저장하고 응답하는 등의 방법을 사용합니다. 동적인 스케일 아웃(서버를 여러 대 추가하여 시스템을 확장하는 방법)을 지원하기도 하며, 가용성을 위하여 데이터 복제 등의 방법으로 관계형 데이터베이스가 제공하지 못하는 성능과 특징을 제공합니다.
In-Memory Database
데이터 스토리지의 메인 메모리에 설치되어 운영되는 방식의 DBMS입니다.
인메모리 데이터베이스는 디스크에 최적화된 데이터베이스보다 더 빠른데 그 까닭은 디스크 접근이 메모리 접근보다 느리기 때문이며, 이 데이터베이스는 내부 최적화 알고리즘이 더 단순하며 더 적은 CPU 명령을 실행합니다. 메모리의 데이터에 접근하면 데이터를 조회할 때 검색 시간이 줄어들기 때문에 디스크보다 더 빠르고 더 예측 가능성 성능을 제공합니다.
데이터 양의 빠른 증가로 데이터베이스 응답 속도가 떨어지는 문제를 해결할 수 있는 대안이 In-Memory Database입니다. 전형적인 디스크 방식은 디스크에 저장된 데이터를 대상으로 쿼리를 수행하지만, 인 메모리 방식은 메모리상에 색인을 넣어 필요한 모든 정보를 메모리상의 색인을 통해 빠르게 검색할 수 있기 때문입니다.
인메모리 데이터 스토리지의 잠재적인 기술적 문제는 RAM의 휘발성입니다. 구체적으로 말해 전원이 소실될 경우나 고의적인 상황 등에서 휘발성 RAM 안에 저장된 데이터는 손실됩니다. 비휘발성 RAM 기술의 도입으로 인메모리 데이터베이스는 전력 손실에도 완전한 속도로 데이터를 유지할 수 있게 되었다고 합니다.
유명한 NoSQL인 RediS가 In-Memory Database 방식 입니다.
객체지향(Object-oriented) Database
객체 지향 프로그래밍 언어를 사용하여 생성된 항목은 종종 관계형 데이터베이스에 저장되지만 객체 지향 데이터베이스는 이러한 항목에 적합합니다.
객체 지향 데이터베이스는 작업보다는 객체, 논리보다는 데이터를 중심으로 구성됩니다. 예를 들어, 관계형 데이터베이스의 멀티미디어 레코드는 영숫자 값과 달리 정의 가능한 데이터 객체일 수 있습니다.
소프트웨어 개발자가 스스로 데이터 형과 메서드(이 두 조합은 객체 지향에서 말하는 객체의 클래스에 해당)를 자유롭게 정의하여 데이터베이스를 개발할 수 있는 데이터베이스 관리 시스템 (DBMS)입니다.
관계 모델을 기반으로 RDBMS 또는 SQL-DBMS는, SQL과 같은 데이터베이스 언어 표준에 의해 사전에 규정된 제한된 데이터 형식 집합에 속하는 데이터에 대해서는 효과적으로 처리할 수 있지만, 객체 지향의 사고방식을 채용한 ORDBMS에서는 소프트웨어 개발자가 스스로 데이터 형식과 방법을 자유롭게 정의하여 데이터베이스를 개발하여 DBMS에 통합시킬 수 있습니다. ORDBMS 기술의 목표는 소프트웨어 개발자에게 문제 영역을 생각하는 수준까지 데이터베이스 설계의 추상화 수준을 높이는 것입니다.
기존의 RDBMS에 외부 소프트웨어 도구를 추가하여 ORDBMS와 비슷한 기능을 제공하게 할 수도 있는데, 이러한 외부 소프트웨어 도구를 객체 관계 매핑 시스템이라고 부릅니다.
그래프(Graph) Database
그래프 지향 데이터베이스 또는 그래프 데이터베이스는 그래프 이론을 사용하여 관계를 저장, 매핑 및 쿼리하는 NoSQL 데이터베이스 유형입니다. 그래프 데이터베이스는 기본적으로 노드와 에지의 모음으로, 각 노드는 엔터티를 나타내고 각 에지는 노드 간의 연결을 나타냅니다.
그래프 데이터베이스는 상호 연결 분석을 위한 인기가 높아지고 있습니다. 예를 들어, 회사는 그래프 데이터베이스를 사용하여 소셜 미디어에서 고객에 대한 데이터를 마이닝할 수 있습니다.
그래프 데이터베이스는 종종 그래프 데이터베이스 분석을 위한 선언적 프로그래밍 언어 및 프로토콜인 SPARQL을 사용합니다. SPARQL에는 SQL이 수행할 수 있는 모든 분석을 수행할 수 있는 기능이 있으며 의미론적 분석, 관계 검사에도 사용할 수 있습니다. 따라서 구조화된 데이터와 구조화되지 않은 데이터가 모두 있는 데이터 세트에 대한 분석을 수행하는 데 유용합니다. SPARQL을 사용하면 사용자가 관계형 데이터베이스에 저장된 정보는 물론 FOAF(friend-of-a-friend) 관계, PageRank 및 최단 경로에 대한 분석을 수행할 수 있습니다.
데이터 마이닝 : 데이터 안에서 체계적이고 자동적으로 통계적 규칙이나 패턴을 찾아내는 것
FOAF(friend-of-a-friend) : 사람과 사람간의 관계(Relationship)를 의미적으로 표현하기 위한 RDF(웹상의 자원의 정보를 표현하기 위한 XML 규격) 명세
PageRank : 페이지의 중요도를 웹페이지 간 연결관계에 기반을 두고 측정한 지표
Database 용어
Database에서 사용하는 용어에 대하여 알아보겠습니다.
테이블(Table)
- 행과 열로 이루어진 데이터의 집합을 테이블
- 엑셀의 표와 유사한 모양
- 일반적인 Database에서는 행과 열만 있으면 테이블이라고 하지만,
관계형 Database에서는 여기에 특별한 제약을 추가해서릴레이션(Relation)이라고 부름 - 아래 조건을 충족하는 테이블만이 릴레이션이 될 수 있기 때문에 모든 릴레이션은 테이블이지만, 모든 테이블이 릴레이션인건 아님
- 모든 값은 유일한 값을 가짐
- 하나의 릴레이션에서 중복되는 행이 존재하면 안됨
행(Row == Record == Tuple)
- 테이블을 구성하는 데이터들 중 가로로 묶은 데이터셋을 의미 (column 값의 조합)
- 일반적으로 행은 한 객체에 대한 정보를 가지고 있음
- 릴레이션에서 같은 값을 가질 수 없음
- 행의 수는 Cardinality라고 함
열(Column == Attribute)
- 테이블을 구성하는 데이터들 중 세로로 묶은 데이터셋을 의미(단일 종류의 데이터)
- 특정 데이터 타입 및 크기를 가지고 있음
- 일반적으로 열은 그 테이블의 속성을 의미하며 열을 구성하는 값들은 같은
도메인(Domain)으로 되어 있음 - 열의 수는 Degree라고 함
도메인(Domain)
- Database에서 필드(Field)에 채워질 수 있는 값의 집합(범위)
- 예를 들어, 도메인이 1에서 10사이의 정수인 속성의 필드에 11이나 -1처럼 도메인을 벗어나는 값 또는 “고양이”처럼 아예 자료형이 다른 값이 들어갈 수 없음
필드(Field)
- 행과 열의 교차점으로 데이터를 포함할 수 있고, 없을 때는 NULL값을 가지고 있음
스키마(Schema)
- Database의 구조를 전반적으로 기술한 것을 말함
- 구체적으로 Database를 구성하는 데이터 레코드의 크기, 키의 정의, 레코드 간의 관계 등을 정의한 것을 말함
- 사용자의 관점에 따라
외부 스키마,개념 스키마,내부 스키마로 구분 - DBMS는 외부 스키마에 명세된 사용자의 요구를 개념 스키마 형태로 변환하고, 이를 다시 내부 스키마 형태로 변환
외부 스키마
- 사용자의 입장에서 정의한 Database의 논리적 구조를 말함
- 데이터들을 어떤 형식, 구조, 화면을 통해 사용자에게 보여줄 것인가에 대한 명세를 말하며 하나의 Database에는 여러 개의 외부 스키마가 있을 수 있음
- 일반 사용자에게는 질의어를 이용해 DB를 쉽게 사용할 수 있도록 하고 응용 프로그래머는 언어를 사용해서 DB에 접근
사용 주체나 응용 프로그램에 따라서 같은 데이터가 같은 구조로 저장되어 있는 Database를 바라보는 관점이 다를 수 있습니다. 즉, SELECT 쿼리를 던졌을 때, 볼 수 있는 표를 외부 스키마의 대표적인 예라고 생각하면 됩니다. (하지만 외부 스키마가 조회된 결과값을 의미 하는 것은 아닙니다.)
개념 스키마
- 조직체 전체를 관장하는 입장에서 DB를 정의한 스키마를 말합니다.
- DB에 대한 모든 논리적 구조를 기술하기 때문에 Database에 하나만 존재하며, 통상 스키마라고 하면 개념 스키마를 일컫는다.
DA가 설계한 DB 구조를 생각하면 됩니다. ERD(Entity Relationship Diagram)가 대표적인 예라고 할 수 있습니다.
내부 스키마
- Database가 어떻게 저장 장치에 저장될 지에 대한 명세를 말합니다.
- 물리적인 저장 장치와 Database 간의 관계를 정의하므로 시스템 프로그래머나 시스템 설계자가 보는 관점의 스키마입니다.
DA가 아닌 오라클사의 Database 개발자 관점에서의 스키마라고 할 수 있습니다.
키(Key)
키는 검색, 정렬 시 Tuple을 구분할 때, 기준이 되는 Attribute를 말합니다.
후보키(Candidate Key)
Tuple을 유일하게 식별하기 위해 사용하는 Attribute의 부분 집합을 말합니다. 즉, 기본키로 사용할 수 있는 속성들을 말합니다. 아래의 2가지 조건을 만족하여야 합니다.
- 유일성 : Key로 하나의 Tuple을 유일하게 식별할 수 있음
- 최소성 : 꼭 필요한 속성으로만 구성
모든 릴레이션은 반드시 하나 이상의 후보 키를 가져야 합니다. (기본키가 필수이기 때문)
<학생> 릴레이션에서 학번이나 주민번호는 다른 레코드를 유일하게 구별할 수 있는 기본키로 사용할 수 있으므로 후보키가 될 수 있습니다. 즉, 기본키가 될 수 있는 키들을 후보키라 하는 것입니다.
기본키(Primary Key)
- 후보키 중 선택한 Key를 말합니다.
- 한 릴레이션에서 기본키로 특정 튜플을 유일할게 구별할 수 있어야 합니다.
- NULL 값을 가질 수 없고, 중복될 수 없다는 특징이 있습니다.
<학생> 릴레이션에는 학번이나 주민 번호가 기본키가 될 수 있고, <수강> 릴레이션에는 학번+과목명으로 조합해야 기본키가 만들어질 수 있습니다. <수강> 릴레이션에서는 학번 속성과 과목명 속성은 개별적으로 기본키로 사용할 수 없습니다. 다른 튜플들과 구별되지 않기 때문입니다.
대체키( == 보조키, Alternate Key)
후보키 둘 이상일 때, 기본키를 제외한 나머지 키를 말합니다.
<학생> 릴레이션에서 학번을 기본키로 정하면 주민번호는 대체키가 됩니다.
슈퍼키(Super Key)
- 한 릴레이션 내에 있는 속성들의 집합으로 구성된 키로서 릴레이션을 구성하는 모든 튜플 중 슈퍼키로 구성된 속성의 집합과 동일한 값을 나타내지 않습니다.
- 유일성은 만족하지만, 최소성은 만족하지 못하는 키를 말합니다.
<학생> 릴레이션에서는 학번, 주민번호, 학번+주민번호, 학번+주민번호+성명 등으로 슈퍼키를 구성할 수 있습니다.
또한, 여기서 최소성을 만족시키지 못한다는 말은 학번+주민번호+성명이 슈퍼키인 경우, 3개의 속성 조합을 통해 다른 튜플과 구별이 가능하지만, 성명 단독적으로 슈퍼키를 사용했을 때는 구별이 가능하지 않기 때문에 최소성을 만족시키지 못하는 것입니다.
외래키(Foreign key)
- 관계(Relation)를 맺고 있는 릴레이션 R1,R2에서 릴레이션 R1이 참조하고 있는 릴레이션 R2의 기본키와 같은 R1 릴레이션의 속성을 외래키라고 합니다.
- 외래키는 참조되는 릴레이션의 기본키와 대응되어 릴레이션 간에 참조 관계를 표현하는 데 중요한 도구로 사용된다.
- 외래키로 지정되면 참조 테이블의 기본키에 없는 값은 입력할 수 없습니다.
<수강> 릴레이션이 <학생> 릴레이션을 참조하고 있으므로, <학생> 릴레이션의 학번은 기본키이고, <수강> 릴레이션의 학번은 외래키입니다. 즉, 각 릴레이션의 입장에서 속성은 기본키가 되기도 하고, 외래키가 되기도 합니다.
Database의 성능?
Database의 성능 이슈는 디스크 I/O 를 어떻게 줄이느냐에서 시작됩니다. 디스크 I/O 란 디스크 드라이브의 플래터(원판)을 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽는 것을 의미합니다. 이 때 데이터를 읽는데 걸리는 시간은 디스크 헤더를 움직여서 읽고 쓸 위치로 옮기는 단계에서 결정됩니다. 즉 디스크의 성능은 디스크 헤더의 위치 이동 없이 얼마나 많은 데이터를 한 번에 기록하느냐에 따라 결정된다고 볼 수 있습니다.
그렇기 때문에 순차 I/O 가 랜덤 I/O 보다 빠를 수 밖에 없습니다. 하지만 현실에서는 대부분의 I/O 작업이 랜덤 I/O 입니다. 랜덤 I/O 를 순차 I/O 로 바꿔서 실행할 수는 없을까? 라는 생각에서부터 시작되는 Database 쿼리 튜닝은 랜덤 I/O 자체를 줄여주는 것이 목적이라고 할 수 있습니다.
참고 : https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Database
https://github.com/WooVictory/Ready-For-Tech-Interview
https://github.com/WeareSoft/tech-interview/blob/master/contents/db.md
https://coding-factory.tistory.com/77
https://searchdatamanagement.techtarget.com/definition/database
https://www.redhat.com/ko/topics/cloud-computing/public-cloud-vs-private-cloud-and-hybrid-cloud
댓글남기기