티스토리 뷰

Federated Engine 의 경우

네트워크를 통해 조회를 해주는 편리함을 제공한다.


저 엔진을 사용하게 된 사례는 다음과 같았다.

글 데이터 DB
로그 데이터 DB

두 DB 의 테이블 간 JOIN 조회가 필요했다.


기존의 경우라면
새벽에 서버를 끄고 켜가며 Replication 관계를 셋팅해줘야 했을 것이다.

스트레스를 받고 있던 차에
Federated Engine 이란것을 알게 되었다.


바로 적용해본다.

양쪽 서버 shutdown 필요 없이
Create Table ( ... ) Engine=Federated 문법으로 테이블 생성만 해주면
바로 원하는 테이블을 localhost DB 서버에서 조회 할 수 있게된다.


문제는 테이블이 대용량일때 발생했다.

Federated engine 쓰는 테이블에 SELECT 쿼리를 한번 하는데
엄청난 시간이 소요되다가
OOM (Out of memory) 메세지만 반환되었다.

저 엔진을 사용하면 네트워크를 통해 끌어오므로
작은 범위로 축소된 결과셋을 가지고 오도록
조건절을 만들어 최대한 범위를 줄여줘야 한다.

또한, 쿼리가 인덱스를 잘 타는가?를 분석해보고
최적화 해야 한다.

인덱스를 탄다는것은
primary key 이던 key 이던 index 지정된 필드를 통해
빠르게 조회 한다는 말과 같다.

# 최적화 전 쿼리
# 이 쿼리 사례에서 인덱스는 id, id_desc, regdate 라고 가정한다
# id_desc 의 경우 id * -1 로 Order By id_desc ASC 순차정렬에 사용하기 위한 필드

Select id,title From document Where `publish`='1' and `id_desc` <= 0 Limit 10;

# explain 명령으로 쿼리 실행계획 분석

explain Select id,title From document Where `publish`='1' and `id_desc` <= 0 Limit 10;

# explain 결과를 분석해보자... 
# type 이 range 등이 아닌 all 이 나와버리면 최악이다.
# federated engine 테이블이므로 네트워크를 통해 모든 레코드를 일단 전체 다 들고 온다는 의미
# possible_keys, key 의 결과들은 NULL 이 아니게 해야 하며
# 최대한 인덱스를 타도록 key 들이 사용되었는가? 인덱스 필드 아닌 키가 사용되었다면 빼고 대체 가능한 인덱스 필드를 쓰도록 쿼리 수정
# Extra 에서는 사용된 조건들을 기술해주는데, Using index ... 가 있다면 잘 짜인 쿼리인 것이나 무조건 있어야 되는 값은 아님

# 최적화 한 쿼리...
# 1일 전 regdate 조건 추가하여 조회하여 가져오는 범위 줄임 (regdate 필드는 index 필드로 가정)
# order by IDX_INTIME 추가하여 정렬 인덱스를 타도록 함

explain Select id,title From document Where regdate >= '2016-05-11' and `publish`='1' Order By id_desc Limit 10

DB 쿼리 타임아웃 시간 다 채우고 Out of memory 오류 반환하던 SELECT 쿼리가
오류 없이 실행시간 65.9 ms 와 함께 이상 없이 실행되도록 최적화 했다.


댓글
댓글쓰기 폼
Total
818,138
Today
266
Yesterday
322
«   2020/02   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
글 보관함