CAP (New) CAP 이론 설명 분산 데이터 베이스 시스템은 일관성, 가용성, 분할 내구성 3가지를 모두 가질 수 없다는 이론 일관성(Consistency): DB는 오류가 아닌 이상 노드에 상관 없이 가장 최신의 데이터를 반환해야 함 가용성(Availability): DB는 특정 노드에서 오류가 나도, 모든 요청에 대해 정상 응답을 해야 함 분할 내구성(Partition Tolerance): DB 노드 간에 통신 장애가 발생해도 동작해야 함 보통 두 가지만 만족하는 CP 시스템, CA 시스템, AP 시스템 으로 구분 CA 시스템 일반적으로 분산 DB 시스템은 네트워크 시스템에 장애가 발생해도 동작해야 함 즉, P가 없는 CA 시스템은 분산 데이터베이스 시스템이 아님 CA 시스템은 보통 하나의 노드에서 동작하는 monolithic한 DB 시스템을 의미 MySQL과 같은 RDBMS 역시 일반적으로는 CA 시스템이나, master-slave 구조를 사용하는 경우 CP 시스템이 됨 CP 시스템 가용성을 포기한 분산 데이터베이스 시스템 대표적인 예로 MongoDB가 존재 (MongoDB 기준으로 설명) 마스터인 primary 노드와 이 데이터가 비동기적으로 복제 되는 여러 secondary 노드로 구성 Primary에서는 데이터를 읽고 쓸 수 있고, secondary 노드는 읽기만 가능 Primary로부터 가장 최신의 데이터를 받으므로, CP 시스템임 Primary가 고장나면 secondary를 primary로 승격하게 되는데, 이 동안 사용 불가능 상태가 됨 (가용성 X) AP 시스템 일관성을 포기한 분산 데이터베이스 시스템 대표적인 예로 Cassandra가 존재 (Cassandra 기준으로 설명) P2P 형식으로, primary 노드가 없고, 각 노드별로 읽고 쓰기 가능 SPOF가 없음 데이터의 복제본을 다른 노드에 저장 한 노드가 다른 노드와 통신이 되지 않아도, 읽고 쓸 수 있음 그러나 가장 최신의 데이터를 받는다는 보장은 없음 (일관성 X) 이후 통신이 복구되면 데이터를 동기화해 일관성을 복구 한계 및 주의점 완벽한 CP 시스템을 구현하기 위해서는, 항상 최신의 응답을 반환해야 함 이를 위해 데이터가 변경된 경우 다른 모든 노드에 항상 복사되어야 함 이 과정에서 특정 노드에 문제가 있으면 성능적 희생이 발생 가능 완벽한 AP 시스템을 구현하기 위해서는, 고립된 노드에게 데이터를 요청해도 계속 데이터를 받기는 함 그러나 최신 데이터가 아닐 수 있음 이 노드와 연결된 사용자는 최신 데이터를 얻기 위해 요청을 보내는 상황이 발생 가능 이런 이유로 완벽하게 일관성과 가용성 중 하나만 선택할 수는 없고, 요구사항에 따른 타협이 필요 또한 네트워크 파티션이 없는 상황을 기술하지 못함 이 부분에 대해 보충하기 위해 PACELC 이론이 등장 References https://onduway.

MVCC-2 MVCC 구현 MVCC를 이용해 DB에 데이터를 쓰는 경우, 다음과 같은 두 가지 방법 존재 다중 버전의 데이터를 DB에 저장하는 MGA(Multi Generation Architecture) 방법 최신 버전의 데이터만 DB에 저장하고, 이전 버전은 UNDO 영역에 저장하는 rollback segment 방법 MGA PostgreSQL, SQL Server 등에서 사용하는 방법 DB를 업데이트 하는 경우 기존 데이터를 덮어 씌우지 않고 새 버전의 데이터를 따로 저장 데이터별를 저장할 때 데이터별로 XMIN, XMAX 값을 저장 XMIN: 데이터가 새로 만들어질 때 현재 트랜잭션 ID를 XMIN에 기록 XMAX: 데이터가 삭제되거나 다른 버전이 생긴 경우 현재 트랜잭션 ID를 XMAX에 기록 XMAX가 NULL인 데이터가 가장 최신 데이터 구현은 쉽지만 다음과 같은 비효율적인 부분 존재 많은 양의 데이터를 저장해야 하므로 저장 공간이 많이 필요 주기적으로 VACCUM 작업을 통해 데이터를 지워야 함 데이터가 변경될 때마다 데이터의 물리적 위치가 변경되므로, 인덱스를 수정해야 함 Rollback Segment MySQL, Oracle 등에서 사용하는 방법 각 데이터에는 SCN(System commit number)라는 값이 존재 DB 내에서 발생하는 이벤트의 논리적 시점을 순차적인 숫자로 나타낸 것 데이터를 업데이트 하는 경우, 기존 데이터를 새로운 데이터로 변경함 기존 데이터는 undo 영역의 rollback segment에 저장됨.

MVCC-1 MVCC 개요 Multiversion Concurrency Control의 약자로, 데이터베이스에 대한 동시 접근을 허용하기 위한 기술 일반적으로 DB는 Lock을 통해 동시성 제어를 하는데, 이 경우 동시성 저하가 발생 가능 MVCC는 데이터의 여러 버전을 만들어 lock 없이 동시에 DB의 데이터를 읽게 함 단, Oracle과 같은 DBMS는 lock을 사용함 장점 / 주의점 장점 Lock을 사용하지 않으므로, 일반적인 RDBMS보다 빠르게 읽고 쓸 수 있음 다른 사람이 데이터를 삭제 / 수정해도 영향을 받지 않고 데이터 사용 가능 주의점 하나의 데이터에 대한 여러 버전이 존재 가능하므로, 충돌할 수 있음 애플리케이션 레벨에서 해결해야 함 사용하지 않는 버전에 대한 관리 필요 또한 여러 버전을 사용하는 만큼 오버헤드가 발생 References https://en.

Index Scan vs Table Full Scan Table Full Scan 테이블에 존재하는 모든 데이터를 읽는 방식 블록들이 물리적으로 인접해 있기 때문에 한 번의 I/O에 여러 블록을 읽을 수 있음 Random access가 아닌 Sequential access를 사용 인덱스를 사용할 수 없거나 인덱스를 사용하는 것이 더 효율성을 낮추는 경우 사용 넓은 범위의 데이터를 가져오는 경우 좋음 캐시에서 원하는 데이터를 못 찾은 경우 이 방법을 통해 한 번의 I/O를 통해 인접한 여러 블록을 같이 가져오면 공간 지역성을 활용 가능함 Index Scan 인덱스를 구성하는 컬럼의 값을 기반으로 데이터를 읽는 방식 Random access를 수행하고, 한 번의 I/O에 한 블록만 읽을 수 있음 읽을 데이터가 많으면 많을수록 Table full scan에 비해 비효율적 큰 테이블에서 소량의 값을 찾을 때 유용 Index Scan 에는 다음과 같은 여러 방식이 있음 Index Scan 종류 Index Range Scan 인덱스를 활용해 루트에서 리프 블록까지 수직적으로 탐색하고, 해당 블록부터 필요한 범위까지 수평적으로 탐색하는 방법 B+ Tree 인덱스의 가장 일반적인 형태 인덱스의 선두 컬럼이 가공되지 않고 Where 절에 사용되는 경우에 사용 가능한 scan 방법 Ex) select * from t where a + 2 = 4; 와 같은 경우에는 사용되지 못함 특정 범위 내의 값을 찾거나, non-unique index를 사용할 때 주로 사용됨 오름차순으로 정렬된 결과를 얻음 Index Full Scan 인덱스의 수직적 탐색 없이, 모든 리프 블록을 수평적으로만 탐색하는 방법 인덱스의 선두 컬럼이 조건 절에 없는 경우에 사용 가능 테이블이 너무 커서 Table Full Scan의 부담이 큰 경우에 사용 인덱스 스캔 단계에서 대부분의 데이터를 필터링하고 아주 소량의 데이터에만 실제 테이블의 엑세스가 필요한 경우, 굉장히 유용 인덱스의 크기는 실제 테이블보다 훨씬 작기 때문에 인덱스 전체를 탐색하는 비용이 작음 그러나 이런 쿼리가 있다면, 그냥 해당하는 인덱스를 만드는 것이 더 유용할 수 있음 이 방법 역시 오름차순으로 정렬된 데이터를 얻을 수 있음 Index Unique Scan 인덱스의 수직적 탐색 으로만 데이터를 찾는 방법 Unique 인덱스를 등호 조건으로 탐색할 때 사용 하나의 유일한 데이터를 찾으므로 수평적 탐색이 필요 없음 Index Skip Scan Multi-column 인덱스에서 후행 칼럼이 조건 절에 사용될 때 사용 가능한 방법 조건절에 빠진 선행 인덱스 컬럼의 고유 값이 적고 후행의 고유 값이 많은 경우 사용됨 Ex) 선행: 10, 20, 30, 40, 후행: 1 ~ 10000 인경우, 후행 조건: 2000 ~ 4000 이 경우 선행이 10 인 경우에 대해서는, 후행이 2000 ~ 4000 인 경우만 찾으면 됨 선행이 10이고 후행이 4001 ~ 10000인 경우는 스킵해도 됨!

REDIS 사용 이유 REDIS 소개 REDIS는 Remote Dictionary Server의 약자 즉, 외부에 key-value 값을 저장하는 서버 REDIS는 SSD, HDD와 달리 메인 메모리인 RAM에 데이터를 저장 속도가 굉장히 빠르지만, 그 대가로 용량이 작음 이 때문에, 메인 DB로 사용되지 않고 캐시 DB 서버로 사용됨 여러 서버에서 접근이 필요한 Global Cache로 사용됨 싱글 스레드로 실행됨 Local Cache vs Global Cache Local Cache Local 내에서만 사용되는 캐시 속도가 빠르지만, 외부에서 접근은 불가 서버가 하나인 경우에 좋음 Global Cache 여러 서버에서 캐시 서버에 접근해서 사용하는 캐시 네트워크를 타야 하므로 Local Cache에 비해 비교적 느림 여러 서버에서 접근이 가능하므로 서로 다른 서버에서 같은 데이터를 사용할 때 용이 REDIS 사용 이유 여러 서버에서 데이터를 사용하는 경우 빠르게 데이터를 제공 가능 I/O가 자주 발생하는 경우 DB 부하를 줄일 수 있음 REDIS의 캐싱을 이용해 DB에 데이터를 바로 업데이트 하지 않음 일정 기간마다 DB에 한꺼번에 업데이트를 해서, 수많은 I/O에 대한 부담을 줄임 사용자 세션 관리에도 적합 Pub / Sub 모델을 통해 실시간 채팅 및 스트리밍 서비스 지원 가능 Scale-out이 쉬움 Master - Replica 구조를 통해 Master의 데이터를 복제 가능 읽기 부하를 줄일 수 있음 다양한 유형의 데이터를 쉽게 저장 및 검색 가능 간단한 API와 대규모 사용자 커뮤니티 References https://zangzangs.

DB Master Slave DB Master Slave 보통 DB에는 쓰는 행위보다 읽는 행위가 더 많음 읽기의 부하를 줄이기 위해, DB는 master-slave 구조를 사용 Master DB에서만 생성 / 삭제 / 수정 작업을 수행 @Transactional(readonly = true) 같이 읽기만 수행하는 경우에는 slave DB에서 동작하도록 설정 Master DB에서 변경이 일어나면 slave DB에 변경 이력을 보내 변경된 내용 반영 이 과정을 통해 트래픽이 집중되는 현상을 완화 가능 Slave 서버를 데이터를 백업하는 용도로도 사용 가능 Master DB가 죽은 경우 Master DB는 Single point of failure가 될 수 있음.

외래키 안쓰는 이유 외래키 안쓰는 이유 외래키는 무결성을 유지하기 위해 사용 CASCADE를 사용하게 된다면 한 테이블에서 데이터를 변경한 것이 다른 테이블에도 영향 가능 ON DELETE, ON UPDATE 등을 이용하게 된다면 매번 무결성 검사를 해야 함 추가적인 리소스 비용이 발생하고, 속도 및 성능 저하가 발생할 수 있음 외래키를 사용하지 않음으로 인해 무결성, 정합성을 희생시켜 성능적 이점을 얻는 것 또한 DB를 수정할 때 외래키가 걸려 있으면 수정할 내용이 훨씬 많아질 수 있음 외래키로 보장되는 내용은 DB가 아닌 애플리케이션 코드 단에서 로직을 구현해서 해결 가능 외래키는 이론상으로만 걸고, 실제로 DB에는 걸지 않음 DB에 많은 일을 떠넘기면 안됨!

Pessimistic Optimistic Lock DB Lock DB에서 여러 트랜잭션이 데이터를 수정 할 때 충돌이 일어날 수 있음 이런 경우에는 Lock을 걸어 트랜잭션의 격리 수준을 높임 Lock을 거는 방법으로는 Pessimistic Lock과 Optimistic Lock 존재 Lock의 종류로는 Shared Lock과 Exclusive Lock 존재 Optimistic Lock 낙관적 lock이라는 뜻으로, 데이터 수정 시 충돌이 일어나지 않을 것이라고 보는 lock DB가 제공하는 lock을 사용하지 않고 application level에서 lock을 걺 JPA 에서는 @Entitiy 내부의 필드에 @Version 어노테이션을 붙여 구현 가능 DB 수준의 롤백이 존재하지 않으므로, 충돌시 대처 방안을 구해야 함 성능적으로는 더 좋지만, 충돌 발생시 개발자가 직접 처리해야 한다는 단점 존재 충돌이 적은 곳에서 사용 Pessimistic Lock 비관적 lock이라는 뜻으로, 데이터 수정 시 충돌이 일어날 것이라고 보는 lock 트랜잭션이 시작될 때 shared lock 또는 exclusive lock을 걸고 트랜잭션을 수행 충돌이 일어난 경우, 트랜잭션이 취소되고 롤백이 수행됨 Repetable Read 혹은 Serializable 정도의 격리성 수준을 제공 무결성을 지키기 용이 Exclusive Lock 배타적 잠금, 쓰기 잠금이라고도 부름 어떤 트랜잭션에서 데이터를 변경할 때 해당 자원에 거는 lock 이 자원에 다른 트랜잭션에서 shared lock / exclusive lock을 걸 수 없음 즉, 다른 트랜잭션이 읽거나 쓰는 행위를 금지 Shared Lock 공유 잠금, 읽기 잠금이라고도 부름 어떤 트랜잭션에서 데이터를 읽을 때 해당 자원에 거는 lock 이 자원에 다른 트랜잭션에서 exclusive lock을 걸 수 없음 즉, 다른 트랜잭션이 쓰는 행위를 금지 다만 여러 트랜잭션이 동시에 한 리소스에 shared lock을 걸어 읽을 수 있음 References https://2step-hyun.

DB Connection Pool DB Connection 애플리케이션에서 DB에 연결하기 위해서 다음과 같은 과정을 거침 DB 드라이버를 통해 DB와 애플리케이션 연결 TCP 소켓 열기 TCP 소켓을 이용해 데이터 통신 DB 연결 닫기 TCP 소켓 닫기 이렇게, DB에 연결 하고 해제하는데에는 많은 비용 소요 DB에 쿼리를 보내고 작업하는 시간보다도 많이 소요될 수 있음 DB Connection Pool 매 요청마다 DB 연결을 수립하는 것은 비효율적 DB Connection Pool(DBCP)이란 미리 여러 개의 DB 커넥션을 객체로 만들어서 저장해둔 Pool WAS 등의 DB가 필요한 애플리케이션에서 DB가 필요할 때 마다 DBCP에서 커넥션을 건네받음 이후 사용을 마치면 반납함.

DB key DB key란 관계형 DB 모델에서 튜플(레코드)을 유일하게 구별할 수 있는 attribute(컬럼) 집합. 다음과 같은 종류 존재. Candidate key Primary key Alternate key Super key Foreign key Super key 튜플을 유일하게 구별할 수 있는 attribute 집합. (key의 정의와 상동) Attribute 전체 집합은 무조건 super key이므로, 모든 relation은 한 개 이상의 super key를 가짐. 최소성을 만족하지 않음. 어떤 super key의 proper subset 역시 super key가 될 수 있음. Candidate key Super key 중에서 최소성을 만족하는 key.