Apache Commons DBCP 2.9 - 아파치의 커넥션 풀 오픈소스인 Commons DBCP는 BasicDataSource라는 타입으로 DataSource를 제공한다. - 커넥션 풀 및 DataSource의 기본 개념이 필요하다면 포스팅을 참고해 주시길 바란다. 커넥션 풀 자료구조: LinkedBlockingDeque DBCP2 기준으로 커넥션 풀은 LinkedBlockingDeque 타입의 객체로 관리된다. 아파치가 커넥션 풀 구현체는 덱 기반으로 한 이유는 'lifo' 설정 때문이다. 커넥션 풀 설정 값에 lifo라는 프로퍼티가 있는데, 이 값을 true로 할 경우 stack 기반으로, 그렇지 않을 경우엔 Queue 기반으로 동작한다. LinkedBlockingDeque의 요소는 Node 타입..

DB Partitioning - 서비스의 크기가 점점 커지고 데이터의 규모 또한 커지면서, DB 시스템의 용량(storage)의 한계와 성능(performance)의 저하를 유발하게 되었다. - 이에 대한 해결책으로 테이블을 파티션이라는 단위로 나눠어 관리하게 되었으며 이러한 과정을 DB 파티셔닝이라고 한다. - 이러한 관점에서 보았을 때 데이터베이스 정규화(Normalization)도 일종의 파티셔닝으로 볼 수 있지만 파티셔닝은 성능 향상을 목적으로 하며 정규화는 중복된 데이터 방지 및 이상현상(Anomaly) 예방을 목적으로 한다. 1. Vertical Partitioning (수직 파티셔닝) 말 그대로 테이블의 컬럼을 기준으로 수직으로 파티셔닝 하는 것을 의미한다. 예시 게시글 데이터를 의미하는 a..

트랜잭션의 특징 : ACID - Atomicity(원자성) : All Or Nothing - Consistency(일관성) : 일관성 있는 DB 상태를 유지해야 함(정해진 DB컬럼에 대한 일관성, 제약조건에 대한 일관성 등) - Isolation(격리성) : 트랜잭션 간 얼마나 영향을 주고받냐를 설명함(4가지 격리수준 참고) - Durability(지속성) : 트랜잭션 결과는 항상 DB에 기록되어야 하며 문제가 발생하더라도 복구할 수 있어야 함 트랜잭션은 위 4가지 성질을 모두 만족해야 한다. 하지만 Isolation의 경우 완벽한 격리를 하게 될 경우 트랜잭션들 간에 완전히 순차적으로 실행되어야 하기 때문에 성능상 이슈가 발생할 수 있다. 따라서 Isolation의 경우는 4가지 수준으로 구분하며 "얼..

애플리케이션에서 데이터베이스와 커넥션을 생성하는 과정 1) 애플리케이션 로직은 DB 드라이버(어떤 DB를 사용할 것이냐에 따라 다름)를 통해 커넥션을 조회한다. 2) DB 드라이버는 DB와 TCP/IP 커넥션을 맺는다. (3-way handshake 발생) 3) TCP/IP 커넥션이 완료되면 DB 접속을 위한 ID 및 Password 등과 같은 정보를 DB에 전달한다. 4) DB는 사용자 인증을 완료하면 DB 내부적으로 세션을 만든다. 5) DB는 커넥션 생성이 완료되었다는 응답을 보낸다. 6) DB 드라이버는 애플리케이션 로직으로 커넥션 객체를 반환한다. 단점 - 커넥션을 생성하는 것은 복잡하고 시간도 오래 소요되는 과정이다. - 시간이 오래 걸리기 때문에 사용자에게 느린 응답을 보일 수밖에 없다. -..

데이터베이스에 인덱스가 없다면 테이블에 데이터가 삽입되는 순서는 특정 제약이 없다. 또한 데이터 조회 시(일반적인 where절 사용) 테이블 풀스캔이 발생한다. 이때 match 되는 데이터를 찾더라도 데이터 순회를 끝내는 것이 아니라, 테이블의 끝까지 데이터를 '순차 탐색'하면서 match 되는 데이터를 '모두' 찾는다. 이러한 테이블 풀스캔이 항상 나쁘다고 할 순 없지만 데이터가 많아질수록 성능에 문제가 발생할 것이다. 물리적으로는 한 테이블의 데이터 record들이 위와 같은 페이지 구조로 저장된다. 만약 record들을 특정 컬럼 기준으로 정렬해서 저장한다고 하면 테이블 풀스캔을 하지 않고도 찾고자 하는 데이터를 찾을 순 있지만 순차 탐색을 해야 한다는 단점이 존재한다. 이를 해결하기 위한 가장 대..

Type Of Index single level index composite index multilevel index 1. Single Level Index - 인덱싱하는 컬럼이 1개인 경우에 해당함 - primary key에 걸면 Primary Index(기본 인덱스), 다른 컬럼에 걸면 Secondary Index(보조 인덱스) - SQL문에서 where = {key1} = {value1} 가 하나인 경우 equality search가 빠르다. - 메모리에 index table의 데이터 크기가 table보다 작음 - 카디널리티가 매우 낮은 컬럼이라면 인덱스를 지정하지 않는 것이 더 나을 수도 있음 [인덱스 정렬 타입] 1) Dense Index(밀집 인덱스) - 한 인덱스에 원하는 데이터가 바로 매칭..

Balanced Tree - 한쪽으로 노드가 몰리는 Binary Search Tree의 단점을 보완하고자 등장 - DBMS에서 가장 범용적으로 사용되는 자료구조 - Binary Search Tree와 유사하지만 depth를 자동으로 잡아주기 때문에 탐색 시간복잡도가 O(logN)을 보장함 - 하지만 depth에 영향을 줄 수 있는 insert, delete 경우에 대해서는 성능이 좋지 않을 수 있음 - 결론적으로, 데이터를 얼마나 자주 삽입, 삭제할 것인가에 따라서 B-Tree Index를 활용할지 말지를 결정 - 즉, 갱신 빈도가 높은 테이블에 인덱스를 지정할 경우, 인덱스 재구성 발생 빈도가 높아진다는 점을 고려해야 함 B-Tree - 하나의 노드에 여러개의 값이 배치되는 구조의 트리 - 차수 M의 ..

개요 - 게시글을 의미하는 post와 작성자를 의미하는 member 테이블을 만든다 - post 테이블에서 FK로 member의 id를 갖도록 구성한다. - post 테이블에서 member_id에 인덱스를 지정할 경우와 그렇지 않은 경우에 대해 분석한다. - post 테이블에는 데이터를 10,000개 넣어두고 분석한다. 인덱스를 설정하지 않은 경우 실행쿼리) select * from post where post_owner_id = 1 소요시간) 466 ms (execution: 147 ms, fetching: 319 ms) 실행계획 분석 쿼리) explain select * from post where post_owner_id = 1; 분석 결과 - type 항목이 ALL 이므로 최악인 '테이블 풀 스캔..

트랜잭션의 특징 (ACID) 원자성 (Atomicity) : 트랜잭션의 수행 결과는 DB에 모두 반영되던가, 그렇지 않던가 둘 중 하나여야 한다. 일관성 (Consistency) : 트랜잭션 수행 결과는 항상 일관성이 있어야 한다. 트랜잭션 시작 시에 참조한 DB상태를 기준으로 트랜잭션을 수행하고 트랜잭션 도중에 변경된 DB를 기준으로 하지 않는다. 따라서 사용자는 일관된 데이터를 볼 수 있도록 한다. 독립성 (Isolation) : 다수의 트랜잭션이 서로의 트랜잭션 연산에 끼어들 수 없다. 트랜잭션들끼리 동시에 수행될 수 없다는 의미가 아니다. 동시에 실행은 될 수 있으나 트랜잭션 도중의 결과를 다른 트랜잭션이 참조할 수 없다는 것을 의미한다. (serializable) 지속성 (Durability) ..

실행계획이란 말 그대로 요청받은 SQL문으로 데이터를 옵티마이저가 '어떻게 가져올 것인지'에 대한 계획 또는 경로를 의미한다. 같은 데이터를 가져오더라도 지름길을 통해 가져온다면 더 효율적으로 데이터를 가져올 수 있을 것이다. 요청할 SQL문의 실행계획을 확인하려면 EXPLAIN, DESCRIBE, DESC 중 아무 키워드나 사용하면 된다. EXPLAIN 키워드를 사용해 SQL의 실행계획을 확인해보면, 다음과 같이 id, select_type, table, type, key 등의 정보가 출력된다. 위 사진은 임의의 post라는 테이블에 explain select * from post; 쿼리를 보냈을 경우 실행계획을 보여준다. 이 정보들을 통해 옵티마이저가 요청받은 SQL문을 비효율적으로 수행하진 않는지,..