데이터베이스에서 인덱스란?
인덱스를 사용하는 이유?
그렇다면 인덱스를 무조건 사용하는 것이 좋은가요? 아니라면 왜 인가요?
인덱스로 지정하면 좋은 Column은 어떤 것인가요?
인덱스를 사용하는 알고리즘에는 무엇이 있나요?
데이터베이스의 칼럼을 색인화하는 것을 인덱스라고 한다. 인덱스를 사용하게 되면 테이블을 풀스캔하지 않고도 빠르게 조회할 수 있게되는 것이 장점이다. 그러나 DML (INSERT, DELETE, UPDATE)이 일어나게 되면 오히려 성능이 떨어질 수 있다. 그 예로, 10만 개 이상의 레코드가 존재할 때 10개의 레코드만 남기고 DELETE 연산을 하게 되면 실제 데이터는 10개인 반면에 인덱스는 여전히 남아있어서 실제 데이터보다 많은 용량을 차지하고 있을 수도 있게된다. 따라서 인덱스는 조회를 주로하는 테이블에 사용하면 좋다.
인덱스는 차수degree가 높은 Column에 적용하면 좋은데, 또한 선택도가 5~10%인 차수에 적용하면 좋다고 한다.
인덱스를 만드는 알고리즘은 주로 B Tree 알고리즘을 사용한다.
B Tree 알고리즘은 이진 트리를 사용하여 만들어진 알고리즘으로, 주로 범위 연산을 할 때 사용하게 된다. (부등호) 그 밖에는 해시 알고리즘이 있는데 칼럼의 내용을 인덱스로 만들어 사용하므로 속도가 매우 빠르다. 그러나 칼럼의 일부만을 가지고 탐색할 수 없기 때문에 등호 연산만 가능하다는 단점이 있다.
View는 무엇인가요?
View를 사용하는 이유?
View의 장단점
뷰는 가상 테이블이다. 기반 테이블에서 SELECT 연산을 미리 해놓은 결과값을 물리 테이블이 아닌 가상 테이블로 저장해둔 것이다. 뷰를 사용하게 되면 보안이 좋아지게 된다. 기반 테이블(원본)을 두고 사용자에게 보여주고 싶은 정보만 뷰로 보여줄 수 있기 때문이다. 또한 뷰를 변경하더라도 기반 테이블이 변경되지 않는다. 뷰를 기반으로 또 뷰를 만들 수 있고, 삭제할 때에는 CASCADE 연산으로 연관 뷰를 함께 삭제하거나 RESTRICT를 사용하여 연관된 뷰가 있다면 삭제가 불가능하게 만들 수도 있다. 단점이 있다면 ALTER 연산이 불가능하기 때문에 직접적으로 뷰의 데이터를 변경하려면 DROP한 뒤 재생성해야하는 점이다.
Transaction이란 무엇인가요?
Transaction의 특성에 대해 말해주세요.
Transaction isolation level이란 무엇인가요?
트랜잭션이란 작업의 단위라고 볼 수 있다. 트랜잭션이란 작업의 완전성을 보장해주는 것이다. 트랜잭션은 CREATE, UPDATE, INSERT, DELETE와 같은 연산들의 집합. 처리 단위라고 할 수 있는데, 이러한 연산들이 모두 처리되거나, 실패할 경우 전부 처리되지 않고 원상태로 돌아올 수 있도록 만들어주는 것을 말한다.
트랜잭션이 성공적으로 완료된 이후에는 Commit 연산이 수행되며 실패한 경우 Rollback 연산이 수행된다.
Commit은 하나의 트랜잭션이 성공적으로 끝났다는 것을 보고하기 위한 연산이고, Rollback은 처음부터 트랜잭션을 다시 시작하거나 부분적으로 취소시키는 것이다.
SQL Server는 기본적으로 Auto commit이며, 오라클이나 mysql에서는 수동커밋이다. 자동커밋으로 설정을 바꿀 수도 있다.
트랜잭션의 ROLLBACK 방식에는 크게 2가지가 있는데 undo와 redo가 있다.
undo는 ROLLBACK 이후에 원상태로 복귀하는 것이고 redo의 경우는 ROLLBACK 이후에 다시 기존의 트랜잭션을 수행하는 것이다.
트랜잭션과 Lock
잠금과 트랜잭션은 비슷한 개념같지만 잠금은 동시성을 제어하는 기능이고, 트랜잭션은 데이터의 정합성을 보장하기 위한 기능이다.
트랜잭션은 4가지의 특성을 만족해야하는데, ACID라는 특성이다.
원자성Atomicity : All or Nothing. 트랜잭션은 전부 실행되거나, 중간에 문제가 발생한다면 아무 것도 실행되면 안 된다.
일관성Concictency : 기존의 일관성있는 데이터를 트랜잭션 수행한 이후의 데이터도 일관성이 지켜져야 한다.
고립성Isolation : 트랜잭션은 다른 트랜잭션의 영향을 받으면 안된다.
지속성Durability : 트랜잭션의 종료 이후에는 영구적으로 데이터베이스에 작업의 결과가 저장된다.
트랜잭션은 이러한 특성을 만족하기 위해 Isolation level을 사용한다.
트랜잭션이 독립적인 수행을 하도록 로킹을 사용하여 트랜잭션을 수행하는 동안 다른 트랜잭션이 관여할 수 없도록 만든다.
격리 수준에는 4가지 종류가 있다.
1. Read Uncommitted (Level 0)
아무 것도 격리되지 않은 단계이다. 트랜잭션이 처리중이거나, 아직 Commit되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용한다. (데이터베이스의 일관성 유지가 불가능하다)
2. Read Committed (Level 1)
SQL Server의 기본 트랜잭션 격리 수준이다. 트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없다. Commit이 이루어진 트랜잭션만 조회가 가능하다.
3. Repeatable Read (Level 2)
트랜잭션이 범위 내에서 조회한 데이터 내용이 항상 동일함을 보장한다. 트랜잭션 수행동안 해당 영역의 데이터에 대한 수정이 불가능하다.
4. Serializable (Level 3)
완벽한 읽기 일관성을 제공한다. 트랜잭션 수행동안 해당되는 데이터의 수정 및 입력이 불가능하다.
낮은 격리 수준을 사용하게 되면 Dirty Read (수정중인 데이터를 다른 트랜잭션이 읽는 경우), Non-Repeatable Read (트랜잭션 도중 다른 트랜잭션이 해당 값을 수정/삭제하여 일관성이 깨지는 현상), Phantom Read(트랜잭션이 새로운 레코드를 만들었을 때, 다른 트랜잭션이 읽으려던 데이터가 아닌 새로운 레코드를 읽게 되는 경우) 현상이 나타날 수 있다.
병행제어와 로킹제어에 대해 말해주세요.
둘의 차이점은 무엇인가요?
커넥션 풀이란 무엇인가요?
커넥션 풀을 사용하는 이유?
커넥션 풀이란 페이지에 접속할 때 필요한 DB 커넥션을 미리 만들어 놓고, 가져다 쓸 수 있도록 만들어놓은 것이다. 기존에 필요한 DB 커넥션을 필요할 때마다 만든다면 2-3초간의 로딩이 더 걸리겠지만, 미리 커넥션을 만들어 놓고 가져다 쓴 뒤, 반납하게 만든다면 기존의 DB 연결보다 빠르게 연결할 수 있다.
커넥션 풀은 이처럼 데이터베이스 성능과 연관이 있는 TPS(Transaction per seconds)와 밀접한 연관이 있다. 커넥션 풀에서 커넥션을 가져다 쓸 경우 TPS의 속도가 굉장히 빨라지지만, 만약 커넥션의 max값이 5개 일때, 5개 초과로 커넥션을 요청하게 되면 5개까지의 응답시간은 빠를 것이다. 그러나 이후의 요청은 이전 커넥션들이 반환될 때까지 대기하게 되면서 느려지게 될 것이다.
그렇다면 커넥션의 max값을 늘리게 되면 어떨까? 사실 실제 서비스 상황에서는 DBMS의 리소스를 다른 서비스와 공유해서 사용하는 경우가 많기때문에 커넥션 개수를 크게 설정할 수 없는 경우가 많고, 예상 접속자 수와 실제 서비스의 부하를 측정해서 최적값을 설정하는 것이 중요하다고 한다. 반대로 max값을 지나치게 줄이게되면 과부하시 오류가 반환되면서 사용자들은 자주 오류 메시지를 볼 수 밖에 없게 된다.
나중을 대비해서 미리 커넥션을 n개 정도 생성해놓는 것이다.
이를테면 쇼핑몰 사이트에서 상품 상세 보기를 클릭 시마다 DB 커넥션이 필요하게 되는데, 이것을 미리 만들어두고 필요할 때마다 만들어놓은 커넥션을 가져다 쓰게 만드는 것이다.
그리고 다 쓴 커넥션은 풀에 다시 반납하게 된다.
DB를 가져올 때의 시간을 줄일 수 있다는 장점이 있다.
다수의 HTTP 요청에 대한 스레드를 효율적으로 처리할 수 있다.
JDBC의 경우 Commons DBCP라는 구현체가 이미 존재하고 이를 사용하여 커넥션 풀을 쉽게 만들 수 있다.
TPS는 트랜잭션의 수행 속도를 의미한다. 커넥션 개수가 TPS와 밀접한 연관을 가지는데, 처리할 요청 수가 증가해도 커넥션 풀의 커넥션 개수가 5개라면 10TPS 이상의 속도를 낼 수 없기 때문이다.
따라서 커넥션 풀의 개수를 늘리는 방식으로 문제를 해결할 수 있지만 일반적으로 DBMS는 다른 서비스와 공유해서 사용하는 경우가 많기 대문에 커넥션 개수를 크게 설정할 수 없는 상황이 많다.
따라서 대기 시간과 커넥션 개수를 적절하게 조절하는 것이 중요하다.
'IT > Interview' 카테고리의 다른 글
| 손코딩 면접 준비 (0) | 2020.10.28 |
|---|---|
| 20.10.16 면접 스터디 (0) | 2020.10.16 |
| 20.10.12 면접 스터디 (0) | 2020.10.12 |
| 20.10.09 면접 스터디 (0) | 2020.10.09 |
| 20.10.06 면접 스터디 (0) | 2020.10.09 |
댓글