"AWS Big Data Technology Fundamentals - 모듈 2: 데이터베이스 아키텍처"의 학습노트다.
개요
마법의 은탄환은 없다. 빅 데이터가 모든 문제를 해결해주지 못한다. 현장에서는 (간단한 서비스라고 하더라도) 3개 이상의 데이터베이스 모델을 섞어서 사용한다. 빅 데이터를 제대로 활용하기 위해서는 다양한 데이터베이스들의 특징들을 알고 있어야 한다.
관계형 데이터베이스 시스템
RDBMS(Relational Database Management System, RDBMS)는 IBM의 에드거 F, 커드가 도입한 관계형 모델을 기반으로 하는 데이터베이스 관리 시스템이다. 빅 데이터시대가 되면서 RDBMS와 다른 데이터베이스 관리 시스템들이 늘어나고 있기는 하지만, 여전히 인터넷 서비스에서의 핵심적인 데이터베이스 모델로 사용하고 있다.
관계형 데이터베이스를 살펴보기 전에 가장 원시적인 데이터 타입인 Flat data를 살펴볼 필요가 있겠다. 플랫 데이터는 ","로 구분된 csv 파일 이나 공백문자로 구분된 데이터를 의미한다.
출판사를 예를 들어보자. 출판사는 고객이 어떤 책을 좋아하는지를 기록으로 남기고 이를 분석해서 중장기 사업계획을 수립하기를 원한다. 그래서 아래와 같은 간단한 설문지를 만들기로 했다.
고객이름 :
Email :
주소 :
나이 :
성별 :
좋아하는 장르 :
올해 읽은 책 갯수 :
이 설문지를 이용해서 성별, 나이, 지역별로 선호 장르를 알 수 있을 것이다. 고객 입장에서는 아주 간단한 설문조사이지만, 이걸 집계해야 하는 출판사직원 입장에게는 쉽지 않을 것이다. 아래와 같은 설문조사가 나왔다고 가정해보자.
이름
Email
주소
나이
성별
장르
올해 읽은 책
홍길동
hong@example.com
광주
23
M
자연과학
5
고길동
go@example.com
경기도 광주
32
F
컴퓨터
12
아무개
amg@example.com
서울
스물일곱
남자
괴기소설
2
김기리
kim@example.com
성남
33
자기관리
14
주소를 보자. 광주는 경기도 광주일까, 광주 광역시일까. 경기도 광주로 집계를 하려면 어떻게 해야 할까. 성별을 빠트린 사람도 있다. 장르의 경우에도 괴기소설 이라는 장르와 별 관련 없는 정보를 넣은 사람도 있다. 이 데이터를 체계적으로 관리해서 정보를 뽑아내야 하는 직원은 상당한 노가다를 뛰어야 할 것이다.
관계형 데이터베이스를 이용하면 이런 문제를 해결 할 수 있다.
비슷한 부류의 필드를 묶어서 분리된 몇개의 테이블을 만든다. 테이블 분류는 "어떤 정보를 분석할지"에 따라 달라진다. 이 경우 성별, 나이, 지역별 분석이 중요하므로 이를 기준으로 4개 정도의 테이블을 만든다. 주소는 지역을 명확히 할 수 있도록 "도/시"로 필드를 나눠야 할 것이다.
테이블이 여러개로 나눠지면, 이들의 관계를 설정할 수 있는 key가 필요하다. 이렇게 테이블의 관계를 설정 하기 위해서 사용하는 key를 primary key라고 한다. 이름은 중복될 수 있으므로 primary key로 사용 할 수 없다. Email이라면 primary key로 할 수 있을텐데, Email 대신에 "유일한 ID"를 만들어서 primary key로 사용하기로 했다.
이렇게 만들어진 테이블은 ID를 기준으로 아래와 같은 연결을 가지게 될 것이다.
도시, 유저 프로필, 소설 장르와 같이 비슷한 성격을 가진 필드로 구성된 몇 개의 테이블이 만들어졌다. 이 테이블들은 primary key인 "ID"로 관계가 맺어진다. 예를 들어 경기도 광주시를 주소지로 하는 유저를 찾으면 ID=2로 유저 테이블에서 검색 할 수 있을 것이다.
그리고 각 테이블의 필드타입도 명확하게 정의 한다. 즉
ID는 숫자(integer)이며 중복할 수 없다.
이름은 문자열이며 빈 값이면 안된다.
성별은 M과 F둘 중 하나여야 한다. 둘 중 하나이므로 bool 타입을 사용 할 수도 있을 것이다.
나이는 반드시 숫자여야 한다.
등이다. 실제 테이블을 설계 할 때는 문자열 길이, 숫자의 크기 등을 세부적으로 설정할 수 있다. 이 데이터베이스의 구조는 아래와 같이 나타낼 수 있다.
데이터베이스의 열을 튜플 혹은 레코드라고 한다. 레코드는 필드로 구성되며, 이 필드들은 고유의 속성을 가진다. 데이터베이스를 구성하는 모든 데이터들은 "ID"를 통해서 관계(relation)가 맺어진다. 이제 데이터베이스 관리자는 "질의어(query)"로 원하는 정보를 찾을 수 있다. 예를들어 "광주 광역시에 거주하는 나이 20~30 사이의 성인들이 좋아하는 장르"와 같은 질의어를 만들 수 있을 것이다. 마케터는 이 데이터로 부터, 광주 광역시에 거주하는 20~30대 독자의 수와 이들이 선호하는 장르 정보를 바탕으로 판매도서를 선정할 수 있을 것이다.
SQL - 구조화 질의 언어
이렇게 데이터베이스를 레코드와 속성, 관계로 표준화된 구조를 설계했다. 이제 데이터를 저장하고, 조작/검색해야 하는데, 이를 위한 표준화된 언어가 필요했다. 이렇게 만들어진 언어가 SQL 이다.
SQL은 관계형 포댈과 튜플해석이라는 이론적 기초로부터 파생됐다. C, C++, Python과 같은 프로그래밍 언어적 특성을 가지지만 데이터베이스의 저장/조작/검색에 특화됐다. 지금은 거의 모든 RDBMS에서 사용하고 있는 언어다. SQL을 사용하는 주요 플랫폼들을 정리했다.
MySQL
MS Access
Oracle
Sybase
Infomix
Postgres
SQL Server
Amazon RDS
Amazon Aurora
SQLite
데이터베이스 관리자와 개발자들은 SQL을 이용해서 데이베이스를 정의하고, 값을 저장하거나 검색 혹은 수정할 수 있다. SQL 문법은 표준이기 때문에, 플랫폼에 상관없이 동일한 문법을 사용 할 수 있다.
SQL 문법은 아래 세가지로 대별된다.
데이터 정의 언어(DDL : Data Definition Language). 데이터베이스의 형식을 정의하거나, 삭제, 수정하는 등의 작업을 위한 구문을 제공한다. CREATE, DROP, ALTER, TRUNCATE을 사용한다.
데이터 조작 언어(DML : Data Manipulation Language). 데이터의 검색,삽입,수정,삭제 구문을 제공한다. SELECT, INSERT, UPDATE, DELETE를 사용한다. 가장 많이 사용하는 구문이다.
데이터 제어 언어(DCL : Data Control Language). 데이터에 대한 접근,소유권을 제어하기 위한 구문을 제공한다. 권한부여(GRANT), 박탈(REVOKE), 연결(CONNECT), 삽입(INSERT), 수정(UPDATE), 삭제(DELETE)에 대한 권한을 제어할 수 있다.
데이터 정의 언어을 이용해서 테이블을 만드는 예제다.
CREATE TABLE user (
id INTEGER PRIMARY KEY,
email VARCHAR(32) NOT NULL,
name VARCHAR(32) NOT NULL,
country VARCHAR(20)
)
유저의 정보를 저장하기 위한 "user"라는 이름을 가지는 테이블을 만들었다. 이 테이블은 id, email, name, country 4개의 필드를 가지고 있다. id를 기본 키로 설정했다. email과 name, country는 문자열을 저장할 수 있으며, 각각 32 바이트와 20바이트의 크기를 허용하고 있다. email과 name은 NOT NULL 속성을 설정해서, 반드시 값을 입력하도록 하고 있다.
데이터 조작 언어를 이용해서 user 테이블에 데이터를 입력하는 예제다.
INSERT INTO user VALUES(1, 'yundream@gmail.com', 'yundream', 'kr');
ACID
ACID는 SQL과 함께 관계형데이터베이스의 주요 이점 중 하나다.
A(Atomicity), 원자성 : 트랜잭션이 부분적으로 실행되다가 중단되지 않는 것을 보장한다. 예를 들어 자금 이체는 성공할 수도 있고 실패할 수도 있지만, 보내는 것은 성공 하고 받는 것은 실패해서는 안될 것이다. 즉시 "송신자 계좌의 금액감소"와 "수신자 계좌의 금액 증가"가 한동작으로 이루어져야 한다.
C(Consistency), 일관성 : 트랜잭션이 성공적으로 완료되면, 데이터베이스의 상태는 언제나 일관적으로 유지되야 한다.
I(Isolation), 격리성 : 트랜잭션이 수행될 때, 다른 트랜잭션의 연산작업이 끼어들지 못한다. 즉 트랜잭션 밖에서는 중간단계의 데이터를 볼 수 없다.
D(Durability), 영속성 : 성공적으로 수행된 트랜잭션은 영구히 반영되야 한다. 시스템문제, DB 일관성 체크 등을 하더라도 유지되야 한다. 보통 모든 트랜잭션 로그를 남겨서, 시스템 장애가 발생하더라도 발생전으로 되돌릴 수 있게 하고 있다. 이를 위해서 트랜잭션은 로그에 모든 기록이 남긴 뒤에 commit 하도록 한다.
대부분의 관계형 데이터베이스는 ACID를 준수한다. 하지만 모든 데이터베이스에 ACID가 필요한 것은 아니다. ACID는 데이터의 완전성과 무결을 보장할 수 있지만 이를 구현하기 위해서는 많은 비용이(성능의 희생) 들어간다. 그래서 ACID의 일부분을 포기하거나 다른 방식으로 ACID를 만족하면서 성능과 같은 다른 부분을 잇점을 얻는 데이터베이스 시스템이 만들어지게 된다.
NoSQL
그리하여 SQL과 ACID를 축으로 하는 관계형데이터베이스 시스템과는 다른 성격의 데이터베이스 시스템들이 등장한다. 이들을 NoSQL 데이터베이스 시스템이라고 한다.
NoSQL은 무엇인가
NoSQL은 Not SQL 혹은 Not Only SQL이라고 부른다. NoSQL이 주는 느낌 때문에, SQL을 사용하지 않는 데이터베이스를 의미하는 것으로 생각 할 수 있겠는데, 보통 NoSQL은 분산 환경에 적합하게 설계된 비관계형 데이터베이스를 의미하는 경우가 많다.
사용하기 편한 SQL과 완벽한 데이터 관리를 보장하는 ACID를 제공하는 관계형데이터베이스가 있는데, NoSQL이라는 새로운 데이터베이스를 사용할 필요가 있는지 의문이 들 것이다.
NoSQL이 등장한 이유는 인터넷 서비스가 확장되고, 데이터의 양과 종류가 기존의 관계형데이터베이스로는 감당할 수 없게(혹은 감당할 수 있지만 효율적이지 않거나 많은 비용을 투자해야 하거나) 되면서다. 분산 처리 시스템이 도입이 되고, 성능과 가용성이 중요시되자 ACID와는 다른 모델이 필요하게 됐다. 그래 성능과 가용성을 위해서 ACID의 C와 I를 포기하고 대신 "BASE"라는 모델을 도입한다.
Basically Available : 가용성(Available)를 중요시 한다.
Soft-state : 사용자가 관리하지 않으면 데이터가 expire될 수도 있으며
Eventually consistency : 지금 당장이 아닌 언젠가 다른 시점에 데이터가 일관성을 가진다.
ACID
BASE
강한 Consistency
약한 Consistency
Commit 우선
Availability 우선
완벽해야 한다.
완벽하기 위해 노력은 하겠다.
관계형 데이터베이스와 NoSQL 데이터베이스의 차이를 예제로 살펴보자. 아래와 같은 관계형 데이터베이스가 있다고 가정해보자.
필드의 데이터 타입이 엄격하게 제한되므로 가격에 "expensive"라거나 "100달러"와 같은 문자열이 들어간다면, 데이터 입력에 실패 할 것이다.
NoSQL에서는 테이블에 대해서 신경을 쓸 필요가 없다. NoSQL은 (모든 NoSQL이 그런건 아니지만) 데이터를 문서형태로 저장을 한다. 보통 JSON을 많이 사용하는데, 테이블의 한 행에 해당하는 레코드를 "문서"라고 하며, 문서의 모음을 컬랙션이라고 부른다.
NoSQL은 테이블 형식이 엄격하게 적용되는 관계형 테이트베이스와 달리 임의의 문서가 저장될 수 있다. 예를들어 위 데이터베이스에 제품 바코드를 추가해야 할 경우 관계형 데이터베이스는 "ALTER TABLE"로 테이블에 필드를 반드시 추가해야 한다.
ALTER TABLE product ADD barcode CHAR(32);
하지만 NoSQL은 그냥 barcode가 포함된 문서를 그대로 사용하면 된다. 이러한 특성을 schemaless 하다고 한다. MongoDB, ElasticSearch, DynamoDB, CouchBase등의 NoSQL 솔류션이 schemaless다. 아래는 NoSQL 데이터 예제다.
{
"ID": 581912,
"Product": "무선 토스터",
"Manufacturer": "Useless Goods.Inc",
"Price": 99.99,
"Unit": "ea",
"barcode": "18170998192",
"review": [
{ "date": "2018/01/03 12:16", "text":"가격도저렴하고, 제품도 좋습니다. 조금만 더 예뻣으면"},
{ "date": "2018/01/02 12:16", "text":"윗분 말씀대로 디자인이 좀 그렇습니다. 하지만 가격을 생각하면..."}
]
}
barcode 외에 리뷰도 포함했다. Schemaless는 NoSQL의 주요 이점 중 하나다.
NoSQL 데이터베이스 타입
NoSQL은 SQL 표준을 따르지 않고 현대의 다양한 인터넷 서비스 데이터를 처리하기 위한 데이터베이스 "제품군"이다. 이들 제품군은 대략 5가지 데이터베이스 유형으로 분류 할 수 있다.
Key-Value Databases
키-값(Key-Value) 저장소 혹은 키-값 데이터베이스는 맵이나 사전과 같이 키가 컬렉션의 하나의 값과 연관되는 간단한 데이터베이스다. 이 관계를 키-값쌍(Key-value pair)라고 한다.
각 키값쌍에서 키는 파일 이름, URI, email, 해시와 같은 임의의 문자열이 될 수 있다. 값으로는 이미지, 사용자 환경설정, 파일과 같은 어떤 종류의 데이터든 사용할 수 있다. 일반적으로 쿼리언어를 사용하지 않으며 대신, get, put, delete등의 명령을 이용해서 데이터를 저장, 검색, 업데이트한다.
Key
Value
K1
AAA,BBB,CCC
K2
AAA,DDD
K4
AAA,2,01/01/2015
K5
3,ZZZ,5623
Document Orientated Databases
문서지향 데이터베이스(Document orientated databases)는 문서에 데이터를 저장한다. 사용자 레코드나 상거래 제품, 진료기록과 같은 데이터를 문서에 저장한다. 문서형식은 HTML, XML, JSON을 사용한다. JSON이 늘어나는 추세다. 문서지향 데이터베이스는 문서의 ID가 키인 키-값(Key-Value)패턴으로 저장한다. 많은 제품들이 MapReduce 연산을 지원하며, javascript를 사용해서 데이터를 질의한다. 완전한 HTTP/REST API를 제공하기도 한다. 아래는 대표적인 문서지향 데이터베이스 솔류션들이다.
Couchbase
CouchDB
MongoDB
Riak
In-Memory Databases
인메모리 데이터베이스는 데이터를 디스크가 아닌 메모리에 저장해서 검색속도를 최적화한다. 메모리는 디스크보다 빠른 읽기/쓰기를 제공하지만 데이터지속성을 보장하지 않을 수 있다. 컴퓨터가 리셋될 경우 모든 데이터가 손실될 수 있지만 복제, 스냅샷, 트랜잭션 로깅등의 방법을 처리해서 데이터의 지속성을 확보할 수 있다. 대부분의 인메모리 데이터베이스들은 키-값 저장소로 사용된다.
Memcached
Redis
Riak
VoltDB
Column Store Databases
행에 데이터를 저장하는 대신, 컬럼에 데이터를 저장한다. 컬럼 접근 방식은 Ad-Hoc 쿼리와 데이터 집계 처리에 이점이 있다.
Apache HBase
Cassandra
Google's BigTable
Graph Databases
데이터는 그래프 구조에 저장되며, 빠른 쿼리와 조회에 최적화되어 있다. 그래프 데이터베이스는 다른 DB와 달리 인접요소에 대한 저장소의 포인터를 가지고 있으므로 인덱스 조회가 필요하지 않다. 각 데이터 항목은 노드라고 하며, 속성을 포함한다. 노드간의 연결을 엣지(Edges)라고 한다. 아래와 같은 데이터베이스들이 있다.
InifiniteGraph
Neo4J
OrientDB
관계형 데이터베이스와 NoSQL 데이터베이스 비교
데이터베이스 모델
관계형 데이터베이스는 SQL 언어를 이용해서 데이터를 조작하고 구조화 한다. SQL은 복잡한 쿼리에 유용하지만 사전정의된 스키마를 사용해아하며 데이터의 타입을 판별해야 하기 때문에 사용에 제한적일 수 있다. 데이터는 동일한 구조를 가져야 하기 때문에, 상당한 사전작업이 필요하다.
NoSQL은 구조화되지 않는 데이터에 대해서 동적 스키마를 가지고 있으며, XML, JSON, HTML 등 여러가지 방법으로 저장을 할 수 있다.
ACID
관계형 데이터베이스는 ACID를 모두 지원하며, 모든 것에 우선한다.
NoSQL은 수평확장 가능한 유연한 데이터모델을 가지고 있으며, 이를 위해서 ACID의 일부 속성을 희생하기도 한다.
성능
관계형 데이터베이스는 엄격하게 계획된 데이터베이스 구조, 쿼리, 인덱스에 따라서 성능이 달라진다. 관계형 데이터베이스에서의 성능향상은 흔히, 데이터베이스 구조의 분석과 재설계, 쿼리 분석, 적절한 인덱스의 생성에 크게 좌우된다.
NoSQL은 클러스터를 구성 수평으로 확장을 한다. 클러스터를 구성하는 각 서버들은 네트워크로 연결되기 때문에, 클러스터의 구성, 네트워크 지연시간, 호출 애플리케이션의 성능에 따라서 성능이 결정된다.
확장
관계형 데이터베이스는 "Scale-Up"으로 확장한다. 즉 더 빠른 하드웨어를 투입하는 식으로 확장한다. 분산 시스템을 구성할 수 있지만 쉽지않고 제한적이다.
NoSQL은 지연시간을 늘리지 않으면서 처리량을 향상하기 위해서 저비용의 하드웨어들을 클러스터에 추가하는 방식으로 이루어진다.
API
관계형 데이터베이스는 SQL을 준수하는 쿼리를 이용 데이터를 저장, 검색한다.
NoSQL은 객체기반 API를 통해서 데이터를 조작한다. HTTP/REST API, 자바스크립트등을 사용하기도 한다.
OLTP와 OLAP
OLTP는 Online Transaction Processing의 줄임말 이다. Batch와는 반대되는 개념으로 실시간으로 데이터의 트랜잭션, 조회, 업데이트, 삭제를 수행한다. 은행창구업마나 항공사의 예약업무가 전형적인 OLTP다. 다수의 클라이언트로 부터 발생하는 요청을 즉시처리 할 수 있어야 한다.
OLAP는 Online Analytical Processing의 줄임말이다. 다차원 정보에 직접 접근하여 대화식으로 정보를 분석하고 의사결정을 내리는 일련의 과정이다. OLTP에서 발생하는 다양한 데이터를 보고/의사결정 수단으로 삼을 수 있도록 통합하고 가공하고 분석하는 일들이 이루어진다.
데이터 웨어하우스
OLAP에서 사용 할 수 있는 "데이터 웨어하우스(Data Warehouse)"에 대해서 살펴보자.
데이터웨어 하우스(DW 혹은 DWH라고 부른다.)는 데이터로 부터 대시보드, 보고서, 분석 도구를 지원하는 역할을 한다. 데이터 웨어하우스는 하나 이상의 데이터 소스로 부터 수신되는 정보를 수집한다. 여기에는 관계형 데이터베이스와 NoSQL 데이터베이스, 로그들이 포함될 수 있으며 이들 데이터를 추출,변환,로드해서 데이터 과학자, 비지니스 분석사 의사결정자들에게 필요한 정보를 제공한다.
마케팅, 판매와 같은 운영 시스템에서 데이터가 업로드된다. 여기에는 유저행동 로그들이 포함될 수 있다.
DW에서 사용 하기 위해서, 데이터를 정제하는 작업을 한다. 주로 ETL을 사용하는데, 원시데이터에 대하 추출, 변환, 로드등의 작업을 통해서 DW에서 사용할 수 있는 데이터베이스에 저장을 한다.
DW에 저장된 데이터들은 분석가, 레포팅, 데이터 마이닝에 사용할 수 있다.
데이터 마트
데이터 마트는 데이터 웨어하우스의 서브셋이다. 데이터 웨어하우스가 전체 데이터를 통합하는데 촛점을 맞춘다면, 데이터마트는 영업, 금융, 마케팅과 같은 제한된 수의 출처에서 데이터를 가져온다. 종종조직내의 단일 부서에 의해서 구축된다. 데이터 웨어하우스의 하위세트이므로 구현이 쉽고 빠르다.
Contents
개요
관계형 데이터베이스 시스템
- 고객이름 :
- Email :
- 주소 :
- 나이 :
- 성별 :
- 좋아하는 장르 :
- 올해 읽은 책 갯수 :
이 설문지를 이용해서 성별, 나이, 지역별로 선호 장르를 알 수 있을 것이다. 고객 입장에서는 아주 간단한 설문조사이지만, 이걸 집계해야 하는 출판사직원 입장에게는 쉽지 않을 것이다. 아래와 같은 설문조사가 나왔다고 가정해보자.- 비슷한 부류의 필드를 묶어서 분리된 몇개의 테이블을 만든다. 테이블 분류는 "어떤 정보를 분석할지"에 따라 달라진다. 이 경우 성별, 나이, 지역별 분석이 중요하므로 이를 기준으로 4개 정도의 테이블을 만든다. 주소는 지역을 명확히 할 수 있도록 "도/시"로 필드를 나눠야 할 것이다.
- 테이블이 여러개로 나눠지면, 이들의 관계를 설정할 수 있는 key가 필요하다. 이렇게 테이블의 관계를 설정 하기 위해서 사용하는 key를 primary key라고 한다. 이름은 중복될 수 있으므로 primary key로 사용 할 수 없다. Email이라면 primary key로 할 수 있을텐데, Email 대신에 "유일한 ID"를 만들어서 primary key로 사용하기로 했다.
이렇게 만들어진 테이블은 ID를 기준으로 아래와 같은 연결을 가지게 될 것이다.- ID는 숫자(integer)이며 중복할 수 없다.
- 이름은 문자열이며 빈 값이면 안된다.
- 성별은 M과 F둘 중 하나여야 한다. 둘 중 하나이므로 bool 타입을 사용 할 수도 있을 것이다.
- 나이는 반드시 숫자여야 한다.
등이다. 실제 테이블을 설계 할 때는 문자열 길이, 숫자의 크기 등을 세부적으로 설정할 수 있다. 이 데이터베이스의 구조는 아래와 같이 나타낼 수 있다.SQL - 구조화 질의 언어
- MySQL
- MS Access
- Oracle
- Sybase
- Infomix
- Postgres
- SQL Server
- Amazon RDS
- Amazon Aurora
- SQLite
데이터베이스 관리자와 개발자들은 SQL을 이용해서 데이베이스를 정의하고, 값을 저장하거나 검색 혹은 수정할 수 있다. SQL 문법은 표준이기 때문에, 플랫폼에 상관없이 동일한 문법을 사용 할 수 있다. SQL 문법은 아래 세가지로 대별된다.- 데이터 정의 언어(DDL : Data Definition Language). 데이터베이스의 형식을 정의하거나, 삭제, 수정하는 등의 작업을 위한 구문을 제공한다. CREATE, DROP, ALTER, TRUNCATE을 사용한다.
- 데이터 조작 언어(DML : Data Manipulation Language). 데이터의 검색,삽입,수정,삭제 구문을 제공한다. SELECT, INSERT, UPDATE, DELETE를 사용한다. 가장 많이 사용하는 구문이다.
- 데이터 제어 언어(DCL : Data Control Language). 데이터에 대한 접근,소유권을 제어하기 위한 구문을 제공한다. 권한부여(GRANT), 박탈(REVOKE), 연결(CONNECT), 삽입(INSERT), 수정(UPDATE), 삭제(DELETE)에 대한 권한을 제어할 수 있다.
데이터 정의 언어을 이용해서 테이블을 만드는 예제다.ACID
- A(Atomicity), 원자성 : 트랜잭션이 부분적으로 실행되다가 중단되지 않는 것을 보장한다. 예를 들어 자금 이체는 성공할 수도 있고 실패할 수도 있지만, 보내는 것은 성공 하고 받는 것은 실패해서는 안될 것이다. 즉시 "송신자 계좌의 금액감소"와 "수신자 계좌의 금액 증가"가 한동작으로 이루어져야 한다.
- C(Consistency), 일관성 : 트랜잭션이 성공적으로 완료되면, 데이터베이스의 상태는 언제나 일관적으로 유지되야 한다.
- I(Isolation), 격리성 : 트랜잭션이 수행될 때, 다른 트랜잭션의 연산작업이 끼어들지 못한다. 즉 트랜잭션 밖에서는 중간단계의 데이터를 볼 수 없다.
- D(Durability), 영속성 : 성공적으로 수행된 트랜잭션은 영구히 반영되야 한다. 시스템문제, DB 일관성 체크 등을 하더라도 유지되야 한다. 보통 모든 트랜잭션 로그를 남겨서, 시스템 장애가 발생하더라도 발생전으로 되돌릴 수 있게 하고 있다. 이를 위해서 트랜잭션은 로그에 모든 기록이 남긴 뒤에 commit 하도록 한다.
대부분의 관계형 데이터베이스는 ACID를 준수한다. 하지만 모든 데이터베이스에 ACID가 필요한 것은 아니다. ACID는 데이터의 완전성과 무결을 보장할 수 있지만 이를 구현하기 위해서는 많은 비용이(성능의 희생) 들어간다. 그래서 ACID의 일부분을 포기하거나 다른 방식으로 ACID를 만족하면서 성능과 같은 다른 부분을 잇점을 얻는 데이터베이스 시스템이 만들어지게 된다.NoSQL
NoSQL은 무엇인가
{ "ID": 5167, "Product": "무선 토스터", "Manufacturer": "Useless Goods.Inc", "Price": 99.99, "Unit": "ea" }{ "ID": 581912, "Product": "무선 토스터", "Manufacturer": "Useless Goods.Inc", "Price": 99.99, "Unit": "ea", "barcode": "18170998192", "review": [ { "date": "2018/01/03 12:16", "text":"가격도저렴하고, 제품도 좋습니다. 조금만 더 예뻣으면"}, { "date": "2018/01/02 12:16", "text":"윗분 말씀대로 디자인이 좀 그렇습니다. 하지만 가격을 생각하면..."} ] }NoSQL 데이터베이스 타입
Key-Value Databases
Document Orientated Databases
In-Memory Databases
Column Store Databases
Graph Databases
관계형 데이터베이스와 NoSQL 데이터베이스 비교
데이터베이스 모델
ACID
성능
확장
API
OLTP와 OLAP
데이터 웨어하우스
데이터 마트
데이터 웨어하우스의 장점
참고
Recent Posts
Archive Posts
Tags