지식 확장: 데이터 왜곡을 해결하기 위한 자체 균형 테이블 분할 방법-MySQL 튜토리얼-php.cn

이 글은 데이터 테이블에 대한 관련 지식을 제공합니다. 주로 데이터 왜곡을 해결하기 위한 자체 균형 조정 방법을 공유합니다. 관심 있는 친구들이 이 글을 살펴보는 것이 모든 사람에게 도움이 되기를 바랍니다.

1. 배경

본 글에서는 비즈니스 데이터 볼륨 증가 및 기존 데이터 왜곡 문제를 해결하기 위한 B-side 토큰 시스템 응용 데이터 테이블을 주로 설명합니다.

1) B Token의 사업 배경

B Token의 사업 배경을 간략하게 설명하자면 B Token 시스템은 마케팅 시나리오에서 많은 사용자를 하나의 토큰으로 묶은 다음 토큰을 프로모션에 묶어 차별화를 이루는 데 사용됩니다. 일반적으로 토큰의 수명주기는 이 프로모션과 동일합니다.

2) B-side 토큰의 현재 구조

토큰과 토큰 사용자의 관계는 일대다 관계입니다. 초기 토큰 시스템은 jed 하위 라이브러리, 2개의 샤드를 사용했으며 확장이 수행되었습니다. 중간 샤드 8개 도달, 저장된 데이터 행 수 1억 2천만 개 도달

3) 데이터 및 비즈니스 현황

1억 2천만 개의 데이터, 각 하위 데이터베이스 8개에 분산 평균 수는 1,500만 명이나 하위 데이터베이스 필드가 토큰 ID(token_uuid)를 사용하기 때문에 일부 토큰 사용자는 몇 천~1만 명에 불과하고 일부는 100만~150만 명에 이르는 많은 토큰 사용자를 보유하고 있습니다. 총 토큰 수는 20,000개 정도로 많지 않아 데이터가 왜곡되어 있습니다. 일부 하위 데이터베이스에는 3천만 개가 넘는 데이터가 있고 일부는 수백만 개에 불과할 수 있습니다. 이로 인해 데이터베이스 읽기가 시작되었습니다. 성능이 저하되도록 작성합니다. 그리고 토큰 사용자 관계 테이블의 데이터 구조는 매우 단순하기 때문에 데이터 행이 많아도 공간을 많이 차지하지 않습니다. 8개 하위 라이브러리의 총 점유 공간은 20G 미만입니다. 동시에 토큰의 수명주기는 기본적으로 프로모션의 수명주기와 동일합니다. 토큰이 하나 이상의 프로모션을 제공한 후에는 천천히 만료되어 폐기되며 앞으로도 계속해서 새로운 토큰이 생성됩니다. 따라서 만료된 토큰을 보관할 수 있습니다.

동시에 B-side 사업의 발전으로 인해 더 많은 사업 수요가 생겼습니다. 사업부와의 소통을 통해 향후 자동 선택 시스템이 출시될 것이라는 것을 알게 되었습니다. 프로모션에 적합한 사람을 선택합니다. 앞으로 매달 데이터가 약 3천만 개 증가합니다. 1년 동안 실행하면 단일 테이블의 평균 데이터 양이 6천만 개에 도달합니다. 현재의 디자인 아키텍처는 더 이상 비즈니스 요구 사항을 충족할 수 없습니다.

동시에 토큰 ID를 기반으로 페이지에서 토큰 아래의 사용자를 조회하는 기능도 있지만 관리측 작업에만 사용되며 자주 사용되지는 않습니다.

2. 솔루션에 대한 생각

1) 이 문제를 해결하는 방법

데이터베이스 읽기 및 쓰기 성능 저하와 비즈니스 성장 요구에 직면하여 현재 다음과 같은 문제에 직면해 있습니다.

단일 테이블에 너무 많은 데이터 행이 있는 문제를 해결하는 방법
현재 하위 데이터베이스 솔루션에는 심각한 데이터 왜곡이 있습니다
향후 데이터 증가에 대처한다면

2) 기술 솔루션

a. 데이터베이스 샤딩

일반적으로 첫 번째 문제를 해결하려면 일반적으로 데이터베이스와 샤딩 테이블을 샤딩해야 하지만 이제 8개의 하위 데이터베이스가 8개 미만의 공간만 차지합니다. 20G 공간은 단일 데이터베이스에 리소스 낭비가 심각하므로 계속해서 하위 데이터베이스를 추가하는 것을 전혀 고려하지 않을 것이므로 하위 테이블이 해결책입니다.

데이터를 테이블로 나누는 방법에는 일반적으로 세로 테이블과 가로 테이블의 두 가지 방법이 있습니다.

수직 테이블 분할이란 데이터의 열을 분할한 후 기본 키나 기타 비즈니스 필드를 적용하여 연관시키는 것을 말하며, 이를 통해 단일 테이블 데이터가 차지하는 공간을 줄이거나 중복 저장 공간을 줄이는 B 토큰 시나리오 데이터 구조입니다. 간단하고 데이터가 작은 공간을 차지하므로 이 테이블 분할 방법은 사용되지 않습니다.

수평 테이블 샤딩은 라우팅 알고리즘을 사용하여 데이터 행을 여러 테이블로 분할하는 것을 의미합니다. 이 테이블 샤딩 전략은 일반적으로 구조가 다음과 같은 데이터 시나리오를 처리하는 데 사용됩니다. 복잡하지는 않지만 데이터 행이 많습니다. 이것이 우리가 사용할 것입니다. 이 방법을 사용할 때 고려해야 할 것은 라우팅 알고리즘을 어떻게 설계하느냐 하는 점이다. 여기서도 이 방법은 테이블을 분할하는데 사용된다.

b. 라우팅 알고리즘

업계에서 데이터 테이블 라우팅 알고리즘을 사용하는 방법은 다양합니다. 하나는 일관성 해시를 사용하여 적절한 테이블 샤딩 필드를 선택하고 필드 값을 해싱한 후의 값이 고정되는 것입니다. 이 값을 사용하여 모듈로 또는 비트별 연산을 통해 고정된 시퀀스 번호를 얻어 데이터가 저장되는 테이블을 결정합니다.

하위 데이터베이스와 같은 가장 일반적인 응용 프로그램은 일관성 있는 해싱을 사용합니다. 하위 데이터베이스 필드의 값을 즉시 계산하여 데이터가 어느 하위 데이터베이스에 속하는지 판단한 후 데이터를 저장할 하위 데이터베이스를 결정합니다. 데이터를 읽거나 읽습니다. 쿼리 시 하위 데이터베이스 필드를 지정하지 않은 경우에는 모든 하위 데이터베이스에 동시에 쿼리 요청을 보내고 최종적으로 결과를 요약해야 합니다.

또한 Java 코드와 같은 HashMap 데이터 구조는 실제로 일관된 해시 알고리즘의 테이블 분할 전략입니다. 키를 해싱하여 데이터가 배열에 저장될 일련 번호를 결정합니다. HashMap은 모듈로를 사용하지 않습니다. 하지만 이 방법은 HashMap의 크기가 2의 x제곱에 기반함을 결정합니다. 이 원칙은 나중에 기회가 있을 때 소개하겠습니다.

위는 HashMap의 단순화된 데이터 해시 저장 프로세스입니다. 물론 일부 세부 사항을 생략했습니다. 예를 들어 HashMap의 각 노드는 연결된 목록입니다(충돌이 너무 많으면 레드-블랙 트리로 전환됩니다). . 우리 시나리오에 적용하면 각 일련번호는 데이터 테이블로 간주될 수 있습니다.

위 라우팅 알고리즘의 장점은 라우팅 전략이 간단하고 실시간 계산을 위해 추가 저장 공간을 추가할 필요가 없다는 것입니다. 그러나 용량을 확장하려는 경우에는 문제가 있습니다. 마이그레이션을 위해 기록 데이터를 다시 해시해야 합니다. 예를 들어 데이터베이스 하위 데이터베이스가 추가된 경우 라이브러리는 모든 데이터를 별도의 라이브러리로 다시 계산해야 하며 배열에 있는 키의 시퀀스 번호를 다시 계산하기 위해 다시 해시를 수행해야 합니다. . 데이터의 양이 너무 많으면 이 계산 과정에 오랜 시간이 걸립니다. 동시에 데이터 테이블이 너무 적거나 샤딩을 위해 선택한 필드의 이산성이 낮은 경우 데이터 왜곡이 발생합니다.

이 재해시 프로세스를 최적화하는 테이블 분할 알고리즘도 있습니다. 이것이 일관성 있는 해시 링입니다. 이 방법은 엔터티 노드 사이의 많은 가상 노드를 추상화한 다음 일관성 있는 해시 알고리즘을 사용하여 이러한 가상을 적중합니다. 각 엔터티 노드는 실제로 엔터티 노드의 반시계 방향으로 다른 엔터티 노드에 인접한 가상 노드의 데이터를 담당합니다. 이 방법의 장점은 용량을 확장하고 노드를 추가해야 하는 경우 추가된 노드가 링의 아무 곳에나 배치되며 노드의 시계 방향으로 인접한 노드의 데이터에만 영향을 미친다는 것입니다. 노드의 데이터를 이 새 노드에 설치하기 위해 마이그레이션해야 하므로 재해시 프로세스가 크게 줄어듭니다. 동시에, 가상 노드 수가 많기 때문에 물리적 노드를 적절한 위치에 배치하면 데이터 왜곡 문제를 최대한 해결할 수 있습니다. .

예를 들어 그림은 일관된 해시 링의 해시 프로세스를 보여줍니다. 전체 링에는 0부터 2^32-1까지의 노드가 있으며, 나머지는 가상 노드입니다. Zhang San 해싱 후 링 위의 가상 노드에 떨어지며, 가상 노드의 위치에서 시계 방향으로 실제 노드를 검색하여 최종 데이터가 실제 노드에 저장되므로 Crazy Donkey와 Li Si가 저장됩니다. 노드 2에 있고 Wang Wu는 노드 3에 있습니다. Zheng Liu는 노드 4에 있습니다.

5번 노드를 확장한 후 1번 노드와 5번 노드 사이의 데이터를 5번 노드로 마이그레이션해야 하며, 다른 노드의 데이터는 변경할 필요가 없습니다. 하지만 그림에서 볼 수 있듯이 이 노드 하나만 추가하면 각 노드를 담당하는 데이터가 고르지 않게 될 수 있습니다. 예를 들어 노드 2와 노드 5는 다른 노드보다 훨씬 적은 데이터를 담당하므로 확장하는 것이 가장 좋습니다. 데이터가 계속 균일하게 유지될 수 있도록 용량을 기하급수적으로 확장하는 것이 가장 좋습니다.

3) 내 계획을 생각해 보세요

B 토큰의 비즈니스 시나리오로 돌아가서 다음 요구 사항을 충족할 수 있어야 합니다

우선 문제를 해결하려면 수평 하위 테이블을 사용해야 합니다.
토큰 기반의 사용자 페이징 쿼리 지원 필요
현재 비즈니스 데이터 증가량은 3천만개이므로 향후 지속적인 비즈니스 성장 가능성도 배제할 수 없습니다. , 하위 테이블 수가 향후 확장을 지원할 수 있어야 합니다
데이터 행 수가 너무 많습니다. 확장 시 데이터 마이그레이션이 필요하지 않거나 데이터 마이그레이션 비용이 낮은지 확인해야 합니다. future
단일 테이블의 과도한 데이터 볼륨으로 인해 전체 성능이 저하되지 않도록 데이터 왜곡 문제를 해결해야 합니다.

위의 호소를 바탕으로 우선 질문 b를 살펴보세요. 토큰을 기반으로 사용자의 페이징 쿼리를 지원하려면 단순히 페이징 쿼리를 지원하기 위해 토큰 아래의 모든 사용자가 동일한 테이블에 있는지 확인해야 합니다. 그렇지 않으면 일부 요약 및 병합 알고리즘을 사용하는 것이 너무 복잡해집니다. 테이블은 쿼리 성능을 저하시킵니다. 이기종 데이터를 이용하여 쿼리 기능을 제공할 수도 있지만, 소수의 관리 측 쿼리 요청에 대해서만 데이터 이종성을 수행하는 것은 비용이 다소 높지만 이점이 명확하지 않으며 낭비이기도 합니다. 자원의. 따라서 하위 테이블 필드는 토큰 ID를 통해서만 확인할 수 있습니다.

위에서 언급한 것처럼 토큰 ID의 수는 많지 않으며, 토큰에 속한 사용자 수는 10,000~100만 명에 이릅니다. 단순히 일관된 해싱을 사용하고 토큰 ID를 샤딩 전략으로 사용하면 데이터 왜곡이 심각해집니다. 향후 확장 중에는 데이터 마이그레이션 비용이 매우 높을 것입니다.

그러나 일관된 해시 링을 사용하면 향후 2의 배수로 최상의 확장이 가능합니다. 그렇지 않으면 일부 노드는 더 많은 가상 노드를 담당하고 일부 노드는 더 적은 수의 가상 노드를 담당하게 되어 불균형이 발생합니다. 데이터. 그러나 데이터베이스 동료와 통신할 때 하나의 데이터베이스에 있는 데이터 테이블 수가 너무 많으면 안 됩니다. 그렇지 않으면 데이터베이스에 큰 부담을 줄 수 있습니다. 일관된 해시 링 방식은 용량을 2~3배 확장할 수 있으며, 이로 인해 1에 도달하는 하위 테이블 수가 매우 높습니다.

위 문제를 바탕으로 토큰 ID를 하위 테이블로 사용하기로 결정한 후 동적 확장을 지원하고 데이터 왜곡 문제를 해결하는 방법에 집중해야 합니다.

3. 계획의 구현

1) 계획의 개요

a. 동적 확장 지원 방법

하위 테이블의 필드는 토큰 ID를 사용하도록 결정되었으며, 앞서 언급했듯이 데이터 구조는 카드이고 사용자는 일대다 관계형 데이터이므로 토큰 생성 시 해시된 하위 테이블 일련번호가 저장되고 이후 라우팅은 저장된 하위 테이블 일련번호를 기반으로 이루어집니다. 향후 확장이 기존 데이터의 라우팅에 영향을 미치지 않도록 하십시오. 데이터 마이그레이션이 필요하지 않습니다.

b. 데이터 스큐 해결 방법

토큰 ID를 하위 테이블 필드로 선택하고 각 토큰의 데이터 크기가 다르기 때문에 데이터 스큐가 큰 문제가 됩니다. 그래서 여기서 우리는 서브미터 수위의 개념을 소개하려고 합니다.

사용자가 관련 사용자 수 저장 또는 삭제를 요청하는 경우, 특정 샤드의 데이터 양이 많을 때 샤드 테이블 일련번호를 기준으로 현재 샤드 테이블 수의 증가 또는 감소 카운트가 수행됩니다. 테이블이 높은 수준에 있으면 관련 사용자 수가 계산되므로 샤딩된 테이블은 샤딩 알고리즘에서 제거되므로 샤딩된 테이블은 계속해서 새로운 데이터를 생성하지 않습니다.

예를 들어 1,000만이라는 임계치를 최고 수위로 설정했을 때, 위 5개의 테이블 중 어느 테이블도 최고 수위에 도달하지 않았기 때문에 토큰을 생성할 때 토큰 ID에 따라 해시한 다음 모듈로 3을 얻고 테이블을 순서대로 얻으면 현재 토큰의 하위 테이블 번호는 b2b_token_user_3입니다. 후속 관계형 데이터는 이 테이블에서 얻어집니다.

일정 기간 동안 실행한 후 테이블 b2b_token_user_1의 데이터 볼륨이 1,200만 개로 증가하여 수위 1,000만 개를 초과했습니다. 이때 토큰 생성 시 테이블이 제거되며, 모듈로는 Hash 이후에 1이 됩니다. 그러면 현재 할당된 테이블은 b2b_token_user_2입니다. 그리고 b2b_token_user_1의 수위를 낮출 수 없는 경우 해당 테이블은 향후 더 이상 하위 테이블에 참여하지 않으며, 테이블의 데이터 양도 증가하지 않습니다.

물론 모든 시계가 만조 수위에 진입했을 가능성은 있습니다. 이때 안전을 위해 수위 기능이 비활성화되고 모든 시계가 하위 테이블에 추가됩니다.

c. 하위 테이블의 수위를 줄이기 위한 정기적인 데이터 보관

테이블의 데이터 양이 감소하지 않고 계속 증가할 경우 조만간 모든 테이블이 최고 수위에 도달하게 됩니다. 이는 동적 효과를 달성하지 못할 것입니다. 위의 배경에서 언급한 바와 같이, 토큰은 특정 프로모션을 제공하기 위해 생성됩니다. 프로모션이 종료되면 토큰은 유효 기간을 가지게 되며 해당 토큰은 만료일을 초과하게 됩니다. 유효기간도 효력을 잃게 됩니다. 따라서 데이터를 정기적으로 보관하면 수위가 높은 테이블이 천천히 수위를 낮추고 하위 테이블에 다시 합류할 수 있습니다.

그리고 현재 토큰은 1억 2천만 개의 데이터가 포함된 b2b_token_user 테이블에 이미 존재합니다. 이 테이블을 다이어그램의 테이블 0으로 사용할 수 있으므로 처음 온라인에 접속할 때 모든 기록만 나누면 됩니다. 토큰은 테이블 일련번호를 0으로 기록하기만 하면 기존 데이터를 마이그레이션할 필요가 없습니다. 이 테이블의 데이터 양이 많으면 하위 테이블에 참여하지 않습니다. 정기적인 데이터 보관과 함께 테이블의 수위는 천천히 내려갑니다.

d. 모니터링 메커니즘

정기적으로 데이터를 보관하면 테이블의 수위가 낮아질 수 있지만 비즈니스가 발전함에 따라 대부분의 테이블이 높은 수위에 들어갈 수 있으며 모두 유효한 데이터를 가지고 있습니다. 이때 시스템은 용량이 75%에 도달했다고 판단하면 자동으로 테이블을 생성할 수 없지만, 테이블의 75%가 만조에 진입하면 개발자가 모니터링하게 됩니다. 경보를 울리고 수동으로 개입해야 합니다. 수위가 높으면 테이블을 확장해야 합니다.

3) 단점

• 수위 한계치 및 팽창 모니터링

현재 수위 임계값은 여전히 수동으로 설정됩니다. 얼마나 크게 설정해야 하는지는 상당히 감정적입니다. 알람 후에는 하나만 설정하고 적절하게 조정할 수 있습니다. 그러나 실제로 시스템은 인터페이스의 읽기 및 쓰기 성능 변동을 자동으로 모니터링할 수 있습니다. 대부분의 표현이 높은 수준에 도달하면 시스템의 읽기 및 쓰기 성능이 크게 변하지 않는 것으로 나타났습니다. 자동으로 임계값을 높여 스마트 임계값을 형성합니다.

인터페이스 성능 읽기 및 쓰기에 큰 변화가 있고 대부분의 테이블이 임계값에 도달한 것으로 확인되면 용량 확장을 고려해야 함을 나타내는 경보가 발생할 수 있습니다.