대용량 데이터를 색인하려면... 먼저 이것부터 해결하세요.

대부분의 검색엔진이 이제는 색인 속도면에서 뒤지지 않는다. 각 회사마다 나름 튜닝을 많이 한것 같다.

하지만 아직도 그리고 미래에도 해결하기 힘든 문제가 있다.

 

바로 bulk 파일을 DB로 부터 내려하는데, 이 때 무진장 시간이 오래걸린다.

 

이 경우 DBA의 도움을 받으면 되는데, 똘똘한 DBA가 프로젝트 현장에 많이 없다.

 

첫번째 느린 이유는 테이블에 특정 조건을 걸고 데이터를 내리는 경우이다.

이 경우 파티셔닝을 통해서 해결할 수 있다. 다행히 그 조건이 지역처럼 딱 맞아 떨어지는 경우만 참 좋다.

기간일 경우 월별로 파티셔닝을 해서 bulk 파일을 내리면 된다.

속도를 비교하자면 최소 3배 이상 날 것이다.

 

두번째 Join을 하는 경우가 있다. 이 경우 어떠한 방법을 사용하더라도 느리다.

그래서 획기적인 방법이 아니라도 개선시킬 수 있는 방안은

1. Nested Join을 하지 말고 Hash Join을 건다.

   (오라클 옵티마이저가 자동으로 해주긴 하지만 가끔씩 안되는 경우가 있다.)

   Hash Join을 할 경우 내부적으로 조인을 한 후 데이터가 나오기 때문에 실행 후 몇십분동안 아무것도 안하가 가만히 있을 수 있다. 그래도 참고 기다리면 된다. 내부적으로 Join이 완료되면 무진장 빠른 속도로 bulk 파일이 만들어진다.

   바로 이때도 느린 사이트가 있다면 DBA를 별도로 두기 힘든 사이트라면 약간의 비용으로 DB 서버 메모리를 확충하라고 충고한다. 100% 효과 있으니 무조건 추천한다. 검색엔진이 얼마 짜린데 고작 몇십만원 아까워서 그런다면 사장님한테 이야기해서 메모리를 사주라고 한다. 접대비로 몇십만원 쓰는것보다 메모리 몇십만원 사주는게 더 엔지니어한테 고마운 일이다.

 

2. 큰 테이블 하나가 있고 나머지 테이블의 사이즈가 작다면 별도 bulker 프로그램을 개발하라.

   큰 테이블을 Full Scan 하면서 데이터를 가지고 오고 작은 테이블은 bulker 프로그램이 로딩할때 미리 메모리에 올려두어서 큰 테이블의 데이터를 bulk 파일에 쓸때 메모리에서 조회해서 같이 쓰면 된다.

   현재까지 나온 방법중에서 이 방법이 가장 빠르다고 생각한다.

 

세번째는 View를 조회할 경우이다. VIew 경우엔 웬만하면 일반 SQL로 바꾸어서 튜닝을 통해서 문제를 해결하기 바란다.

VIEW를 일반 SQL로 바꾼다면 위 첫번째 두번째에 모두 해당한다.

 

네번째는 흠... 이건 다음에...