클 라 우 드 데이터 이전 서 비 스 를 보면 MySQL 큰 표 추출 모델 의 원리 분석

요약:MySQL JDBC 추출 은 어떤 방식 을 사용 해 야 하 는 지,그리고 작은 편집 을 들 어 흥미진진 하 게 이야기 해 준다.
최근 클 라 우 드 의 한 이전 프로젝트 에서 MySQL 추출 모드 에 시 달리 고 있다.처음에 메모리 폭발 은 고객 에 의 해 24636℃가 되 었 고 나중에 이동 효율 이 낮 아 지면 24636℃가 되 었 다.MySQL JDBC 추출 은 도대체 어떤 방식 을 사용 해 야 하 는 지,그리고 편집장 에 게 흥미진진 하 게 들 려 준다.
1.1 자바-JDBC 통신 원리
JDBC 와 데이터베이스 간 의 통신 은 socket 을 통 해 완 료 됩 니 다.대체적으로 다음 그림 과 같 습 니 다.Mysql Server->커 널 Socket Buffer->클 라 이언 트 Socket Buffer->JDBC 가 있 는 JVM

1.2 JDBC 에서 데 이 터 를 읽 는 세 가지 모드
1.2.1 방식 1:JDBC 기본 매개 변수 로 데이터 읽 기
주로 다음 과 같은 몇 단계 로 나 뉜 다.
1)Mysql Server 는 OuputStream 을 통 해 Socket Server 로 컬 Kennel Buffer 에 데 이 터 를 기록 합 니 다.메모리 복사 입 니 다.
2)Socket Server 로 컬 Kennel Buffer 에 데이터 가 있 으 면 TCP 링크 를 통 해 Socket Client 가 있 는 기계 의 Kennel Buffer 로 데 이 터 를 전송 합 니 다.
3)JDBC 가 있 는 JVM 은 InputSream 을 이용 하여 로 컬 Kennel Buffer 데 이 터 를 JVM 메모리 로 읽 고 데이터 가 없 을 때 읽 기 가 차 단 됩 니 다.
다음은 1,2,3 을 반복 하 는 과정 이다.문 제 는 Socket Client 의 JVM 이 기본 모드 에서 Kennel Buffer 를 읽 는 것 은 이 컴퓨터 의 메모리 크기,얼마나 읽 는 지 고려 하지 않 았 다 는 것 이다.데이터 가 너무 크 면 FULL GC 가 발생 하고 이어서 메모리 가 넘 칠 수 있 습 니 다.
JDBC API docs 를 참고 하 십시오.기본 모드 자바 데모 코드 는 다음 과 같 습 니 다.

1.2.2 방식 2:커서 조회
JDBC 는 1 폭 메모리 문 제 를 해결 하기 위해 jdbc 연결 을 만 들 때 useCursor Fetch=true 를 추가 하 는 커서 파 라 메 터 를 제공 합 니 다.커서 를 설정 하면 JDBC 는 서버 측 에 매번 추출 한 데 이 터 량 을 알려 메모리 폭발 을 피한다.통신 과정 은 아래 그림 과 같다.

방식 2 커서 조 회 는 메모리 가 넘 치 는 문 제 를 해결 하지만 방식 2 는 네트워크 품질 에 크게 의존한다.네트워크 지연 이 커지 면 매번 통신 이 10ms 증가한다 고 가정 하면 10 만 번 의 통신 이 1000 s 가 더 많아 진다.여 기 는 요청 한 RT 만 보 내 고 TCP 는 메 시 지 를 보 낼 때마다 데이터 의 신뢰성 을 확보 하기 위해 피드백 ACK 를 요구 합 니 다.client 는 100 줄(요청 줄 수 설정 가능)을 가 져 올 때마다 여러 번 통신 을 하고 지연 증가 로 인 한 효율 문 제 를 확대 합 니 다.또한 커서 조회 에서 Mysql 은 조회 의 종료 시간 을 예측 할 수 없습니다.자신의 DML 작업 에 대응 하기 위해 추출 할 데 이 터 를 로 컬 에 임시 공간 으로 저장 합 니 다.따라서 커서 조회 시 다음 과 같은 몇 가지 현상 이 발생 한다.
a.IOPS 가 급증 하고 Mysql 은 데 이 터 를 임시 공간 에 기록 하 며 데이터 전송 시 임시 공간 에서 데 이 터 를 읽 습 니 다.이것 은 대량의 IO 작업 을 야기 합 니 다.
b.디스크 공간 이 급증 하고 임시 공간 수명 주 기 는 전체 JDBC 읽 기 단계 에 존재 하 며 클 라 이언 트 가 Result.close()를 시작 할 때 까지 Mysql 에 의 해 회 수 됩 니 다.
c.CPU 와 메모리 가 일정한 비율 로 상승 합 니 다.
커서 조회 의 원 리 는 블 로그 MySQL JDBC StreamResult 통신 원리 에 대한 분석 과 JDBC 소스 코드 를 참고 할 수 있 으 며 본 고 는 군말 하지 않 습 니 다.
JDBC API docs 참조,커서 모드 자바 데모 코드 는 다음 과 같 습 니 다.

1.2.3 방식 3:스 트림 읽 기 데이터
방식 1 은 JVM 메모리 넘 침 을 초래 할 수 있 습 니 다.방식 2 는 FULL GC 는 아니 지만 통신 효율 이 낮 고 Mysql 서버 IOPS 가 급증 하여 디스크 공간 을 소모 하 는 등 문제 가 발생 할 수 있 습 니 다.따라서 스 트림 에서 데 이 터 를 읽 는 것 을 소개 합 니 다.스 트림 은 Result 를 읽 기 전에 설정 해 야 합 니 다.

방식 3 통신 전에 어떠한 Server-Cient 의 상호작용 도 하지 않 고 통신 효율 이 떨 어 지지 않도록 한다.서버 에 데 이 터 를 기록 할 Kennel Buffer 를 준비 합 니 다.이 데 이 터 는 TCP 링크 를 통 해 Client 의 Kennel Buffer 에 전 송 됩 니 다.이 어 client 엔 드 input Stream.read()방법 이 깨 어 나 데 이 터 를 읽 습 니 다.방식 1 과 달리 client 는 매번 하나의 package 큰 데이터 만 읽 습 니 다.패키지 가 한 줄 에 만족 하지 않 으 면 하나의 package 를 다시 읽 습 니 다.client 가 데 이 터 를 소비 하 는 속도 가 데이터 전송 속도 에 미 치지 못 할 때 client 엔 드 kennel 구역 의 데이터 가 가득 쌓 이 고 서버 엔 드 의 kennel 데이터 도 가득 쌓 여 OuputStream 을 막 습 니 다.이렇게 해서 JDBC 는 Stream 모드 에서 하나의 수도관 처럼 두 개의 저수 지 를 연결 하고 Client 와 Server 는 하나의 균형 을 이룬다.
JDBC 클 라 이언 트 에 대해 매번 kennel 에서 데 이 터 를 읽 기 때문에 효율 이 방식 2 보다 훨씬 높 고 일부분 의 데 이 터 를 읽 을 때마다 JVM 메모리 가 넘 치지 않 습 니 다.서버 에 대해 Mysql 은 매번 kennel 에 데 이 터 를 씁 니 다.임시 공간 을 만 들 필요 가 없고 IO 읽 기와 관련 되 지 않 으 며 서버 의 압력 도 작 아 집 니 다.물론 방식 3 에 도 문제 가 있다.예 를 들 어 Stream 흐름 식 일 때 cancel 이 불가능 하고 cancel 이 막 히 지 않 는 다 는 등 이다.
JDBC API docs 를 참고 하여 인터넷 의 많은 튜 토리 얼 은 useCursorFetch=true ResultSet.FETCH 를 설정 해 야 합 니 다.REVERSE 등,사실 소 편 은 JDBC 구동 소스 코드 를 연구 한 결과 fetch Size=Integer.MIN 만 설치 하면 된다 는 것 을 알 게 되 었 다.VALUE,기타 설정 은 기본 설정 과 일치 하면 됩 니 다.커서 모드 자바 데모 코드 는 다음 과 같 습 니 다.

1.3 클 라 우 드 데이터 이전 서비스 가 세 가지 모델 에서 의 개선
클 라 우 드 데이터 이전 서비스(Cloud Data Migration,CDM)는 화 웨 이 클 라 우 드 의 이전 도구 로 CDM 홈 페이지 를 참조 하고 작은 편집 자 는 CDM 을 통 해 세 가지 모델 로 데 이 터 를 추출 하 는 방법 을 소개 한다.CDM 은 기본적으로 방식 3,스 트림 추출 데 이 터 를 사용 합 니 다.전환 방식 1,방식 2 는 추가 설정 이 필요 합 니 다.
1.3.1 설정 방식 1:기본 읽 기
새 Mysql 연결 기 를 만 듭 니 다.만 드 는 방법 은 홈 페이지 를 참조 하고 고급 속성 에 useCursorFetch=false 와 adopt.stream=false 를 추가 합 니 다.

1.3.2 설정 방식 2:커서 조회
Mysql 연결 기 를 편집 하고 고급 속성 에 useCursor Fetch=true 와 adopt.stream=false 를 추가 합 니 다.커서 조회 의 크기 는 화면 에 있 는 Fetch Size 를 통 해 조정 할 수 있 습 니 다.기본 값 은 1000 입 니 다.

1.3.3 설정 방식 3:흐름 식
CDM 기본 스 트림 입 니 다.추가 설정 이 필요 없습니다.Stream 모드 에서 인터페이스의Fetch Size는 작용 하지 않 습 니 다.원인 은 지난 절 을 참고 하 십시오.
1.3.4 성능 대비
새 Mysql2Hive 의 CDM 이전 작업,원본 표 101 필드,100 만 줄 데이터,설정 은 다음 과 같 습 니 다.


방식 1:100 만 줄 의 데 이 터 를 기록 하 는 데 걸 리 는 시간 1m22s

방식 2:똑 같이 100 만 줄 을 기록 하고 fetchSzie 를 각각 1,10,100,100 으로 조정 하 며 최소 2m1s 소모

방식 3:똑 같이 100 만 줄 을 기록 하고 1m5s 소모

소 편 은 또 100 만 개의 작은 시 계 를 테스트 했다.뚜렷 한 방식 1 과 방식 3 의 속 도 는 방식 2 보다 훨씬 높 았 다.또한 소 편 은 1000 만 개의 큰 시 계 를 테스트 했다.방식 1 은 메모리 폭발,방식 2 는 정상 적 으로 이전 하지만 20 분 이상 걸 렸 고 방식 3 은 15 분 안에 완 주 할 수 있다.
클 라 우 드 데이터 이전 서 비 스 를 통 해 MySQL 큰 표 추출 모델 의 원리 에 대한 분석 에 관 한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 관련 MySQL 큰 표 추출 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 지원 을 바 랍 니 다!