감자는 아직 꿈을 꾼다.

[데이터 베이스] 면접 전 한 번에 정리하기 본문

CS적 감자/데이터 베이스

[데이터 베이스] 면접 전 한 번에 정리하기

dreaming-potato 2024. 11. 24. 00:31

면접/IT역량테스트에 앞서서 CS지식을 한번에 총 정리하기 위해서 한번에 정리하기로 작성하게 되었습니다.

면접 질문의 답을 작성하기 보단 면접 질문에 나오는 내용들의 개념을 정리해서 이해함으로 외워서 답을 하는 것이 아니라 이해로 인해서 자연스럽게 나오도록 하기위해 정리하는 글입니다. 제가 공부하면서 얻은 파편화된 지식을 모아서 정리하는 용도로 한번에 다 담기위해서 노력했습니다. 잘봐주세용 

 

추가로 작성하지 않는 부분은 계속해서 업데이트하면서 작성할 예정입니다.

 

본 글은 유튜버 "쉬운 코드"님의 데이터 베이스강의를 참고하여 작성한 글입니다.

해당 강의를 들어 보는 것을 추천드립니다.

 

허락을 받고 작성하는 블로그 입니다.

 

https://www.youtube.com/@ez.

 

쉬운코드

10년차 백엔드 개발자가 배워서 남주려고 만든 채널이에요 알기 쉽게 설명합니다 함께 성장했으면 좋겠어요 :) #컴공맛집 #백엔드전문채널

www.youtube.com

 

 

목차는 "그림으로 공부하는 데이터베이스" 책의 목차를 참고했습니다.

< 목 차 >

1. 데이터베이스 기본 및 보존 

2. 데이터베이스 조작 

3. 데이터베이스 관리

4. 데이터베이스 도입 

5. 데이터베이스 운용

6. 데이터베이스 트러블과 보안

7. 데이터베이스 활용

1. 데이터베이스 기본 및 보존 

데이터베이스란 

데이터 베이스는 데이터의 저장소로 신속하게 정보를 꺼내거나 분석을 통해 새로운 정보를 얻게 도와줍니다.

등록, 정리 ,검색의 특징을 갖습니다. 등록한 데이터를 정리하고 원할때 검색해서 사용할 수 있게 해줍니다,

 

DBMS란 

데이터베이스 관리 시스템으로 사용자와 데이터베이스 사이에서 중개역할을 수행합니다.

여러가지 데이터 베이스를 관리하는 기능이 있는데 접근 권한, 검색이나 정렬, 제약 조건 설정이 가능 , 복구

 

데이터베이스 에는 일정한 규칙을 따라서 데이터가 저장되어있는데 이러한 데이터 구조를 데이터 모델이라고합니다.

데이터 모델은 계층형, 네트워크 형, 관계형으로 나뉩니다. 

과거에는 계층형과 네트워크형이 주로 있었지만, 어느 순간부턴 관계형이 대부분이 되었습니다.

 

계층형은 1개의 부모의 복수의 자식으로 뻗어나가는 구조로서 회사의 조직도와 비슷합니다.

예시로 여러팀에 소속된 직원이 있으면 데이터를 중복해서 저장해야하는 단점이 존재합니다.

복잡한 관계를 표현하기 힘들지만, 링크가 형성되어 있어서 데이터 추출은 빨랐습니다.

 

네트워크 형은 계층형의 단점을 극복하고자 여러명의 부모를 둘 수있어 계층형 보단 복잡한 관계 형성이 가능했지만, 역시 단점으로 하나의 변형이 발생하면 그 와 연관된 모든 구조가 영향을 받는 구조였습니다.

 

현재는 관계형이 주류로 사용됩니다.

 

관계형은 행과 열을 가진 2차원 테이블에 데이터를 저장하는 모델입니다. 관계형에서는 프로그램과 데이터를 독립적으로 관리하기가 편해졌습니다.

 

관계형 모델에서 관계란 무엇일까요??

수학에서의 관계는 Cartesian Product의 부분집합으로 표현합니다.

A라는 Set이 1과 2의 원소를 가지고있고 B라는 Set이 3 4 5 원소를 가지고 있으면 

A X B = { 1,3 / 1,4 / 1,5/ 2,3/ 2,4/ 2,5 } 인 것이죠. 

이렇게 두개만 있을 땐 binary relation이라고 표현하고 이 페어 들은 Cartesian Product의 부분 집합입니다.

 

2개 아닌 여러개로 확장해서 생각해보면 

n개의 Set에서의 Cartesian Product의 부분집합인 n- sub set이 관계인것이죠.

즉 수학에서의 관계는 각 set 의 원소들이 포함되어서 이루어진 튜플 인것이고 

이러한 튜플을 관계형 모델에서 잘 표현이 가능한것입니다. 

 

수학에서의 Set이 관계형 모델에서는 도메인으로 불리고, 그 도메인의 이름이 속성, attribute 가 됩니다.

예를 들어서 학생이라는 relation을 정의한다고하면, 학생의 relation안에는 이름,나이,전화번호 등의 도메인이 있을 것입니다. 도메인은 구체적으로 이름이면 student_ids : 학번 집합 , 7자리 정수 이렇게 형성됩니다.

그리고 도메인은 하나의 릴레이션에서 중복될 수 도 있겠죠. 전화번호라는 도메인은 학생의 전화번호와 부모님의 전화번호라고 동시에 중복되어서 사용될 수도있습니다. 이렇게 도메인의 역할을 구분하기 위해서 이름을 붙인게 attribute입니다.

 

즉 위에서 말한 튜플은 관계형 모델에서 테이블로 쉽게 표현이 됩니다.

도메인의 이름인 attribute가 컬럼 값이 되고, 하나의 레코드는 튜플이 되는 것입니다.

이러한 relation은 테이블 그자체가 되어, 학생이라는 이름의 테이블이 나타내는 것이고요.

 

Relation Schema 

-> STUDENT ( id ,name ,pohe ) 

릴레이션의 구조를 나타내고, 제약조건 표시

 

degree of relation 

-> attribute의 수를 차수라고 한다.

 

또한 튜플을 레코드라고도 합니다. 그리고 한칸 한칸을 필드라고 명칭하죠.

 

 

RDBMS VS Nosql VS GraphQl

 

이렇게 관계형 모델을 활용한 DBMS를 RDBMS라고 하는 것입니다.

Mysql과 Oracle등 대부분의 시중 DBMS가 RDBMS입니다.

 

장점은 뭐가 있을까요?

관계를 이용해서 데이터를 JOIN과 같은 기능으로 결합할 수 있습니다.

하지만 이것이 동시에 처리속도를 느리게 하는 원인이 되기도 하죠.

가장 중요한 장점은 데이터의 정합성입니다. 정합성은 데이터 간의 일관성을 표현하는 것으로 여러 데이터가 일관성 있게 존재되는 것. RDBMS는 이렇게 데이터의 정합성 관점에선 장점이 있습니다.

일정한 스키마로 데이터의 포맷이나 제약조건을 설정하기 때문입니다. 정규화 작업도 있고요

이런 것들이 데이터의 중복을 지양하게 만들어 갱신시 여러곳을 수정할 필요없이 한곳만 하게해줘서 갱신 비용을 줄여주기도 하죠. 이처럼 RDBMS는 데이터를 정확한 상태로 취득할 수 있다는 장점이  있습니다.

 

단점으로는 데이터가 방대해지면 복잡한 처리와 집계로 인해서 처리속도가 느려집니다.

트랜잭션의 ACID 원칙은 아주 좋은 장점이지만, 이것을 지키기 위해서 Performance에는 Trade Off가 있는 것입니다.

또한 다양한 형태의 데이터 표현이 안됩니다. JSON, XML ,그래프등의 형식이 안되고,

분산해서 처리하기가 힘듭니다. 또한 스키마가 있기에 새로운 정보를 추가할때 스키마를 변경해야되는 점이 있는것이죠.

이미 데이터가 천만건이 있는 테이블을 확장하려면 기존 데이터에 Write를 해야하고, 위험부담이 있습니다.

주로 RDBMS는 Scale - Up하는 데 최적화 되어있고 , Scale - out은 가능하지만 복잡합니다.

왜냐면 리플리케이션으로 scale - out해서 read의 부하를 줄였다고 하더라도, Write에 대한 트래픽이 몰린다면 그 역시도 샤딩이라고 하는 기법으로 분산을 해줘야되는 거죠. 이처럼 복잡한 과정이 있습니다.

이렇듯 RDBMS는 에초에 Scale-out에 유연한 것은 아닙니다.

 

그런 단점을 극복하는게 NoSql입니다.

 

NoSql

 

Not Only Sql 

말 그대로 관계형 데이터베이스를 제외한 DBMS를 가르키는 단어입니다.

등장하게 된 계기는 2000년대 초,중반 부터 인터넷이 보급되고 다양한 서비스들이 등장하면서,

트래픽이 증가해 High-throghput이 요구되고 ,빠르게 서비스를 받아 보고 싶기에 low-latency가 요구 되었습니다. 또한 수많은 사람들이 사용함으로써 데이터가 RDBMS에 딱 정의 된 규격대로 생성되는 것이 아니라 비정형 데이터의 생성도 늘어났죠. 이러한 상황속에서 NoSql 나온 것입니다.

 

MongoDB,Redis 등 다양한 것들이 Nosql에 속합니다.

 

일반적인 특징을 소개하면 

1. flexible schema 

-> 다양한 구조의 데이터를 저장할 수있습니다. 스키마가 정의 되어 있지않아서 자유롭습니다.

하지만 이렇기에 스키마 관리를 application 단계에서 개발자들이 관리를 해야합니다.

 

2. 중복 허용

-> join을 회피합니다.

그냥 한번에 모든 정보를 가져올 수 있습니다. 하지만 중복된 데이터들이 존재 할 수있기에 application레벨에서의 중복데이터를 최산의 상태로 유지하도록 처리해줘야됩니다.

 

3. Scale-Out

-> 분산 처리에 효과적입니다.

서버 여러대로 하나의 클러스터를 구성해서 사용합니다. 왜 Scale-Out에 유리할 까요?

중복허용이라는 특징 때문입니다. 중복을 허용해서 데이터를 저장하고, 정해진 스키마가 없기 때문에, 데이터를 여러 서버에 분산해서 저장해도 되는 거죠. RDBMS였다면 정규화를 거친 테이블을 따로 저장해버리면, 각 서버에 접근해서 JOIN을 수행해야하는 비용이 발생하게 되지만, NoSql에서는 중복허용된 데이터들이 존재하고, 그냥 정보가 필요하면 서버에 접근해서 읽어오면 되기에 Scale - Out이 유리합니다.

 

트랜잭션의 ACID으 일부를 포기하고 높은 처리량과 낮은 지연율을 추구합니다.

상황마다 이것은 장점일 수도, 아주 큰 단점일 수도 있습니다. 이처럼 NoSql의 특징상 데이터의 정합성을 유지하거나 , 뮤결성을 유지하는 것은 힘들기에, 또한 ACID를 보장하지 않는 다면 금융 시스템에선 consistency가 중요하기에 NoSql은 지양되겠죠. 하지만 실시간으로 처리가 요구되는 게임이나 대규모 분석에 있어선 유리합니다.

 

그 다음으론 NoSql 모델의 종류에 대해서 설명하겠습니다.

 

1. 키 - 벨류형

키와 벨류 쌍을 저장하는 모델입니다. 키와 벨류로 이루어져 있기에 원하는 정보를 키값으로 고속으로 읽을 수 있습니다.

이렇게 간단한 구성으로 인해서 속도가 장점이며 주로 캐싱 기능을 사용할 때 이용하는 모델입니다.

여기에 대표적인 NoSql이 Redis 입니다.

 

Redis

in memory key value database

인 메모리이므로 메모리의 응답성이 빠르기에 캐시로 많이 사용합니다.

그래서 데이터베이스의 앞단에서 캐시로 주로 사용하는 거죠.

 

2. Document  지향형 

JSON같은 계층구조를 가진 데이터를 저장할 수있는 모델이고 대표적으로 MongoDB가 있습니다.

JSON 데이터에는 여러 항목이 포함되어있고, 배열이나 해쉬같은 깊은 계층 구조의 형태로 있는 경우가 많은데 , 이것을 일반적인 관계형으로 표현하려면 , 처리해야할 과정이 너무 늘어나고 복잡합니다. 하지만 이 상태 그대로 저장이 가능하기에 심지어 데이터 구조가 변경해도 따로 데이터베이스의 설계를 바꿀 필요가 없습니다.

 

3. Grpah 형 

노드 간의 릴레이션 십이나 , 노드가 가지는 속성으로 표현하는 방식입니다.

SNS의 친구 관게를 둘러싼 검색을 고속으로 실시 할 수있습니다.

 

레디스와 카프카란 ?

mysql 과 oracle 

어떤 데이터 베이스를 선택할까? CAP PACELC 

2. 데이터베이스 조작 

 

SQL - DCL,DML,DDL

Sql은 Structureed Query Language로 데이터베이스에 명령을 보내기 위한 언어입니다.

Sql을 통해서 원하는 정보를 추출하고 분석이 가능합니다. DBMS가 SQL을 파싱해서 최적화도 거치고 여러 과정을 거쳐서 수행합니다.

 

DDL ( Data Definition Language ) : 데이터 정의 언어

-> 데이터 베이스의 구조를 정의하거나 수정 

CREATE, DROP, ALTER , TRUNCATE, RENAME

DDL은 오토 커밋, 즉시반영되므로 주의 해야됩니다.

 

DML ( Data Manipulation Language) : 데이터 조작 언어

-> 삽입, 조회, 수정 ,삭제 등 실제 데이터를 조작하는 데 사용됩니다.

SELECT, UPDATE, INSERT , DELETE

DML은 트랜잭션에 포함되므로 TCL 명령어로 롤백하거나 조작이 가능합니다.

 

DCL ( Data Control Language ) : 데이터 제어 언어

-> 데이터 베이스의 사용자나 권한을 관리하는 언어, 데이터 보안의 역할을 수행합니다.

REVOKE, GRANT 

TCL ( Transaction Control Language ) : 트랜잭션 제어 언어

-> 트랜잭션을 제어하는 언어로 트랜잭션의 시작과 끝을 관리합니다.

COMMIT, ROLLBACK, SAVEPOINT 

 

그러면 트랜잭션이란 뭘까요? 

Trans + Action 말 그대로 데이터베이스의 상태를 변화시키는 하나의 논리적인 수행 단위입니다,

여러 SQL문을 하나의 단일 작업으로 묶은 것이죠. 

이체라는 과정에서 A->B에게 만원을 보내면 A계좌에 UPDATE가 발생하고 , B계좌에도 UPDATE가 발생 할 것입니다. 둘중 하나만 발생하면 이체라는 작업이 의미가 없는 것이죠 그래서 저런 2가지의 SQL문을 하나의 트랜잭션이라고 하는 것입니다.

 

COMMIT 과 ROLLBACK 

COMMIT 

지금까지의 작업내용을 DB에 영구적을로 저장한다. 트랜잭션을 종료한다.

ROLLBACK

지금까지의 작업을 모두 회수해서 트랜잭션 수행 이전 상태로 되돌린다.

 

트랜잭션의 ACID

 

Atomicity 원자성

-> 전체가 실행되거나 전체가 실행되지 않아야합니다. 부분적인 실행을 막습니다.

 

Consistency 일관성

-> 미리 설정된 조건을 충족하고 데이터가 일관성있게 유지되게 해줍니다.

 

Transaction은 결국 DB상태를 consistent한 상태에서 또 다른 consistent한 상태로 바꾸는 과정입니다.

만약 제약조건에 위배되는 트랜잭션이 발생하면 롤백해서 데이터의 일관성이 유지 되도록합니다.

 

Isolation 격리성

-> 트랜잭션이 수행되는 동안 다른 트랜잭션에 의해 간섭받으면 안됩니다.

트랜잭션이 실행 중인 데이터를 다른 트랜잭션이 확인 못해야합니다.

즉 Concurrency Contorl의 주된 목표가 Isolation입니다.

 

Durability 지속성

-> 트랜잭션이 커밋되면 그 결과는 영구히 유지되어야합니다.

문제가 생겨서 시스템 오류가 생겨도 성공적으로 커밋된 내용은 변하면 안되고 유지되어야합니다.

 

Concurrency Control provides Serializability &recoverability

 

트랜잭션의 스케쥴이란 여러 트랜잭션이 동시 실행될 때 각 트랜잭션에 속한 실행 순서를 말합니다.

트랜잭션들이 겹치지 않고 각자 순차적으로 직행되는 것이 Serial Schedule 입니다.

겹치지 않기에 동시성에 대한 문제는 없지만 반대로 말하면 순차적으로 실행하는 동안 IO 작업이 끝날때까지 다른 트랜잭션을 수행하지 않고, 기다리면서 자원을 낭비하는 것이죠. 그래서 성능 상으론 좋지 않습니다. 그래서 실제로 잘 안쓰죠.

 

겹치는 트랜잭션들이 Non-Serial입니다.

IO작업을 실행하는 동안 cpu가 놀지 않고 다른 작업을 수행합니다.

그렇기에 동시성이 높아져서 같은 시간동안 더 많은 트랜잭션을 수행하는 것입니다. 성능상 더좋은 것이죠

하지만 Non-Serial은 겹쳐서 실행할 경우 이상한 결과를 초래할 수도 있습니다.

 

그래서 Non-Serial로 실행해도 이상한 결과가 안나오게 방법을 찾았고, 그에 따라서 serial과 동일하게 non-serial을 수행하면 되겠다라고 아이디어를 떠올리게 됩니다. 그렇다면 여기서 스케줄이 동일하다는건 무엇을 의미할까요?

 

Conflict Equivalent 

1. 두 스케줄이 같은 Transaction을 가진다.

2. 어떤 conflict operation의 순서도 양쪽 스케줄이 동일하다 

1번과 2번의 조건을 만족하면 conflict equivalent라고 합니다.

 

여기서 Conflict Operation이란 동일한 자원에 대해서 서로 다른 트랜잭션이 최소하나는 write operation하는 경우를 뜻합니다. 이처럼 논-시리얼한 스케쥴이 시리얼 스케줄과 Conflict - Equivalent 하는 경우를 만드는 것.

Conflict Serializable이라고 합니다.

 

Conflict Serializable한 Non-serial 스케줄을 사용하자 ! 

 

여기서 Concurrency Control이란건 결국 어떤 스케줄도 serializable하게 만들어주는 것을 말합니다.

 

 

Recoverable Schedule 

 

UnRecoverable Schedule이란 

참조: 쉬운코드 데이터베이스 강좌 (유튜브)

 

그림과 같이 두가지 트랜잭션의 상황에서 1번째 트랜잭션이 커밋을 완료한 상태이다. 근데 여기서 트랜잭션 2가 abort가 발생해서 롤백을 한다면, + 30만원한건 롤백될 것이다. 그리고 H에 30만원 보내는 작업을 수행한 1도 취소 될것이고, 그러나 Durability 속성때문에 트랜잭션의 1의 잔고는 20만원 마이너스된 상태로 유지가 되버린다. 저 20만원은 복구가 안된다 .그렇기에 unRecovable 한 스케줄인 것이다. DBMS에서는 이러한 스케쥴은 에초에 막아서 실행 못하게한다.

즉 스케줄 내에서 커밋된 트랜잭션이 롤백된 트랜잭션의 write했던 데이터를 읽은 경우다.

 

어떤 스케줄이 Recovable할까

의존성이 있는 상황에선 의존성의 주체가 되는 트랜잭션이 커밋할 때까지는 커밋하지 않는 것을 의미한다.

 

 

 

이런 스케줄이 롤백하면 온전한 상태로 돌아가기에 DBMS에서 수행을 해야한다.

이렇게 하나의 트랜잭션에서 롤백일어나면 관련있는 트랜잭션들도 연쇄적으로 롤백을 하는데 이걸 Cascading Rollback이라고 합니다. 이는 연쇄적으로 롤백이 일어나므로 비용이 많이 들죠.

 

비용이 많이 발생하지 않게 Cascadeless Schedule이 나왔다.

스케쥴 내에서 어떤 트랜잭션도 커밋되지 않은 트랜잭션들의 데이터를 읽지 않는 경우를 말한다.

 

 

 

 

하지만 이렇게 케스케이드리스 스케줄을 해도 문제가 생깁니다.

 

그림과 같은상황도 케스케이드리스 스케줄이죠. read 자체가 없습니다.

하지만 문제가 발생했습니다. 1번 트랜잭션에서 abort가 발생해서 롤백하니까 2번이 write한 2만원이 아니라 3만원으로 돌아가게 되는 거죠. 이런 점을 극복한게 Strict Schedule 입니다.

 

바로 커밋되지 않는 트랜잭션들이 wirte한 데이터는 읽지도 않고 쓰지도 않는 경우입니다.

 

결국 Concurrency Control은 Serializability랑 Recoverability를 제공하는 겁니다.

 

 

트랜잭션 격리 수준 ( Isolation Level )

 

이상현상 3가지 

 

 

Diry Read 

y를 70으로 write했는데 커밋을 하지 않는 데이터를 Read해서 x값이 이상해졌습니다.

커밋 되지 않은 변화를 READ해서 문제가 되는 상황입니다.

 

 

Non-Repeatable Read ( Fuzzy Read )

 

즉 같은 데이터의 값을 읽었는데 한 트랜잭션 안에서 값이 달라지는 현상입니다.

이것은 트랜잭션의 고립성을 무시한 것이죠. 트랜잭션의 Isolation은 여러 트랜잭션이 동시에 실행해도 마치 혼자서 실행 한것 과 같은 속성인데 그것을 버린 것입니다.

 

 

기존에 읽었을 때는 t1 밖에 없었는데, 새롭게 t2가 생기는 없던 데이터가 생기는 이상현상이 Phantom Read입니다.

 

 

이처럼 이상 현상들은 모두 발생하지 않게 만들 수 있습니다. 하지만 그렇게 되면 제약사항이 많아져서 트랜잭션의 가능한 수가 줄어 DB의 처리량이 하락하게 되는 Trade Off가 발생합니다.

 

그래서 격리수준이라는 Isolation Level을 설정해서, 개발자가 스스로 필요에 따라 적절히 선택하도록 한것이고

isolation level은 이상현상 중 몇개를 허용한지에 따라서 구분되는 것입니다.

 

 

 

Read Uncommitted : 커밋되지 않는 데이터를 다른 트랜잭션이 읽는 것을 허용한다.

Read Committed : 커밋된 데이터만 다른 트랜잭션이 읽을 수 있다.

Repeatable Read :  트랜잭션 범위 내에서 읽는 데이터 값은 항상 같아야 된다.

Serializable : 트랜잭션을 순차적으로 실행하며 완전한 격리성을 보장한다.

 

이렇게 4가지로 격리 수준을 나눈 것인데 여기에는 비판의 목소리가 많았다.

실제로 DBMS 마다 이 격리수준을 나누는 기준이 조금씩 다르기도 한다.

하지만 대부분은 이 3가지 이상현상에 대해서 격리 수준을 나누어 설정했다.

 

이 기준에 비판하는 사람들의 의견은 이상현상이 3가지 뿐만 아니라 더 많다는 것이였습니다.

몇가지 이상현상을 더 소개해드리겠습니다.

 

 

이 이외에도 여러가지 이상현상이 더 있습니다.

 

사실 근데 어처피 실제 DBMS에서는 위에 설명한 3가지의 이상현상을 기준으로 선정한다고 했습니다.

그러면 이상현상 다른 것들은 몰라도 된다고 할 수도 있지만, 여러가지 이상현상을 알고 있으면 개발할 때 국한되어서 생각하지 않고 넓게 문제를 바라볼 수 있기에 추가적으로 작성했습니다. 

우리는 주어진 상황에 맞게 DBMS에 맞게 격리 수준을 잘 설정하면 됩니다.

 

항상 격리 수준이 낮아지면 동시성이 높아지고 데이터의 일관성은 낮아지는 것을 염두하면 될것같습니다.

 

DB Lock 

 

Lock 으로 Concurrency control을 합니다.

 

Write Lock ( Exclusive Lock ) : 베타락 

-> read/write 할 때 사용하는 락으로 다른 트랜잭션이 같은 데이터를 읽거나 쓰는 것을 허용하지 않습니다.즉 락이 언락될 때까지 다른 트랜잭션의 접근을 막습니다.

 

Read Lock ( Shared Lock ) : 공유락

-> Read 할 때만 사용하는 락으로 읽기만 하기에 다른 트랜잭션이 같은 데이터를 Read하는 것을 허용한다.

 

데드락 ( 교착 상태 )

 

두 개 이상의 트랜잭션이 특정 자원의 Lock을 획득한 채 다른 트랜잭션이 소유하고 있는 잠금을 요구하면 아무리 기다려도 상황이 바뀌지 않는 상태가 되는데 이를 교착상태라고 한다.

 

방지하거나 해결을 하는 방법 으로는 교착상태를 발견하면 다른 트랜잭션을 먼저 풀어준다. 풀어버림으로 써 그 트랜잭션이 종료되게 하는 것이다.

아니면 데드락이 발생하지 않도록 순서를 미리 정해놓는 것이다. 

무조건 A를 먼저 수행한다던지 이런 순서를 정해서 방지한다.

 

조인

SQL에서 두 개 이상의 테이블을 결합하여 관련 데이터를 하나의 결과로 반환

 

논리적 조인과 물리적 조인으로 나뉩니다.

논리적 조인이 사용자가 SQL문으로 지정하는 테이블 결합 방식입니다.

대표적으로 inner join과 outer join. cross join 이 있습니다.

inner 조인은 두 테이블간 공통된 데이터 값이 있는 행만 반환합니다.

outer 조인은 두 테이블간의 교집합과 한 테이블에만 있는 데이터를 반환합니다.

테이블 위치에 따라서 left,right로 나뉩니다.

 

물리적 조인은 DM 옵티마이저에 의해서 실제로 실행되는 테이블 결합 방식입니다.

Nested Loop Join, Sort Merge Join, Hash Join이 있습니다.

 

Nested Loop Join은 외부테이블 (Outer테이블)의 각행을 기준으로 내부 테이블 (inner테이블)을 반복적으로 탐색해 조인 조건에 맞는 행을 결과로 반환하는 기법입니다. 이중 for문의 형식으로 되어 있고,구현이 쉽고 작은 데이터셋에서 효과적이며 인덱스가 있어야 성능이 좋습니다.

 

Sort Merge Join은 조인 컬럼을 기준으로 정렬한다음 조인 결과를 반환하는 기법인데, 정렬의 추가 비용이 발생한다는 단점이 있습니다.

 

Hash join은

조인 대상의 두 테이블 중 데이터가 더 작은 테이블을 Build Input(빌드 입력) 이라 하고, 큰 테이블을 Probe Input(프로브 입력) 이라고 한다.

Build Input 테이블의 조인 컬럼에 Hash Function(해시 함수) 를 이용해서 Hash Key(테이블의 인덱스 역할) 을 생성 후, Hash Table(해시 맵) 을 생성한다. 그리고, Probe Input 테이블의 조인 조건에 맞는 해시 테이블을 탐색하며, 해시 함수를 적용하여 해시 키를 생성하고, 해시 테이블에서 같은 해시 키를 찾아서 조인을 진행하는 방식이다.

 

대용량 데이터의 경우 동증 조건은 hash , 범위 검색은 정렬된 Sort Merge join의 성능이 좋을 것같습니다.

 

Group By

SQL에서 데이터를 그룹으로 묶고, 각 그룹에 대해 집계 함수(aggregate function)를 사용하여 계산을 수행할 때 사용됩니다.

 

having과 where 

where 과 having 의 차이점 
웨얼에서 지정한 조건은 그룹바이 이전에 실행 되고
해빙은 그룹바이에서 그룹화된 결과에 필요한 정보를 추릴 떄 사용되는 것 

 

'DELETE', 'TRUNCATE'및 'DROP'명령을 구분하십시오.

DELETE는 테이블의 특정 행을 삭제할 때 사용하며, 트랜잭션 로그를 기록하기에 Rollback이 가능합니다. 하지만 로그를 기록하기에 대용량 데이터를 삭제할 때의 속도는 느립니다.

 

TRUNCATE는 테이블 내의 모든 데이터를 삭제하지만, 테이블의 구조는 유지 됩니다. 그리고 로그를 기록하지 않기에 RollBack이 불가능합니다.

 

DROP은 테이블 자체를 삭제하는 명령어로 , 데이터 뿐만아니라 인덱스, 제약조건등 전부 삭제하고 rollback이 불가능합니다.테이블 전체를 삭제하기에 제일 빠릅니다.

 

3. 데이터 베이스 관리

char와 varchar

varchar와 char의 차이는 가변길이 이런문제가아니라 공간의 예약 기준이다미리공간이 예약된건지 아닌지에따라서 갈리는것 차에서 미리 예약한다는건 공간의 낭비가 이뤄질수있다는것

즉 말해서 좀더 깊게 들어가보면 데이터가 저장되는 공간을 미리 예약하는게 오히려 더 좋을 떄도 있다는 것이다 값의 변화가 자주일어나고 가변 길이의 범위폭이 좁다면 오히려 char가 더 좋을  때가 있습니다.

만약 varchar에서 abcd가 저장되어있는 공간을 abcde로 업데이트한다고 치면 DBMS는 원래 레코드가 저장된 공간을 인플레이스로 업데이트를 못합니다. 공간의 사이즈가 다르기 때문이죠. 그래서 15바이트를 새롭게 저장할 공간을 찾을 것입니다. 데이터페이지가 이떄 계속해서 차게되며는 레코드 한건을 저장할 공간을 찾는게 어려워 질것이고 어느순간에 찾지못한다면, 새로운 저장 공간을 찾을거다 이 과정의 비용이 크다.
하지만 char였다면 컬럼을 위해 이미 충분한 공간을 예약했기에 레코드를 통쨰로 옮겨쓸 필요가 없어서 좋다는거지 
레코드 위치를 옮길 필요가없어진다

 

무결성

 

데이터의 정확성,일관성,유효성이 유지되는 것을 말합니다.

정확성은 데이터가 올바르게 입력되고 저장되는 것이며, 일관성은 데이터베이스 전체에 데이터가 일관성있게 저장되는 것

무결성을 지키기 위해서 제약조건을 걸거나, 트랜잭션의 ACID 특성 같은 특성을 이용해서 유지합니다.

 

1. 개체 무결성 ( Entity Integrity )

기본키로 선택된 필드는 고유한 값을 가지며, Null을 허용하지 않아 각행이 고유하게 식별되야 되는것입니다.

2. 참조 무결성 

테이블 간 관계에서 외래키가 참조하는 값이 일관성을 유지해야합니다.

Restricted : 레코드를 변경 또는 삭제시 해당 레코드가 참조하는 개치가 있으면 연산 자체를 취소합니다.

Cascade : 동시에 참조하고 있는 개체도 변경 삭제됩니다,

Set Null : Null 로 설정합니다.

이렇게 외래키에 제약조건을 걸어 참조 무결성을 지킵니다.

3. 도메인 무결성 

도메인 무결성은 각 열이 정의된 데이터 타입(문자,숫자) 등을 준수해야하는 것입니다.

각 열이 정의한 Not Null 같은 제약조건을 준수해야됩니다.

 

무결성이 깨지면 데이터 값에 오류가 생겼다는 것이고, 참조 무결성 같은 것이 깨졌다는 것은 관계가 손상되었다는 것을 의미합니다.

 

키의 종류

 

유일성과 최소성을 만족하는 지에 여부로 키를 나눕니다.

유일성은 모든 레코드에서 해당 필드에 중복된 값이 나타나지 않는 속성이고

최소성은 최소한의 필드로 레코드를 유일하게 구별해야되는 속성입니다.

 

슈퍼키 

테이블의 하나 이상의 열로 구성된 키로 유일성을 만족합니다.

 

후보키

슈퍼키 중에서 최소성을 만족한 키로서 기본키가 될 수 있는 후보입니다.

 

기본키

후보 키중에서 선택된 고유한 식별자입니다. 후보키와 같이 유일성과 최소성을 만족하며 NULL값을 가질 수 없습니다.

두가지 사항을 고려해야합니다.

 

값이 자주 변경 되지 않아야 한다.

-> 값이 변경되면 NULL인지 유일한지 검사해야하므로 변경되지 않는 키를 선택

값이 단순한 것을 선택

-> 기본 키로 선택된 필드에 많은 자리숫의 정수거나 문자열이면 그만큼 기본키 비교시 많은 비용 소모됩니다.

 

외래키 

한 테이블의 열이 다른 테이블의 기본 키를 참조하여 두 테이블 간 관계를 정의하는 키입니다.

외래키 값 자체는 중복되거나 NULL값이 가능하지만 참조되는 데이터는 반드시 존재하며 유일해야합니다.

 

 

대체키

후보키중 기본키로 선택된 것을 제외한 모든 키

 

복합키

한개이상의 필드를 포함하는 키

 

4. 데이터 베이스 도입 

엔티티 속성

데이터간의 관계 

ER 다이어그램 

개논물

 

함수 종속 ( Functional Dependency ) 

X값에 따라서 Y값이 유일하게 결정될 때, x가 y를 함수적으로 결정하고 y는 x에 함수적으로 의존한다고 말할수 있고, 두 집합사이의 이러한 제약관계가 함수종속입니다.

X->Y 이렇게 함수종속을 표현합니다.

 

함수 종속은 테이블의 state를 보고 판단하는 것이 아니라, 의미를 보고 파악해야됩니다.

예를 들어서 이름과 생일 컬럼이 존재하고, 현재 테이블상 중복되는 데이터가 없는 상태인 경우, 함수 종속 상태라고 판단할 수있지만 의미적으로 생각해보면 동명이인이 있을 경우는 함수종속이 되지않기에 주의해야됩니다.

 

또한 X->Y 인 경우 Y->X는 항상 성립하지 않고 보장도 되지 않습니다.

그리고 어떠한 값에 상관없이 Y값이 일정한 경우는 {} -> Y 이렇게 표현합니다.

 

함수 종속은 종류가 존재합니다.

 

Trivial FD 

X-> Y, 일때 Y가 X의 부분 집합일 경우

{a,b,c} -> {c }

 

Non-Trivial FD

{a,b,c} -> {b,c,d} 

부분 집합은 아닌 경우 

 

Partial FD 

Proper subset : X와 동일하지 않은 부분집합 {a,b,c}이면 {a,b,c}를 제외한 부분집합

X->Y, Proper subset of X가 Y를 여전히 결정이 가능한 경우

 

Full FD

proper subset으로는 결정 못짓는 경우

 

DB 정규화 

데이터 중복과 이상현상을 최소화 하기 위해 일련의 Normal Form에 따라서 DB를 구성하는 과정입니다.

정규화 되기위해 준수해야되는 룰이 Normal Form이고, 처음부터 순차적으로 진행하며 앞단계를 만족해야 다음 단계로 진행 가능합니다. 

FD와 key만으로 정의되는 NormalForm이 1,2,3,BCNF 까지이고 그 뒤는 실무적인거라기보단 학술적인것이라 다루지 않습니다.

 

이상현상

 

1. 삽입 이상

데이터를 삽입할 때 의도하지 않은 데이터까지 삽입해야만 하는 현상

2. 갱신 이상

중복된 데이터중 일부만 수정되어 데이터 모순이 일어나는 현상

3. 삭제 이상

이떤 정보를 삭제하면 의도하지 않은 다른 정보까지 삭제되는 현상 

 

참조 : https://dev-coco.tistory.com/63

https://mangkyu.tistory.com/110

 

[Database] 정규화(Normalization) 쉽게 이해하기

지난 포스팅에서 데이터베이스 정규화와 관련된 내용을 정리했었다. 하지만 해당 내용이 쉽게 이해되지 않는 것 같아서 정규화 관련 글을 풀어서 다시 한번 정리해보고자 한다. 1. 정규화(Normaliz

mangkyu.tistory.com

 

제1 정규형 : 테이블의 컬럼이 원자 값(Atomic Value; 하나의 값)을 갖도록 분해합니다.

제2 정규형: 제1 정규형을 만족하고, 기본키가 아닌 속성이 기본키에 완전 함수 종속이도록 분해합니다.

※ 여기서 완전 함수 종속이란 기본키의 부분집합이 다른 값을 결정하지 않는 것을 의미


제3 정규형 : 제2 정규형을 만족하고, 이행적 함수 종속을 없애도록 분해합니다.

※ 여기서 이행적 종속이란 A → B, B → C가 성립할 때 A → C가 성립되는 것을 의미


BCNF 정규형 : 제3 정규형을 만족하고, 함수 종속성 X → Y가 성립할 때 모든 결정자 X가 후보키가 되도록 분해합니다.

 

1. 데이터베이스 변경 시 이상현상이 발생하는 문제점을 해결할 수 있다.

2. 데이터베이스 구조 확장 시 정규화된 데이터베이스는 그 구조를 변경하지 않아도 되거나 일부만 변경해도 된다.

 

반정규화

 

정규화된 데이터베이스의 성능 향상을 위해 데이터 중복을 허용하거나, 테이블 구조를 단순화하는 과정

정규화를 거치면 릴레이션 간의 연산(JOIN 연산)이 많아지는데, 이로인해 성능이 저하될 우려가 있습니다.

역정규화를 하는 가장 큰 이유는 성능 문제가 있는(읽기작업이 많이 필요한) DB의 전반적인 성능을 향상시키기 위함입니다.

 

5. 데이터베이스 운용

scale up과 scale out 

 

스케일 업은 기계의 성능을 향상 시켜서 처리량을 늘리는 방식입니다.

스케일 아웃은 기계의 대수를 늘려서 처리량을 늘리는 방식으로 데이터를 분산시키는 방식입니다.

 

파티셔닝 샤딩 

둘다 데이터를 효율적으로 저장하고 처리하기 위한 데이터 분산 기법입니다,

 

파티셔닝

데이터 베이스의 테이블을 더 작은 테이블로 나누는 것.

 

수직 파티셔닝

테이블을 열 기준으로 분리

정규화 과정도 수직 파티셔닝에 속합니다. 데이터의 중복을 피하고 이상현상을 방지하기 위함이죠.

정규화 과정 말고도 수직 파티셔닝이 필요한 경우가 있습니다. 게시글 목록화면에서는 게시글의 내용이 필요하지 않고 제목이나 날짜 조회수같은 정보만 필요합니다. 그래서 쿼리를 날릴때도 Select 문으로 필요한 정보만 선택하죠. 하지만 실제로는 해당 조건에 만족하는 레코드 한행을 다 가져와서 거기서 선택해서 주는 것입니다. 즉 IO에 부담이 알게모르게 가해집니다. 그러므로 게시글의 내용은 보통 이미지 등 이유로 사이즈가 클 것이고 이것을 필요없음에도 가져와야 되므로 성능에 영향을 줄 것입니다. 그래서 content를 수직 파티셔닝으로 따로 분리하면 IO 부담이 적어지겠죠.

이럴때 수직 파티셔닝을 사용하기도 합니다.

 

수평 파티셔닝

테이블을 행 기준으로 분리

행을 기준으로 분리하기에 테이블의 스키마는 유지된다.

 

테이블이 커질 수록 인덱스의 크기도 커진다. 데이블이 읽기 쓰기 할때마다 계속해서 시간이 늘어 나는 것이다.

쓸 때마다 B 트리 내부에서 조정이 일어나기에. 

 

Hash 기반 수평 파티셔닝 

Hash Function을 선언한 다음 0과 1로 나오게 설정한다 . Partition key로 유저 아이디를 설정한다.

유저 아이디를 함수에 넣어서 0과 1로 나오는 것을 기준으로 2개로 테이블을 수직 파티셔닝한다.

데이터가 균등히 배분 되도록 해쉬 함수를 잘 정의 해야되고, 파티셔닝 키를 자주 쓰이는 것으로 선택해야됩니다.

그리고 한번 파티션이 설계되면 추가되기 힘들다. 재분배하기

 

샤딩

 

수평 파티셔닝과 유사하게 행을 기준으로 나눕니다. 하지만 데이터 자체를 다른 컴퓨터 (서버)에 분산해서 저장합니다. 여기서 나누어진 단위를 샤드라고 합니다. 서로 다른 서버에 분산되기에 부하자체가 분산되는 Scale-out 효과를 얻는 장점이 있습니다.

또한 샤드키를 잘 설정해서 한곳으로 트래픽이 몰리는 현상을 막아야됩니다. 한쪽으로 몰려서 병목현상이 발생하는 것이 HotSpot현상이고 이를 방지해야됩니다.

또한 다른 서버에 데이터가 존재하게 되므로 JOIN을 하기에 성능이 안좋습니다.

 

클러스터링 리플리케이션 

둘다 가용성을 확장하기 위한 방법입니다. High Available을 위함 

 

클러스터링 

여러 데이터베이스 서버를 하나의 그룹(클러스터)으로 구성하여, 마치 단일 데이터베이스처럼 동작하게 만드는 기술입니다.

 

활성-활성(Active-Active) 클러스터:

  • 모든 노드가 동시에 활성 상태로 동작하며, 부하를 분산(Load Balancing)하여 처리.

활성-대기(Active-Passive) 클러스터:

  • 한 노드가 활성 상태로 작동하고, 나머지 노드는 대기 상태로 있다가 장애 발생 시 활성화.

장점

  1. 자동 장애 전환(Failover):
    • 클러스터링은 장애가 발생하면 즉시 다른 노드로 작업을 전환하여 무중단 서비스 제공.
  2. 고가용성
  3. 수평적 확장(Scale-out):
    • 새로운 노드를 추가하여 처리량 증가 가능.

단점으론 비용이 증가하고 관리가 힘들다는 점이있습니다.

 

리플리케이션

 

데이터를 한 서버에서 다른 서버로 복제하여 동일한 데이터를 유지하는 기술입니다.
주로 읽기 성능 향상과 데이터 백업을 위해 사용됩니다.

 

읽기가 주로 발생하므로 읽기 작업을 복사된 데이터베이스로 부하를 넘겨서 부하를 줄일 수 있습니다,

 

  • 단방향 리플리케이션(Master-Slave):
    • 마스터 서버가 쓰기 작업을 처리하고, 데이터를 슬레이브 서버로 복제.
    • 슬레이브 서버는 읽기 작업을 처리하여 부하를 분산.
  • 다중 마스터 리플리케이션(Master-Master):
    • 여러 서버가 쓰기와 읽기 작업을 동시에 처리하며, 데이터를 서로 복제.
    • 충돌 해결 로직이 필요.

쓰기 작업 부하 분산 어려움:

  • 단방향 리플리케이션에서는 쓰기 작업이 마스터 서버에 집중됨.

6. 데이터베이스 트러블과 보안

 

인덱스

풀 스캔으로 탐색했을 때는 시간복잡도가 데이터의 갯수 만큼 O(N)인데, B- Tree 기반 인덱스를 사용할 경우 O(LgN)까지 줄어들어 탐색의 속도가 빨라진다. 즉 인덱스를 사용하는 이유는 조건에 만족하는 튜플을 빠르게 조회하기 위해서 입니다.

특정 조건을 만족하는 데이터를 빠르게 찾기위해서 사용하는 것.

인덱스의 단점

1. 쓰기 작업 성능 저하

  • 데이터 삽입, 업데이트, 삭제 시 인덱스도 함께 갱신되어야 하므로, 쓰기 작업이 느려질 수 있습니다.
    • 예: 테이블에 새 데이터를 삽입하면 관련 인덱스도 갱신되어야 하므로 삽입 속도가 저하.

2. 저장 공간 추가 사용

  • 인덱스는 별도의 데이터 구조(B-Tree 또는 Hash 등)를 사용하기 때문에 추가적인 디스크 공간이 필요합니다.
    • 예: 테이블이 클수록 인덱스 크기도 증가.

3. 과도한 인덱스 생성으로 인한 관리 복잡성

  • 너무 많은 인덱스를 생성하면 관리가 복잡해지고, 어떤 인덱스가 효율적인지 파악하기 어려움.
    • 예: 필요 없는 인덱스가 많을 경우, 쿼리 성능이 오히려 저하될 수도 있음.

인덱스 종류 

 

B-Tree

 

B-Tree는 자식 2개 만을 갖는 이진 트리(Binary Tree)를 확장하여 N개의 자식을 가질 수 있도록 고안된 것이다. 그리고 좌우 자식 간의 균형이 맞지 않을 경우에는 매우 비효율적이라, 항상 균형을 맞춘다는 의미에서 균형 트리(Balanced Tree)라고 불린다.

B-Tree는 최상위에 단 하나의 노드 만이 존재하는데, 이를 루트 노드(Root Node)라고 한다. 그리고 중간 노드를 브랜치 노드(Branch Node), 최하위 노드를 리프 노드(Leaf Node)라고 한다.

 

 

 

  • B-Tree 인덱스 (일반적인 인덱스)
    • 데이터가 정렬된 트리 구조로 저장되어, 검색 및 삽입/삭제 시 효율적.
    • 범위 검색과 정렬에 유리.
    • DB는 보조기억 장치에 주로 저장된다.
    • 보조기억 장치는 데이터를 처리하는 속도가 느리지만 용량이크고, block단위로 데이터를 읽고 쓴다.
    • 데이터를 읽을 때는 내가 원하는 것만 가져오는게 아니라 블락단위로 가져오는 것이다.
    • DB에서 데이터 조회할 때 최대한 보조기억 장치에 적제 접근하는 것이 성능 면에 좋다.
    • 블록 단위로 읽고 쓰기에 연관된 데이터를 최대한 모아서 저장하는 게 좋다.
    • B트리가 보조기억 장치에 접근하는 횟수가 적다. 왜냐하면 자녀 노드의 수를 많이 가져 갈 수있기에 탐색범위를 빠르게 좁혀 갈 수있다는 것입니다. 즉 리프노드로 가는 횟수를 줄인다는 것입니다.
    • 또한 B트리는 노드의 데이터 수가 차수에 따라서 2개 이상 가져 갈 수있기에 block에 대한 공간의 저장활용도가 높습니다.
    • 101차수 B tree는 네개의 레벨만으로 수천만의 데이터를 저장 가능한 것도 있다.
  • Hash 인덱스
    • 데이터를 해시 함수로 변환하여 저장.
    • 정확한 값 검색에 최적화되었지만, 범위 검색에는 적합하지 않음.
    • 시간복잡도가 O(1), 해쉬로 구현되어서 = 비교만 가능 range는 불가능이이기

 

1. 사용에 적합한 경우

  • 데이터 읽기(SELECT)가 빈번한 테이블.
  • WHERE 조건이나 조인에 자주 사용되는 열.
  • 정렬이나 그룹핑이 자주 필요한 열.

2. 사용에 적합하지 않은 경우

  • 데이터 변경(INSERT, UPDATE, DELETE)이 매우 빈번한 테이블.
  • 테이블의 데이터 크기가 작아 인덱스 효과가 미미한 경우.
    • 이때는 풀스캔이 더 빠르다.
  • WHERE 조건에 사용되지 않는 열.
  • 값의 종류가 너무 적은 열 (예: 성별처럼 M/F만 있는 열은 효과가 적음).

멀티 컬럼 인덱스

 

WHERE A  = 7 AND B = 95 이런 형식의 조건절에서는 A와 B둘다 자주 사용되는 조건이라면 둘을 같이 인덱스로 만들어주는 것이 성능에 좋다.여기서 인덱스가 정렬되는 방식은 앞에 먼저 쓴 A기준으로 인덱스 테이블이 정렬된다.

멀티컬럼에서 주의할 점은 A,B 순서를 안지키고 쓰게되면 인덱스를 안타게되므로 주의해야된다.

 

sql injection

SQL Injection은 공격자가 애플리케이션의 입력 필드를 통해 악의적인 SQL 쿼리를 주입하여, 데이터베이스에 접근하거나 조작할 수 있는 보안 취약점입니다.

"1 or 1" 이런 쿼리문을 입력 란에 작성해, 로그인시 조건문에서 항상 참이 되게하여 로그인 되게 공격할 수도 있습니다.

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'pass';

 

방어하는 방법으로는 입력을 철저하게 검증하거나 ORM을 사용해서 방지합니다. 아니면 최소 권한을 부여해서 읽기 전용 사용자로 쓰기를 방지합니다.

 

 

회복 기법 

즉시갱신 지연갱신 

 

7. 데이터베이스 활용

JDBC

ORM과 JPA와 Hibernate

N+1 문

view

 

저장프로시저

일련의 쿼리를 마치 함수처럼 실행하기 위한 쿼리의 집합이다.

애플리케이션에서 함수에 인자만 전달하여 쿼리 수행이 가능하다.

 

성능이 향상 됩니다. 미리 컴파일 되어서 저장되므로 sql문을 파싱하거나 해석할 필요 없이 실행됩니다.

재사용이 가능하므로 중복을 줄입니다. SQL 명령어 실행에 대한 권한을 주지 않고도 프로시저에 대한 권한만 주게 설정하여 보완을 높일 수도 있습니다. 클라이언트-서버 간의 트래픽을 감소하는 효과도 있습니다.

 

하지만 단점으로는 데이터베이스단에서 로직이 저장 될 경우 애플리케이션 단과 경계가 모호해진다는 점이 있습니다.

또한 DBMS의 문법따라 달라서 이식성이 떨어집니다. 디버깅이 어렵습니다. 또한 문자나 숫자 연산에 사용하면 자바보다 느립니다.

 

트리거

특정 이벤트가 데이터베이스에서 발생할 때 자동으로 실행되는 저장된 프로그램(코드)

DML문이 실행되었을 때 자동으로 데이터베이스에서 실행되게 작성한 프로그램

데이터의 일관성과 무결성, 자동화를 위해서 쓸 수 있습니다.

데이터를 삭제시 다른 참조하고 있는 테이블의 데이터를 삭제하는 등해서 말이죠.

 

 

하지만 개발 코드에서 찾을 수가 없습니다,가시적이지 않아서 개발도 관리도 문제파악도 힘듭니다.

트리거 연쇄적으로 발생되서 문제 파악이 힘들수 있고 

오히려 DB에 부담이 되어서 응답을 느리게 만듭니다.

디버깅이 어렵고 최종적으론 피하는 게 좋습니다.

 

 

힌트

옵티마이저(Optimizer) 대신 개발자가 직접 최적의 실행 경로를 작성해 주는 것이다.

 

  • 쿼리 최적화:
    • 데이터베이스의 기본 실행 계획이 비효율적인 경우, 힌트를 사용해 더 나은 실행 방식을 강제.
  • 특정 인덱스 사용 강제:
    • 데이터베이스가 특정 인덱스를 선택하지 않을 때, 원하는 인덱스를 강제로 사용하도록 설정.

하지만 최적의 실행계획보다 비효율적인 실행계획을 선택할 확률이 높고, 데이터의 분포가 바뀔경우 힌트의 효과가 사라질 수 있습니다.

 

 

Elastic Search

 

엘라스틱 서치는 동의어나 유의어를 활용한 검색이 가능하며, 비정형 데이터의 색인과 검색이 가능하고, 역색인 지원으로 매우 빠른 검색이 가능합니다.

 

DB 튜닝

 

데이터베이스 어플리케이션, 데이터베이스 자체, 운영체제 등의 조정을 통하여 데이터베이스 시스템의 성능을 향상시키는 작업

  • 갈수록 복잡화, 대량화되는 시스템을 그대로 유지하면서 DB 시스템을 최적화한다.
  • 어플리케이션이 높은 작업 처리량과 짧은 응답시간을 갖도록 한다.

튜닝 3단계

DB 설계 튜닝 ( 모델링 관점 ) -> DBMS 튜닝 ( 환경 관점 ) -> SQL 튜닝 ( APP 관점 )

1. DB 설게 튜닝 

데이터베이스 설계 단계에서 성능 고려해서 설계를 최적화

정규화/반정규화, 파티셔닝 

 

2. DBMS 튜닝 

성능을 고려해서 메모리나 블록 크기 지정

CPU.IO 메모리 관점

IO를 최소화, 버퍼  풀 튜닝 (지역성 관점에서 데이터 관리 )

캐시 크기 라던지

 

3. SQL 튜닝

SQL 작성시 성능 고려 

JOIN,INDEX , 힌트 사용 

 

DB커넥션풀