스키마의 역할은 이전에 소개한 적이 있습니다. 이번 글에서는 규칙과 서버를 함께 소개하겠습니다~
1 샤딩의 규칙에 대해서는 이번에는 상대적으로 높은 비율의 몇 가지 메소드만 추출합니다. 먼저 구성 파일의 내용을 살펴보겠습니다.
스크린샷의 상단에는 규칙에 대한 정의가 설명되어 있으며, 하단에는 해당 규칙에 해당하는 실제 분할 규칙이 나와 있습니다. 수석 엔지니어가 소개하는 네 가지 분할 방법~중얼거림은 속았다~
- ------------ ------------ ------------ ---------------해시 정수--------- ------------ ------------ ------------ -
먼저 hash-int를 살펴보겠습니다. 이 분할 규칙에는 mapfile이 있는데, 이는 partition-hash-int의 내용에 따라 분할 규칙이 결정된다는 의미입니다. 이 텍스트 파일을 보세요
매우 간단한 내용입니다. 즉, 분할에 사용되는 기본 열에서 값이 10000이면 첫 번째 DN(dn1)에 배치되고 값이 10010이면 두 번째 DN(dn2)에 배치됩니다.
실제 효과를 확인하실 수 있습니다
테이크 MyCAT 디버그 로그를 보면 이 두 문은 dn1과 dn2에 할당되고 해당 데이터도 데이터베이스에 삽입됩니다.
(굴착기가 거칠게 굴러갑니다~) 기준열의 값이 삽입된 데이터에 이 파일에 명시된 값이 없으면 어떤 영향을 미치나요? 
대략적으로
열거 파티션 
으로 이해하면 됩니다. 성별(0,1)과 같이 값이 고정되어 있는 상황 ), 지방(고정값, 단기적으로는 불가능) 일본 지방을 되찾자~), 채널딜러
또는 다양한 플랫폼의 ID
그리고 쉼표 구분으로 여러 값을 하나의 파티션에 배치할 수 있어 실제 데이터/트래픽/접속량에 따라 종합적으로 세분화 전략을 세울 수 있습니다╮(╯_ ╰)╭
--------- -------- ----------------------------- -------- ----------장거리------------------ ------- ----------------- --- 두 번째 분할 방법인 range-long은 자세히 보면 hash-int와 비슷합니다. 분할 전략도 특정 파일에 따라 결정되므로 파일 내용을 살펴보는 것이 좋습니다. > 파일 내용을 보면 범위를 나누어 벤치마크 컬럼의 범위를 공식화한 후 이 범위의 모든 데이터를 하나의 DN에 넣는 방식임을 알 수 있는데, 이 방식은 기본적으로 hash-int와 동일하므로 스크린샷을 찍지 않겠습니다(게으름의 후반, 시간이 부족합니다!) 이 세분화 전략은 개인적으로 이러한 세분화로 인해 비즈니스 데이터베이스에서 사용 시나리오가 줄어들 것이라고 생각합니다. 그 방식은 전체 숫자를 예약해야 하는데, 이는 무한히 증가한 데이터를 사용할 수 없다고 판단하므로 결국 X 조각을 수정하는 비즈니스와 같이 특정 숫자에 따라 균등하게 나누는 것이 번거롭습니다. 하루에 많은 데이터(온도 수집? 데이터 수집? 등)를 수집한 다음 미리 여러 개의 DN(라이브러리)을 구축합니다. 물론 잠재적인 문제도 있습니다.
단시간에 대량의 삽입 작업이 발생하면
1000W 데이터를 저장하도록 DN이 설정되어 있습니다
), 그러면 이때 특정 DN(하위 데이터베이스)의 IO 압력이 매우 높을 것이고, 다른 여러 DN(하위 데이터베이스)에는 IO 작업이 전혀 없을 것입니다.
DB의 일반적인 핫 블록/핫 디스크 현상과 MySQL은 자동 증가 기본 키를 사용하는 경우가 많으므로 MySQL 테이블에 대량의 "순차적" 삽입 기회가 더 많아질 것입니다 . ------------------------------- ------ ------------------ -mod- 긴 -------------------- ------------------ -------------------------------- -- mod-long, mod 관점에서는 나머지 부분을 취하는 방식입니다. 데이터를 균등하게 분산시키는 방법입니다. 4개의 DN(물론
남은 숫자를 취하는 이 방법을 사용하면 이 4개의 데이터가 4개의 DN(라이브러리)에 삽입되고, 시퀀스가 삽입되면 데이터가 DN(라이브러리)에 고르게 분산되는 것을 볼 수 있습니다. 위의 여러 DN(라이브러리)위의 범위 방법과 비교하면 이 분할 전략은 데이터베이스 쓰기 부담을 더 잘 분산시키겠지만 문제도 분명합니다. 일단 범위 쿼리가 발생하면 MyCAT을 병합해야 합니다. 결과 , 데이터 양이 많을 때 이런 종류의 데이터베이스 간 쿼리 + 병합 결과에 소요되는 시간이 많이 늘어날 수 있으며, 특히 주문이 발생할 때 더욱 그렇습니다.
에 의해.
따라서 이러한 종류의 분할 전략은 단일 포인트 쿼리 장면 에 더 적합할 것입니다. 예를 들어 ... 모르겠어요 ... 정말 모르겠습니다. 아마도 은행, 개인 계좌 정보 조회 시 사용자 정보가 포함된 일부 테이블이 중복될 수 있는데, 이 방법을 이용하면 보다 효율적인 조회가 가능합니다. (결국 은행은 사용자가 많으니까요~)
----------------------------- ------------------파티션별- ----- ------------------- ----- -------------
~ Â Â Â 범위 내에 있었음 -long과 mod - -long 사이의 약간 절충된 파티셔닝 전략 구체적인 파티셔닝 상황은 다음과 같습니다. 1024를 단위로 하여 각 DN은 partitionLength 양의 데이터를 저장하며 partitionCount x partitionLength =1024입니다.
좀 이해하기 어려울 것 같은데,
partitionCount(4) x partitionLength(256)이 DN1,256-에 배치되어 있습니다. 511 DN2에 올려놓는 식으로 오프셋 값이 128인 8개의 데이터를 삽입해 보고, mycat의 로그를 직접 보면
8개의 데이터가 있음을 알 수 있다. 이 4개에 균등하게 분포됩니다. DN 내부~
이 분할 전략도 비균일 분포를 지원한다는 점은 언급할 가치가 있습니다~정말 헤아릴 수 없는 두 장의 도난 사진입니다~
> > 이 분할 전략은 
range-long과 mod-long은 상대적으로 유연하며 상황에 따라 불균일한 분할에 사용할 수 있습니다. 실제로 적용할 수 있는 시나리오는 조금 더 많을 것입니다. 즉, 교차 DN 상황의 수를 상대적으로 줄이고 데이터를 균등하게 분할하는 많은 시나리오에서 사용할 수 있으며 단일 지점 쿼리가 너무 느리지 않습니다. 
---------------------------- ------------------------------------- ----마지막에 작성해주세요---------------------------- ------- ----------------
실제로 MyCAT에서는 다양한 분할 방법을 지원합니다. 예를 들어 시간을 기준으로 한 분할 전략은 월, 일 등으로 분할할 수 있습니다. 포함할 방법이 없습니다. 전략은 여기에 다 올렸네요 죄송합니다 o(￣ヘ￣o#)
사실 개인적인 관점에서는 데이터베이스 자체의 파티셔닝 전략에 따라 시간을 나누는 데에는 문제가 없습니다. 반기별, 분기별 데이터는 여전히 동일합니다. 쿼리를 하셔야 합니다...PS: _(:з ∠)_정말 게으르지 않습니다... MyCAT 서브의 핵심은 다음과 같습니다. -이 규칙에는 기본적으로 데이터베이스와 테이블이 반영되어야 합니다. 테이블 데이터를 분할하는 방법은 실제 업무에 따라 가장 적절한 분할 전략이 결정되어야 합니다. 장사~
위 내용은 MySQL 분산 클러스터의 MyCAT(3) 규칙에 대한 상세 분석(그림 및 텍스트)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
