Zero to Hero

대량의 데이터를 고속으로 처리하는 기술

 

인덱스 특징

1. B+Tree 구조를 띄고 있다.

2. 참조 및 갱신이 O(logmN)으로 처리할 수 있어 매우 빠르다.

3. 모든 액세스가 랜덤 액세스다. 액세스 되는 블록이 군데군데 위치하고 있고 HDD는 랜덤 액세스가 매우 느리다.

4. 인덱스가 메모리에 들어가 있는 경우는 매우 빠르지만 그렇지 않은 경우 HDD에 랜점 액세스로 접근해야 하고, 성능은 크게 악화된다.

 

5. 인덱스가 메모리에 올라가지 못한 다는 것은 그만큼 데이터 양이 많아졌다는 뜻이다.

6. 인덱스 크기를 어떻게 하면 줄일 수 있을지를 고민하고, 이를 줄이는 것이 성능 향상으로 이어진다.

7. 처리하는 데이터가 대량으로 되었을 경우에 DML이 느려지게 되면 성능 면에서 큰 리스크를 책임 저야 한다.

 

해결방법 1, 레인지 파티셔닝

1. 테이블 및 인덱스를 한 개가 아닌 내부적으로 복수로 분할하여 관리하는 기술

2. 특정 파티션에 접근을 집중시킬 수 있다면 전체 인덱스 크기 보다도 압도적으로 액세스 범위가 좁아지므로 그 파티션은 메모리에 올릴 수 있어 액세스 성능을 크게 향상할 수 있다.

3. 도메인의 특징에 따라서, 예를 들면 SNS 서비스의 경우 최근의 데이터를 조회하거나 조작하는 경우가 거의 대부분이다. 이를 이용해서 최신 파티션에 액세스가 집중하기 때문에 레인지 파티셔닝으로 성능을 향상할 수 있다.

 

해결방법 2, B+Tree 이외의 인덱스 자료 구조

1. ToKuDB의 경우 Fractal Tree라는 자료 구조를 사용해 보조 인덱스 크기가 아무리 커져도 INSERT 성능이 항상 일정한 라인으로 빠른 속도를 낼 수 있다.

2. 레인지 파티셔닝이 필요 없다는 장점이 있다

 

해결방법 3, SSD 사용하기

1. HDD 대신 SSD를 사용해 랜덤 액세스 성능이 심각한 문제가 되지 않게 한다.

 

해결방법 4, 트랜잭션

1. 트랜잭션을 지원하지 않으면 오류가 발생했을 때 일관성이 보장되지 않는다는 문제가 있다.

2. 슬레이브가 다운되었을 때 슬레이브는 어디까지 업데이트를 완료하고 어디에서 복제를 다시 시작하면 좋은가라는 정보를 필요로 한다.

3. 그러나 트랜잭션을 지원하지 않으면 이 정보가 맞다는 보장이 전혀 없다.

4. 즉 다시 시작하여 복구할 수 있는 보장이 없기 때문에 데이터를 처음부터 다시 작성해야 한다. 이것은 데이터양의 크면 클수록 복구에 시간이 걸리게 된다.

5. 또 트랜잭션을 지원하지 않으면 마스터에서 장애가 일어나거나 오퍼레이션 실수 등의 잘못된 업데이트가 발생했을 때 올바른 결과와 데이터를 가지고 있는 서버는 존재할 수 없다.

6. 그러므로 백업은 정기적으로 가지고 갈 필요가 있지만 트랜젝션을 지원하지 않는 데이터베이스 제품은 서버 업데이트를 중지하는 것 밖에 일관성 있는 백업 방법이 없다.

 

출처 및 참고문헌

데이터베이스를 지탱하는 기술
국내도서
저자 : 마쯔노부 요시노리 / 정인식역
출판 : 제이펍 2012.11.18
상세보기
profile

Zero to Hero

@Doljae

포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!