i can do ik!

DBMS

• DataBase Management System
• 사용자의 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성하고 데이터베이스를 관리해 주는 소프트웨어

SQL

• Strucured Query Language
• 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어.
• 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안되었다.

RDBMS

• RDBMS는 DBMS앞에 R이 붙는다. Relational의 약자로 관계형 데이터베이스 관리 시스템을 의미한다.
• RDBMS는 RDB를 관리하는 시스템이며 RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 데이터 베이스.
• RDBMS는 다른 테이블들과 관계를 맺고 모여있는 집합체로 이해할 수 있다.
• 관계를 나타내기 위해 외래키(foreign key)를 사용한 테이블 간 Join이 가능하다는 게 RDBMS의 가장 큰 특징.

NoSQL

• Not Only SQL
• RDB 현태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술.
• RDBMS와 달리 테이블 간 관계를 정의하지 않는다.
• 데이터 테이블은 그냥 하나의 테이블이며 따라서 일반적으로 테이블 간 Join도 불가능.
• 빅데이터 등장으로 데이터와 트래픽이 기하급수적으로 증가함에 따라 RDBMS의 단점인 성능 향상시키기 위해 등장
• 데이터 일관성은 포기하되 비용을 고려하여 여러 대의 데이터에 분산하여 저장하는 Scale-Out을 목표로 등장.
• NoSQL 하면 가장 유명한 Document 기반의 MongoDB를 떠올리지만 MongoDB는 NoSQL의 한 종류로 NoSQL은 하기와 같이 다양한 형태의 저장기술을 지원하고 있다.
• 저장기술은 RDBMS 스키마에 맞추어 데이터를 관리해야 된다는 한계를 극복하고 수평적 확장성(Scale-out)을 쉽게 할 수 있다는 장점

Key-Value Database

• Key-Value Database는 데이터가 Key와 Value의 쌍으로 저장된다. Key는 Value에 접근하기 위한 용도로 사용되며, 값은 어떠한 형태의 데이터라도 담을 수 있다. 심지어는 이미지나 비디오도 가능하다. 또한 간단한 API를 제공하는 만큼 질의의 속도가 굉장히 빠른 편이다.
• 대표적인 NoSQL Key-Value Model로는 Redis, Riak, Amazon Dynamo DB 등이 있다.

Document Database

• Documnet Database 데이터는 Key와Document의 형태로 저장된다. Key-Value 모델과 다른 점이라면 Value가 계층적인 형태인 도큐먼트로 저장된다는 것이다. 객체지향에서의 객체와 유사하며, 이들은 하나의 단위로 취급되어 저장된다. 다시 말해 하나의 객체를 여러 개의 테이블에 나눠 저장할 필요가 없어진다는 뜻이다. 
• 주요한 특징으로는 객체-관계 매핑이 필요하지 않다. 객체를 Document의 형태로 바로 저장 가능하기 때문이다. 또한 검색에 최적화되어 있는데, 이는 Ket-Value 모델의 특징과 동일하다. 단점이라면 사용이 번거롭고 쿼리가 SQL과는 다르다는 점이다. 도큐먼트 모델에서는 질의의 결과가 JSON이나 xml 형태로 출력되기 때문에 그 사용 방법이 RDBMS에서의 질의 결과를 사용하는 방법과 다르다. 
• 대표적인 NoSQL Document Model로는 MongoDB, CouthDB 등이 있다.

Wide Column Database

• Column-family Model 기반의 Database이며 이전의 모델들이 Key-Value 값을 이용해 필드를 결정했다면, 특이하게도 이 모델은 키에서 필드를 결정한다. 키는 Row(키 값)와 Column-family, Column-name을 가진다. 연관된 데이터들은 같은 Column-family 안에 속해 있으며, 각자의 Column-name을 가진다. 관계형 모델로 설명하자면 어트리뷰트가 계층적인 구조를 가지고 있는 셈이다. 이렇게 저장된 데이터는 하나의 커다란 테이블로 표현이 가능하며, 질의는 Row, Column-family, Column-name을 통해 수행된다.
• 대표적인 NoSQL Column-family Model로는 HBase, Hypertable 등이 있다.

Graph Database 

• Graph Model Model에서는 데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장하는 Database입니다. 개체와 관계를 그래프 형태로 표현한 것이므로 관계형 모델이라고 할 수 있으며, 데이터 간의 관계가 탐색의 키일 경우에 적합하다. 페이스북이나 트위터 같은 소셜 네트워크에서(내 친구의 친구를 찾는 질의 등) 적합하고, 연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 데이터베이스로도 적합하다.
• 대표적인 NoSQL Graph Model로는 Neo4J가 있다.

RDBMS 장단점

장점

• RDBMS는 위에서 설명을 하였듯이 정해진 스키마에 따라 데이터를 저장하여야 하므로 명확한 데이터 구조를 보장하고 있다. 
• 또한 관계는 각 데이터를 중복없이 한 번만 저장할 수 있다.

단점

• 테이블간테이블 간 관계를 맺고 있어 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리가 만들어질 수 있다.
• 성능 향상을 위해서는 서버의 성능을 향상 시켜야하는 Scale-up만을 지원합니다. 이로 인해 비용이 기하급수적으로 늘어날 수 있다.
• 스키마로 인해 데이터가 유연하지 못합니다. 나중에 스키마가 변경 될 경우 번거롭고 어렵다.

NoSQL 장단점

장점

• NoSQL에서는 스키마가 없기 때문에 유연하며 자유로운 데이터 구조를 가질 수 있습니다. 언제든 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있다.
• 데이터 분산이 용이하며 성능 향상을 위한 Saclue-up 뿐만이 아닌 Scale-out 또한 가능하다.

단점

• 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경 될 경우 수정을 모든 컬렉션에서 수행을 해야 한다.
• 스키마가 존재하지 않기에 명확한 데이터 구조를 보장하지 않으며 데이터 구조 결정가 어려울 수 있다.

Transaction

• 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위.
• 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미한다.
• 데이터베이스 시스템에서 병행 제어 및 회복 작업 시 처리되는 작업의 논리적 단위.
• 사용자가 시스템에 대한 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업단위.
• 하나의 트랜잭션은 Commit되거나 Rollback된다.

Transaction 성질

Atomicity(원자성)

• 트랜잭션의 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다.
• 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.

Consistency(일관성)

• 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환한다.
• 시스템이 가지고 있는 고정요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 한다.

Isolation(독립성, 격리성)

• 둘 이상 트랜잭션이 동시에 병행 실행 될 때 어느 하나의 트랜잭션 실행중 다른 트랜잭션의 연산이 끼어들 수 없다.
• 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.

Durability(지속성, 영구성)

• 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다.

Transaction 연산

Commit연산

• Commit 연산은 한개의 논리적 단위(트랜잭션)에 대한 작업이 성공적으로 끝났고 데이터베이스가 다시 일관된 상태에 있을 때, 이 트랜잭션이 행한 갱신 연산이 완료된 것을 트랜잭션 관리자에게 알려주는 연산이다.

Rollback연산

• Rollback 연산은 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 이 트랜잭션의 일부가 정상적으로 처리되었더라도 트랜잭션의 원자성을 수현하기 위해 이 트랜잭션이 행한 모든 연산을 취호하는 연산이다.
• Rollback시에는 해당 트랜잭션을 재시작하거나 폐기한다.

MySQL의 Transaction

• MySQL의 InnoDB 엔진은 기본 설정이 트랜잭션이 미지원 상태이다.
• autocommit모드(줄단위 Commit)가 켜져있는 상태이기 때문에 트랜잭션이 미지원 상태이다.
• 트랜잭션이 지원되게 하려면 기본 설정을 autocommit모드를 False로 변경 해야한다.

INDEX

인덱스란 지정한 컬럼들을 기준으로 메모리 영역에 일종의 목차를 생성하는 것.

예를 들어 책 뒷편에 '색인'이 인덱스의 역할과 동일하다.

insert, update, delete의 성능을 희생하고 대신 select(Query)의 성능을 향상시킨다.

단 update, delete의 성능이 느리지만, 인덱스가 있으면 update, delete를 하기 위해 데이터를 조회하는것은 빠르다.

INDEX 장단점

INDEX 장점

• 검색 속도가 빨라질 수 있다. (모든 상황은 아니다.)
• 쿼리의 부하가 줄어들어 시스템 전체의 성능이 향상 된다.

INDEX 단점

• INDEX가 데이터베이스 공간을 차지. 약 10%정도의 추가 공간이 필요.
• 첫 인덱스 생성시 시간이 많이 소요될 수 있다.
• 데이터 변경 작업이 자주 일어날 경우 오히려 성능이 저하 될 수 있다.

효율적인 INDEX

• WHERE 절에 자주 등장하는 컬럼을 인덱스로 설정
• ORDER BY 절에 자주 등장하는 컬럼을 인덱스로 설정
• SELECT 절에 자주 등장하는 컬럼들을 잘 조합해서 인덱스로 설정
• JOIN이 자주 사용되는 열에 인덱스를 생성하는 것이 좋다.

데이터 중복도

• 중복도가 낮다 - 분포도가 높다 - Cardinality가 높다 - 나타나는 데이터의 종류가 많다.
• 중복도가 높다 - 분포도가 낮다 - Cardinality가 낮다 - 나타나는 데이터의 종류가 적다.

INDEX 사용시 주의점

• INDEX를 막 생성하면 SELECT는 빨라지지만 INSERT, UPDATE는 느려진다.
• WHERE절에 사용되어야 INDEX를 주로 사용한다.
• INDEX를 자주 사용하지 않으면 성능 저하를 초래할 수 있다.  
• INDEX의 데이터 중복도가 높으면 성능 저하를 초래할 수 있다. 
• JOIN절에 자주 사용되는 열에는 INDEX의 효율이 좋다.
• 사용하지 않는 INDEX는 제거하는 것이 효율적이다. 

NOT LIKE

특정 문자가 포함되어 있지 않는 데이터를 검색할 때 사용.

-- 특정 문자를 포함하지 않는 데이터 검색
SELECT * FROM [테이블명] WHERE [컬럼명] NOT LIKE '%특정 문자열%';

NOT LIKE 두개 이상 사용할 때

기본 검색 방식은 동일.

-- 특정 문자를 전부 포함하지 않는 결과
SELECT * FROM [테이블명] WHERE ([컬럼명] NOT LIKE '%특정문자1%' AND [컬럼명] NOT LIKE '%특정문자2%');

• MySQL/Maria DB를 사용하다 보면 한글 깨짐 현상이 종종 발생하게 된다.
• 영문이 아닌 한글만 깨지는 경우에는 보통 2가지 방법으로 해결이 가능.

my.ini 파일 소스 추가

[client]
default-character-set=utf8
 
[mysql]
default-character-set=utf8
 
[mysqld]
collation-server = utf8_unicode_ci
init-connect='SET NAMES utf8'
character-set-server = utf8

해당 소스를 my.ini 파일에 추가 한다.

데이터베이스 기본 인코딩 셋 변경

alter database [데이터베이스명] default character set UTF8;

해당 데이터베이스 이름을 입력 하고 쿼리문을 실행 한다.

EXISTS

• 한 테이블이 다른 테이블과 외래키(FK)와 같은 관계가 있을 때 유용.
• 조건에 해당하는 ROW의 존재 유무와 이후 더 수행하지 않음.
• 일반적으로 SELECT절까지 가지 않기에 IN에 비해 속도나 성능면에서 더 좋음.
• 메인 쿼리 -> EXISTS 쿼리

※ IN절은 IN 쿼리 -> 메인 쿼리의 순서. 이 부분이 IN절과 EXISTS절의 가장 큰 차이

-- 검색어1 또는 검색어2인 값만 출력 
WHERE [컬럼명] EXISTS ('검색어1', '검색어2'); 

-- SELECT문의 조건만 출력 
WHERE [컬럼명] EXISTS (SELECT문);

NOT EXISTS

NOT EXISTS는 EXISTS와 반대로 해당 조건을 제외하고 출력 할 때 사용.

-- 검색어1 또는 검색어2이 아닌 값만 출력 
WHERE [컬럼명] NOT EXISTS ('검색어1', '검색어2'); 

-- SELECT문의 조건이 아닌 값만 출력 
WHERE [컬럼명] NOT EXISTS (SELECT문);

EXPLAIN

SELECT문을 수행하는 방법에 대해 정보를 얻기 위한 수단.

EXPLAIN SELECT * FROM TABLE_NAME

EXPLAIN 결과

id: 1 
select_type: SIMPLE 
table: TABLE_NAME 
type: ALL 
possible_keys: NULL 
key: NULL 
key_len: NULL 
ref: NULL 
rows: 1
Extra: NULL

• id : 쿼리 안에 있는 각 select 문에 대한 순차 식별자. 이순서대로 select문이 실행된다고 생각하면 된다.
• select_type : select 문의 유형.
  • SIMPLE : 서브쿼리나 'union'이 없는 가장 단순한 select문.
  • PRIMARY : 가장 바깥에 있는 select문.
  • DERIVED : from 문 안에있는 서브쿼리의 select문.
  • SUBQUERY : 가장 바깥의 select 문에 있는 서브쿼리.
  • DEPENDENT SUBQUERY : 기본적으로 SUBQUERY와 같은 유형, 가장 바깥 select문에 의존성을 가진 서브쿼리.
  • UNION : union 문의 두번째 select문.
  • DEPENDENT UNION : 바깥 쿼리에 의존성을 가진 union문의 두번째 select문.
• table : 참조되는 테이블.
• type : MySQL이 어떤식으로 테이블들을 조인하는지를 나타내는 항목. 이는 매우 중요한데, 이 타입을 분석함으로써 어떤 인덱스가 사용여부를 알 수 있고, 어떤식으로 쿼리가 튜닝되어야하는지에 대한 insight를 제공하기 때문.
  • system : 0개 또는 하나의 row를 가진 테이블.
  • const : 테이블에 조건을 만족하는 레코드가 하나일 때, 상수 취급
  • eq_ref : primary key나 unique not null column으로 생성된 인덱스를 사용해 조인을 하는 경우.  const 방식 다음으로 빠른 방법.
  • ref : 인덱스로 지정된 컬럼끼리의 '=' , '<=>' 와 같은 연산자를 통한 비교로 수행되는 조인이다
  • index_merge : 2개 이상의 인덱스를 이용해 각각의 검색 결과를 만들어낸 후에 그 결과를 병합하는 처리 방식
  • unique_subquery : 오직 하나의 결과만을 반환하는 'IN'이 포함된 서브쿼리의 경우이다.
  • index_subquery : unique_subquery와 비슷하지만 여러개의 결과를 반환한다
  • range : 특정한 범위의 rows들을 매칭시키는데 인덱스가 사용된 경우이다. BETWEEN이나 IN, '>', '>=' 등이 사용될 때이다.
  • all : 조인시에 모든 테이블의 모든 row를 스캔하는경우이다. 물론 성능이 가장 좋지 않다.
• possible_keys : 테이블에서 row를 매핑시키기 위해 사용 가능한 (사용하지 않더라도) 키를 보여준다.  
• key : 실제 쿼리 실행에 사용된 key 목록. 이 항목에는 possible_keys 목록에 나타지 않은 인덱스도 포함 될 수 있다.
• ref : key column에 지정된 인덱스와 비교되는 column 또는 constants를 보여준다.
• rows : 결과 산출에 있어서 접근되는 record의 숫자. 조인문이나 서브쿼리 최적화에 있어서 중요한 항목.
• Extra : 실행계획에 있어서 부가적인 정보를 보여준다.
  • distinct : 조건을 만족하는 레코드를 찾았을 때 같은 조건을 만족하는 또 다른 레코드가 있는지 검사하지 않음.
  • not exist : left join 조건을 만족하는 하나의 레코드를 찾았을 때 다른 레코드의 조합은 더 검사하지 않는다.
  • range checked for each record : 최적의 인덱스가 없는 차선의 인덱스를 사용한다는 의미.
  • using filesort : mysql이 정렬을 빠르게 하기 위해 부가적인 일을 한다.
  • using index : select 할때 인덱스 파일만 사용
  • using temporary : 임시 테이블을 사용. order by 나 group by 할때 주로 사용
  • using where : 조건을 사용한다는 의미.

CONCAT()

CONCAT()은 둘 이상의 문자열이나 컬럼 값을 순서대로 합쳐서 반환해 주는 함수.

단, 합쳐지는 문자열이나 컬럼값이 NULL을 포함한다면 반환되는 값도 NULL.

SELECT CONCAT(문자열1, 문자열2 [, 문자열3 ...]) FROM 테이블명

CONCAT() 예제

SELECT CONCAT('AA','BBB',' ','CCC','DD') FROM TABLE_NAME;
SELECT CONCAT('999','.','111') FROM DUAL;
SELECT CONCAT('AA','BBB',NULL,'CCC','DD') FROM TABLE_NAME;

#AABBB CCCDD
#999.111
#NULL

CONCAT_WS()

CONCAT_WS()는 둘 이상의 문자열이나 컬럼 값을 반복되는 구분자를 넣고 순서대로 합쳐서 반환해 주는 함수.

CONCAT()와는 다르게 NULL을 포함하여도 NULL로 반환하지 않는다.

SELECT CONCAT_WS(구분자, 문자열1 [, 문자열2, 문자열3 ...]) FROM 테이블명

CONCAT_WS() 예제

SELECT CONCAT_WS(',','AA','BBB','CCC','DD') FROM DUAL;
SELECT CONCAT_WS(',','AA','BBB',NULL,'CCC','DD') FROM DUAL;
SELECT CONCAT_WS(',','111','222','333') FROM DUAL;

#AA,BBB,CCC,DD
#AA,BBB,CCC,DD
#111,222,333