MyCat 구덩이 밟 기

대량의 데 이 터 를 읽 는 SQL 을 실행 하면 한동안 실행 하지 않 습 니까?
MyCat 의 기본 SQL 실행 시간 초과 시간 은 300 S (5 분) 입 니 다. MyCat 의 프로필 server. xml 설정 을 조정 해 야 합 니 다.
    
        
        1800      
    

ER 분할 서브 시트 의 경로 규칙
1. 하위 표 와 부모 표 의 관련 필드 가 부모 표 의 블록 필드 라면

 
        
  • 하위 테이블 을 업데이트 할 때 (메 인 키 에 따라) 모든 노드 에 sql 문 구 를 보 냅 니 다.
  • 글자 표 의 조각 규칙 은 아버지 표 에 따라 조각 을 나눈다
  • 자 표를 조회 할 때, 자 표 의 메 인 키 에 따라 찾 으 면 모든 노드 로 이동 합 니 다. (이때 자 표 가 모든 부분 에서 메 인 키 가 유일 하 다 는 것 을 보증 해 야 합 니 다)
  • 부모 노드 의 블록 필드 (joinKey) 에 따라 조회 하면 부모 표 의 경로 규칙 에 따라 조회 합 니 다.서표 와 부모 표 가 join 조 회 를 할 때 도 부모 표 의 길 을 걷는다.

  • 2. 하위 표 와 부모 표 의 관련 필드 가 부모 표 의 분할 필드 가 아 닐 때
    
             
    
            
  • 서브 시트 의 블록 규칙 은 부모 표 의 parentKey 가 있 는 블록 구역 에 따라 블록 을 나 누 는 것 이다.
  • 시트 에 update 문 구 를 사용 할 때 (홈 키 ID 나 parentKey 를 통 해) 모든 노드 에 sql 을 보 냅 니 다. 부모 노드 의 분할 정 보 를 확인 할 수 없 기 때 문 입 니 다.
  • 해당 하 는 부모 표 기록 을 찾 아 하위 표 가 있 는 부분 을 확인 해 야 합 니 다. 찾 지 못 하면 오류 가 발생 할 수 있 습 니 다. join 에서 조회 할 때 길 은 모든 부분 노드 로 갑 니 다.
  • 메 인 키 가 아 닌 블록, MyCAT 은 '메 인 키 에서 블록 까지' 메모리 캐 시 메커니즘 을 제공 하고 핫 이 슈 데 이 터 는 메 인 키 에 따라 조회 하 며 성능 을 조금도 손상 시 키 지 않 습 니 다.

  • MyCat 데이터 가 져 오기 및 내 보 내기
    내 보 내기
    분할 데 이 터 를 내 보 내 는 것 은 각 분할 노드 에 내 보 낸 다음 에 통합 하여 데이터 충돌 을 피 하 는 것 이 좋 습 니 다.
    도입
    대량의 블록 데이터 가 져 오기 select * from table into outfile 명령 을 사용 하여 백업 이 필요 한 mysql 데이터베이스 에서 데 이 터 를 내 보 낼 수 있 습 니 다.그리고 명령 행 도구 로 MyCat 에 연결 하고 'load data infile' 명령 을 실행 하여 조각 데 이 터 를 가 져 옵 니 다.
    다 중 관계
    업무 에 흔히 의 관련 관계 가 존재 한다. 예 를 들 어 + + 이때 분 편의 전략 은 업무 수요, 성능 차이 에 따라 결정 된다 (다 표 join).회원 의 모든 상점 의 주문 서 를 받 아야 하고 회원 표 에 의존 하 는 업무 관계 가 비교적 많 으 면 회원 표 로 나 누 는 것 을 고려 할 수 있다.반대로
    ER 분할 시트 update 작업
    ER 분 편, childTabe 를 업데이트 할 때 joinKey 를 업데이트 할 수 없습니다. 보고 합 니 다: Parent related column cant 't be update.....많은 프레임 워 크 업 데 이 트 는 기본 키 에 따라 모든 필드 를 업데이트 합 니 다. 이것 은 매우 구덩이 가 있 는 곳 이 라 고 할 수 있 습 니 다. sql 을 다시 써 야 합 니 다.
    비 메 인 키 블록 성능 최적화
    어떤 장면 에서 필름 을 나 눌 수 있 는 필드 는 메 인 키 가 아 닙 니 다.메 인 키 분할 도 유일한 선택 이 아니다.
  • 이 업무 필드 는 가장 빈번 하거나 가장 중요 한 조회 조건 이다.
  • 데 이 터 를 가능 한 한 고 르 게 분포 하 는 각 노드
    
           
    
          
  • 이 경우 MyCAT 은 '메 인 키 에서 필름 까지' 메모리 캐 시 메커니즘 을 제공 하 며, 핫 이 슈 데 이 터 는 메 인 키 로 조회 하 므 로 메 인 키 조회 의 성능 을 희생 할 염려 는 없다.
    홈 키 가 아 닌 table 에 속성 primaryKey 을 입력 합 니 다. 이때 MyCAT 은 홈 키 로 조회 한 SQL 문장의 첫 번 째 실행 결 과 를 분석 하여 이 Table 의 어떤 홈 키 가 어떤 블록 에 있 는 지 확인 하고 홈 키 에서 블록 ID 캐 시 까지 진행 합 니 다.두 번 째 또는 후속 조회 my cat 는 캐 시 에서 id – > node 즉 메 인 키 에서 필름 의 맵 까지 우선 조회 합 니 다. 직접 조회 가 있 으 면 이 방법 을 통 해 메 인 키 가 아 닌 필름 의 조회 성능 을 향상 시 킵 니 다.
    MyCat 작성 표 와 저장 과정
    MyCat 작성 표 는 주해 문법 을 사용 해 야 합 니 다. 예 를 들 어 select 1 from table 에서 찾 아 낸 데 이 터 는 그 노드 에서 어느 노드 로 실 행 됩 니까?
    저장 프로시저 생 성
    /*!mycat: sql = select 1 from 표 * / CREATE DEFINER = root @ % PROCEDURE proc_test () BEGIN END;
    건축 표
    /*!mycat: sql = select 1 표 * / create table ttt (id int);
    MyCat 성능 모니터링 도구 - MyCat - Web
    MyCat 이 공식 적 으로 제공 하 는 성능 모니터링 도 구 는 sql 에 대해 모니터링, 통계 조회, 실행 시간 감 측 을 할 수 있 습 니 다.모니터링 결과 에 따라 프로그램 이나 설정 을 일련의 조정 할 수 있다.
    여 기 를 누 르 면 MyCat - Web 을 다운로드 합 니 다. 사용 방법 은 압축 을 푼 readme. txt 를 보십시오.
    MyCat 빠 른 체험, MyCat 공식 적 으로 이미 미 러 를 만 들 었 습 니 다. 테스트 환경 을 통합 하여 Virtual Box 를 설치 하여 가 져 오 면 빠 른 체험 을 할 수 있 습 니 다.
    MyCat 분할 원칙 (MyCat 권위 지침 에서 전환)
  • 일정 수량 급 에 도달 해 야 분할 (800 만)
  • 800 만 이 안 되 지만 큰 표 (800 만 이 넘 는 표) 와 관련 된 조회 표 도 나 누 어야 한다. 여기 서 큰 표 관련 표
  • 라 고 한다.
  • 큰 표 관련 표 는 어떻게 뜯 습 니까? 100 만 이하 의 전체 표 사용;100 만 이상 이 800 만 이하 이 고 큰 표 와 같은 분할 전략 을 사용 합 니 다.큰 표 와 같은 규칙 을 사용 할 수 없 는 경우 자바 코드 에서 단계별 로 조회 하 는 것 을 고려 할 수 있 습 니 다. 관련 조 회 를 하지 않 거나 이례 적 으로 전체 표를 사용 할 수 있 습 니 다.
  • 이례 적 인 전체 표: 예 를 들 어 itemsku 표 250 만, 큰 표 와 관련 이 있 고 큰 표 와 같은 분할 전략 을 사용 할 수 없 으 며 전체 표 도 만 들 었 습 니 다.이례 적 인 전역 표 가 만족 해 야 할 조건: 다 중 스 레 드 와 같은 id = 1 의 기록 을 동시에 업데이트 하 는 등 치열 한 동시 업데이트 가 없습니다.다 중 스 레 드 update 가 있 지만 같은 줄 의 기록 을 조작 하 는 것 이 아 닙 니 다.다 중 스 레 드 update 전역 표 의 같은 줄 기록 은 잠 겨 있 습 니 다.대량 insert 괜 찮 습 니 다.
  • 분할 필드 는 수정 할 수 없습니다.
  • 분할 필드 는 하나의 필드 일 수 있 습 니 다. 두 필드 로 나 누 려 면 하나의 불필요 한 필드 를 새로 만들어 야 합 니 다. 불필요 한 필드 의 값 은 두 필드 의 값 으로 연결 되 어야 합 니 다 (예 를 들 어 큰 구역 + 년 월 에 zone yyymm 필드 로 조합).
  • 분할 알고리즘 의 선택 과 합 리 성 평가: 선택 한 알고리즘 에 따라 분할 한 후 각 라 이브 러 리 의 표 는 800 만
  • 을 초과 해 서 는 안 된다.
  • 안 뜯 을 수 있 는 건 최대한 안 뜯 어.만약 에 어떤 표 가 다른 표 와 관련 되 지 않 고 조회 하지 않 으 면 데이터 의 양 이 적 고 직접 분리 하지 않 고 단일 라 이브 러 리 를 사용 하면 된다.

  • 개발 프레임 워 크 선택
    마 이 캣 의 호환성 때문에 블록 버스터 필드 를 업데이트 할 수 없 는 등 제한 적 이다.Hibernate 프레임 워 크 개발 을 권장 하지 않 습 니 다. 가장 좋 은 선택 은 SQL 을 제어 할 수 있 는 프레임 워 크 입 니 다. 예 를 들 어 MyBatis, JDBC SQL 을 최적화 할 수 있 습 니 다.

    좋은 웹페이지 즐겨찾기