(어플리케이션 개발) 데이터베이스 주의사항

*애플리케이션 개발 후 회원수가 많아져서 로그인 과정이 예전보다 상당히 느려진 경우

-> 서버에 투자하는 것 보다는 효율적인 인덱스 구성과 인덱스에 맞는 쿼리를 구현하는 일이 더 바람직하다.

주의사항: 회원테이블의 기본키를 무심코 회원ID로 정의하면 안된다. 기본키를 일련번호 칼럼으로 정의해야 한다.
예를들어, Korea라는 회원ID를 사용하고 있던 회원이 물건을 구매한 후 탈퇴를 했다고 가정하자. 그러면 그 회원의 데이터를 지울 수 있는가? 지울 수 없다. 왜냐하면 물건을 구매했기 때문에 그 회원의 회원ID가 상품 테이블의 포린키로 남아있기 때문이다.


그러므로 회원ID칼럼과 비밀번호 컬럼에 인덱스를 부여해야 한다.
그리고 당연히 각각으 칼럼에 인덱스를 부여하는 것 보다 두 개의 칼럼을 하나의 인덱스로 구성해야 한다.

인덱스 유형은?

회원 테이블의 기본키인 회원번호는 분명 넌 클러스터드 인덱스로 만들어져야 하며 회원ID와 비밀번호 칼럼에도 역시 넌 클러스터드 인덱스를 만들어야 할 것이다.

그러면 어떠한 칼럼에 클러스터드 인덱스를 만들까? 그것은 조회의 조건에도 자주 등장하면서 데이터가 순차적으로 입력되는 칼럼에 부여하는 것이 좋다. 아마도 등록일 컬럼이 될 듯 싶다.

조회문장(Query)에 대한 고려

Select * from 회원 where 회원ID='1111' and 비밀번호='1111'

이거은 조건에 맞는 해당 회원의 모든 컬럼의 데이터를 가져오라고 하는 것이므로 검색 프로세서는 인덱스의 리프레벨에서 해당 회원의 존재유무를 확인했지만 해당 회원의 모든 칼럼을 가져오기 위해 데이터 페이지까지 내려가서 데이터를 가져오는 작업을 진행하게 된다.

단지, 회원을 인증하기 위해 질의를 하는 것이지 회원의 정볼르 보기 위해 질의를 하는 것이 아님을 명심하자

그러므로

Select 회원ID from 회원 where 회원ID='1111' and 비밀번호='1111'

이렇게 되면 원하는 데이터를 인덱스의 리프 레벨에서 찾을 수 있으며 불필요하게 다른 데이터를 가져오기 위해 데이터 페이지까지 내려가지 않아도 되므로 성능에 도움이 된다.

****Select절에서 * 대신 조회하기 원하는 컬럼명만 조회하는 습관을 들이자.

2. 포린키(Foreign Key)에 인덱스를 부여하는 것을 고려하자

테이블의 연관된 정보를 보기 위해서 조인을 수행할 때 기본적으로 부모 테이블의 기본키와 자식 테이블의 포린키를 조인하게 된다. 조인은 데이터를 비교하는 프로세서이다.
조인의 대상이 되는 데이터를 비교해서 원하는 결과를 리턴하게 되는데 부모 테이블의 기본키에만 인덱스가 존재하고 포린키에 아무런 인덱스도 만들어지지 않았다면 당연히 조인의 성능이 좋을 수 없다.

보통 두 테이블의 관계에 있어서 차수에 따라 다른 유형의 인덱스 구성이 필요하다.

1:1유형은 굳이 클러스터드 인덱스를 구성할 필요없다. 왜냐하면 질의의 유형이 포인트 쿼리이기 때문이다.

1:N유형은 당연히 범위조회(Range Query)성격이 강하므로 클러스터드 인덱스를 만들어주는것이 거의 모든 경우에 유리하다.

3. 데이터의 사용량을 분석해야 한다.

입력,수정,삭제 빈도가 높은 테이블이라면 적절하게 Index의 채우기 비율을 설정해주는 것 또한 빠뜨리지 말아야한다. 그래야 페이지 분할(Page Split)현상을 최소화할 수 있따.

4. 하나의 테이블에 들어가는 칼럼의 숫자는 가급적이면 많아야 10개 내외가 될 수 있도록 디자인하자.

당연히 하나의 레코드의 총 사이즈가 커지게 될 것이다. 컬럼의 숫자가 50개라고 가정하고 하나의 칼럼 사이즈를 평균 20Byte라고 한다면 한 레코드의 크기가 무려 1000Byte나 되고 하나의 데이터 페이지 헤더를 제외하고 실제로 데이터가 저장되는 데이터 페이지의 사이즈가 8096Byte이므로 하나의 데이터 페이지에 8개의 레코드밖에 저장되지 못한다.

그러면 데이터를 저장할 때 많은 수의 데이터페이지가 할당되게 되고 이런 상태에서 인덱스를 만들게 되면 당연히 인덱스의 레벨 또한 높아져 성능에 상당히 부정적인 영향을 미친다.

5. 파일 그룹 사용

파일과 파일 그룹의 효과적인 사용은 대용량 데이터베이스를 위한 솔루션이 될 수 있다.

예를들어, 하나의 데이터베이스가 여러 개의 파일로 구성되어 있으며 그 여러 개의 데이터 파일들이 서로 물리적으로 다른 하드디스크에 분할되어 있다면 테이블이 위치한 파일 그룹과 인덱스가 위치한 파일 그룹을 서로 다르게 지정함으로써 데이터를 읽고 쓰는데 있어서의 경쟁을 피할 수 있따.

파일과 파일그룹을 적절하게 이용하는 것은 데이터의 읽고 쓰는 경쟁을 효과적으로 피할 수 있기 때문에 성능의 향승을 기할 수 있을 뿐만아니라, 데이터베이스의 백업과 복구 시에도 파일이나 파일 그룹별로 백업과 복구를 할 수 있기 때문에 백업과 복구속도를 향상 시킬 수 있다.