캐시 : 데이터나 값을 미리 복사해 놓는 임시 장소입니다. 캐시에 데이터를 미리 복사해 놓으면, 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있습니다.
캐시에 모든 데이터를 다 담아둘 수 없기 때문에, 캐시의 크기가 제한되고 그에 따라 캐시가 대체되어야 합니다. 캐시 교체 알고리즘에 따라 어떤 파일을 버리고 새로운 캐시를 저장할지 결정하는 것이 캐시 교체 알고리즘입니다.
종류
1. FIFO - 캐시 내에 오래 있었던 페이지 교체, 자주 사용되는 페이지가 교체될 우려가 있음.
2. LFU - 사용 횟수가 가장 적은 페이지 교체, 최근 적재된 페이지가 교체될 우려가 있음.
3. LRU - 가장 오랜동안 사용되지 않은 페이지 교체, time stamping에 의한 오버헤드 존재
* 페이지 : 주기억 장치의 물리적 용량을 구분하는 단위. 주기억 장치와 보조 기어 장치 사이의 전송 단위이고, 한 페이지는 물리적 기억 장치의 한 블록에 해당하며 1kb, 2kb, 4kb 의 크기를 갖는다.
* 오버헤드 : 운영체제가 시스템을 관리하는 데 필요로 하는 CPU 타임이나 메모리 용량
stackOverflow :
재귀함수, 함수 호출 시 이전의 호출한 스택 메모리는 종료하면 된다. 이를 꼬리 재귀 라고도 한다
상호참조, 두 클래스간에 생성을 위임하면서 체이닝을 이루게 되면 발생한다. 해결방법은 상호간의 생성관계를 만들지 않거나, 인스턴스를 직접 생성하기 보다 주입을 통해서 인스턴스를 생성하면 된다.
DB Index : 인덱스는 조회를 성능을 향상 시키기 위해 사용한다. 그러므로 update, insert에 대한 성능을 개선하기 위해 인덱스를 사용한다고 하면 잘못된 개선 방향이다.
: 특정 테이블에 수십만개의 데이터가 저장되어 있을 경우를 가정해보자. 저장된 데이터에서 검색 조건으로 특정 ROW를 추출하는 기능이 있다. 인덱스를 지정해 놓지 않았다면 데이터베이스는 해당 테이블을 처음부터 끝까지 조회하면서 값을 반환하기 때문에 트래픽에 따라 성능이 저하될 수 밖에 없다. 이러한 이슈를 해결하고자 인덱스를 활용하여 자주 조회되는 Column에 대한 인덱스 테이블을 따로 만들어 해당 테이블로 조회할 수 있도록 최적화 하였다.
인덱스를 사용하면 얻을 수 있는 장점은 무엇일까?
1. 인덱스 필드를 사용하면 검색과 정렬 속도를 향상 시킬 수 있다.
2. 테이블의 기본키는 자동으로 인덱스로 적용된다.
3. 테이블 조인에서도 인덱스된 필드를 사용하면 성능을 향상 시킬 수 있다.
4. 그룹화 작업의 속도를 향상 시켜준다.
인덱스 사용시 단점은 없을까?
1. 인덱스 테이블은 이진트리 검색을 사용하기 때문에 기본적으로 정렬되어 있기 때문에 인덱스 필드에 대한 삽입, 삭제, 수정이 빈번히 발생할 경우, 인덱스 테이블 또한 재정렬이 필요하기 때문에 전체적인 성능 저하가 발생할 수 있다.
2. 필드에 인덱스를 추가할 수록 인덱스 생성 파일의 크기가 커지기 때문에 데이터베이스에 추가적인 공간이 필요하다.
3. 고유한 값이 아닌 필드를 인덱스 하게 되면 성능이 향상되지 않는다.
4. 인덱스를 생성하는 데 상당한 시간이 소요된다.
INDEX 사용시 주의사항
1. delete 할 경우, 데이터는 제거되었지만 인덱스는 지워지지 않고 표시만 되어 삭제되는 데이터가 증가할 수록 인덱스의 성능 향상이 저하된다.
2. 갑자기 인덱스를 추가할 경우, 기존 쿼리에 옵티마지어가 실행계획을 바꾸는 경우가 생겨 갑자기 느려질 수 있다.
3. between, like, <, > 등 범위 조건은 해당 컬럼은 인덱스를 타지만, 그 뒤 인덱스 컬럼들은 인덱스가 사용되지 않습니다.
4. 반대로 =, in 은 다음 컬럼도 인덱스를 사용합니다.
5. AND연산자는 각 조건들이 읽어와야할 ROW수를 줄이는 역할을 하지만, or 연산자는 비교해야할 ROW가 더 늘어나기 때문에 풀 테이블 스캔이 발생할 확률이 높습니다.
6. 인덱스로 사용된 컬럼값 그대로 사용해야만 인덱스가 사용됩니다.
ex) where salary * 10 > 150000;는 인덱스를 못타지만, where salary > 150000 / 10; 은 인덱스를 사용합니다.
SQL : 관계를 맺고 있는 데이터가 자주 변경되는 경우, 또 명확한 스키마가 사용자와 데이터에게 중요한 경우 관계형 데이터베이스를 사용하는게 좋다. 금융 산업과 같은 시스템의 형태가 급격하게 변하지 않으면서 그 안의 데이터가 계속 바뀌는 보수적인 시스템에서 유리하다.
ACID 특성을 따르는데, ACID는 DB의 트랜잭션이 안전하게 수행되는 것을 보장하기 위한 특징이다.
NoSQL : 비관계형 데이터베이스는 정확한 데이터 구조를 알 수 없거나 변경 / 확장 될 수 있는 경우 (수평적으로), 읽기 처리는 많이 하지만, 데이터를 자주 변경하지 않는 경우 사용하면 유리하다. CAP 이론
*옵티마이저 : 가장 효율적인 방법으로 SQL을 수행할 최적의 처리 경로를 생성해주는 DBMS의 핵심 엔진입니다. 실행 계획을 세우는 방식에 따라 규칙 기반 옵티마이저(실행우선 순위)와 비용 기반 옵티마이저(액세스 비용)로 나뉜다.
*트랜잭션 : 데이터베이스의 상태를 변환시키는 기능을 수행하기 위한 하나 이상의 쿼리를 모아놓은 하나의 작업 단위를 말한다.
*ACID : 데이터베이스 내에서 일어나는 하나의 트랜적션의 안전성을 보장하기 위해 필요한 성질이다.
Atomicity(원자성) : 시스템에서 한 트랜잭션의 연산들이 모두 성공하거나, 반대로 모두 실패되는 성질을 말한다.
Consistency(일관성) : 일관성은 하나의 트랜잭션 이전과 이후, 데이터베이스는 데이터베이스의 제약이나 규칙을 만족해야 한다.
Isolation(고립성) : 모든 트랜잭션은 다른 트랜잭션으로부터 독립되어야 한다.
Durability(지속성) : 하나의 트랜잭션이 성공적으로 수행되었다면, 해당 트랜잭션에 대한 로그가 남아야하는 성질. 만약 런타임 오류나 시스템 오류가 발생해도 해당 기록은 영구적이어야 한다.
분산 데이터베이스 : 분산 데이터베이스 시스템의 장점은 명확하다. 사용자 트래픽이 늘어남에 따라, 데이터베이스 관리자는 분산 데이터베이스 환경에 노드를 더함으로써 쉽게 수평 확장할 수 있다. 일반적으로 수직 확장보다 수평확장이 저렴하기 때문에 대용량 데이터와 트래픽에 효율적으로 대응할 수 있다.
*CAP 이론:
Consistency(일관성) : 사용자가 분산 데이터베이스 상의 어떤 노드와 통신하는 지 상관없이 같은 데이터를 조회할 수 있는 것을 의미한다.
Availablity(가용성) : 가용성이란 모든 요청이 응답을 받을 수 있어야 한다는 것을 의미한다. 중단 되는 일 없이 언제든지 사용 가능.
Partition Tolerance(분할 허용성) : 분할 허용성이란 시스템 내 분할이 생겼을 때 시스템이 여전히 작동하는 것을 의미한다.
CAP 이론이란 분산 데이터베이스 시스템은 분할이 생겼을 때 일관성과 가용성 중 하나를 희생해야 한다는 것을 의미한다. 분산 데이터베이스 시스템은 반드시 네트워크 장애나 여러 이유들로 인해 장애가 발생할 수 밖에 없다. 그러므로 분산 데이터베이스 시스템은 반드시 분할 허용성을 가지고 있어야 하며, 일관성과 가용성 중 하나를 선택해야만 한다.
