수백억 개의 데이터를 테이블로 나눈 후 페이징 쿼리 이해

mysql 비디오 튜토리얼 컬럼에서는 수백억 개의 데이터에 대한 페이징 쿼리를 소개합니다.

예를 들어 비즈니스 규모가 특정 규모에 도달하면 Taobao의 일일 주문량은 5천만 건이 넘고 Meituan의 일일 주문량은 3천만 건이 넘습니다. 데이터베이스가 막대한 데이터 압력에 직면한 경우 하위 데이터베이스 및 테이블 하위 작업이 필요합니다. 데이터베이스가 테이블로 분할된 후 일부 일반 쿼리로 인해 문제가 발생할 수 있습니다. 가장 일반적인 쿼리는 페이징 쿼리입니다. 일반적으로 샤딩 테이블의 필드를 샤딩 키라고 부릅니다. 예를 들어 주문 테이블은 사용자 ID를 샤딩 키로 사용합니다. 그러면 쿼리 조건에 사용자 ID가 포함되지 않은 경우 어떻게 페이징을 수행합니까? 예를 들어, 분할 키가 없으면 어떻게 더 많은 다차원 쿼리를 쿼리할 수 있습니까?

고유한 기본 키

일반적으로 우리 데이터베이스의 기본 키는 자동으로 증가하므로 테이블 분할 후 기본 키 충돌 문제는 피할 수 없는 문제입니다. 가장 간단한 방법은 고유한 비즈니스 필드를 유일한 기본 키로 사용하는 것입니다. 키(예: order) 테이블의 주문 번호는 전역적으로 고유해야 합니다.

고유 ID를 생성하는 일반적인 분산 방법은 여러 가지가 있으며, 가장 일반적인 방법은 Snowflake 알고리즘, Didi Tinyid 및 Meituan Leaf입니다. 눈송이 알고리즘을 예로 들면 1밀리초에 4194304여러 ID가 생성될 수 있습니다.

첫 번째 비트 는 사용되지 않으며 기본값은 0입니다. 41자리 타임스탬프 밀리초 단위로 정확하고 69년을 수용할 수 있으며 10자리 작업 기계 ID 상위 5자리는 데이터 센터 ID, 하위 5자리는 노드 ID, 12자리 일련번호입니다. 각 노드는 밀리초마다 누적되며 총합은 2^12 4096개의 ID에 도달할 수 있습니다.

테이블 분할

첫 번째 단계는 테이블 분할 후 주문 번호가 고유한지 확인하는 것입니다. 이제 테이블 분할 문제를 고려해보세요. 먼저, 자체 비즈니스 볼륨 및 증분을 기반으로 하위 테이블의 크기를 고려하십시오.

예를 들어 현재 당사의 일일 주문량은 100,000건이며, 1년 안에 일일 주문 건수 100만건에 도달할 것으로 예상됩니다. 비즈니스 특성에 따라 일반적으로 반년 이내에 주문 조회를 지원하고, 이를 초과하는 주문은 지원하지 않습니다. 반년 동안 보관해야 합니다.

그래서 반년 동안 하루 100만개 주문을 기준으로 별도의 테이블 없이 주문량이 100만개에 도달하게 됩니다. RT를 운반하는 데 걸리는 시간을 도저히 용납할 수 없습니다. 경험에 따르면 단일 테이블의 수가 수백만 개이면 데이터베이스에 부담이 없으므로 256개의 테이블로 나누어 1억 8천만/256 ≒ 700,000개이면 충분합니다. 512개의 테이블로 나눌 수도 있습니다. 그렇다면 생각해 보세요. 비즈니스 볼륨이 하루 1천만 주문으로 10배 더 증가하면 하위 테이블 1024가 더 적합한 선택입니다.

테이블을 분할하고 반년 넘게 데이터를 보관하면 단일 테이블에 700,000개의 데이터가 있으면 대부분의 시나리오를 처리하기에 충분합니다. 다음으로 주문 번호를 해시한 다음 256의 모듈로를 취하여 해당 주문이 어떤 테이블에 속하는지 확인합니다.

글쎄, 유일한 기본 키는 주문 번호를 기반으로 하기 때문에 이전에 기본 키 ID를 기반으로 작성한 쿼리는 사용할 수 없습니다. 여기에는 일부 기록 쿼리 기능이 수정됩니다. 그런데 이건 문제가 되지 않죠? 그냥 주문번호로 확인하도록 바꿔주시면 되겠죠? 이 중 어느 것도 문제가 되지 않습니다. 문제는 제목에서 말하는 것입니다.

C 측 쿼리

오랜 시간 동안 이야기를 나눈 끝에 마침내 본론에 도달했습니다. 그러면 테이블 파티셔닝 후 쿼리 및 페이징 쿼리 문제를 어떻게 해결할 수 있을까요?

먼저 샤딩키를 이용한 쿼리에 대해 이야기해보겠습니다. 예를 들어, 페이징으로 무엇을 하든 특정 테이블을 직접 찾아 쿼리하면 문제가 없을 것입니다. 질문.

샤딩키가 아닌 경우, 위 예시에서 주문번호를 샤딩키로 사용한다면 일반적으로 앱이나 소형 프로그램은 사용자 아이디를 통해 조회하게 되는데, 주문번호를 통해 이루어진 샤딩은 어떻게 해야 할까요? ? 많은 회사의 주문 테이블은 사용자 ID를 샤딩 키로 직접 사용하는데, 이는 매우 간단하고 직접 확인할 수 있습니다. 그렇다면 주문 번호로 무엇을 해야 할까요? 아주 간단한 방법은 주문 번호에 사용자 ID 속성을 추가하는 것입니다. 아주 간단한 예를 들자면, 원래의 41자리 타임스탬프를 다 쓸 수 없다고 생각합니다. 사용자 ID는 10자리입니다. 주문 번호 생성 규칙에는 특정 테이블에 입력할 때 사용자 ID가 10자리입니다. 주문번호의 ID 해시를 사용하며, 주문번호나 사용자 ID에 상관없이 쿼리 효과가 동일하도록 모듈러스를 취합니다.

물론, 이 방법은 단지 예시일 뿐입니다. 구체적인 주문 번호 생성 규칙, 몇 자릿수, 포함되는 요소는 귀하의 비즈니스 및 구현 메커니즘에 따라 결정됩니다.

그렇다면 주문번호나 사용자 ID를 샤딩키로 사용하시거나 위의 두 가지 방법을 따르면 문제를 해결할 수 있습니다. 그렇다면 또 다른 질문이 있습니다. 주문 번호도 아니고 사용자 ID 쿼리도 아닌 경우에는 어떻게 되나요? 가장 직관적인 예는 판매자 측 또는 백엔드의 쿼리입니다. 판매자 측에서는 판매자 또는 판매자의 ID를 쿼리 조건으로 사용합니다. 백엔드의 쿼리 조건은 제가 만난 일부 백엔드 쿼리 조건처럼 더 복잡할 수 있습니다. 수십 개가 있을 수 있습니다. 어떻게 확인하나요? ? ? 걱정하지 마세요. B 측과 백엔드의 복잡한 쿼리에 대해 별도로 이야기해 보겠습니다.

실제로 실제 트래픽의 대부분은 사용자 측 C 측에서 발생하므로 본질적으로 사용자 측의 문제를 해결합니다. 이 문제는 대부분 해결되고 나머지 쿼리 트래픽은 판매자-판매자에서 발생합니다. B사이드와 백엔드 지원 운영 사업은 그리 크지 않을 것이며 이 문제는 쉽게 해결될 것입니다.

Other-side query

B-side에서 비샤딩키 쿼리를 해결하는 방법에는 두 가지가 있습니다.

이중 쓰기, 이중 쓰기는 주문 데이터가 C면에 하나, B면에 하나씩 두 개의 복사본에 저장된다는 의미입니다. C 면의 경우 주문 번호나 사용자 ID를 사용할 수 있습니다. B측은 가맹점 ID를 샤딩키로 사용하면 됩니다. 일부 반 친구들은 "두 번 쓰면 성능에 영향을 미치지 않습니까?"라고 말할 것입니다. B측에서는 약간의 지연이 허용되므로 비동기식 방법을 사용하여 B측 주문을 할 수 있습니다. 생각해 보세요. Taobao에 가서 물건을 사고 주문할 때 판매자가 주문 메시지 수신을 1~2초 지연해도 문제가 될까요? 주문한 테이크아웃 가맹점이 주문을 1~2초 늦게 받는 것이 큰 영향을 미치나요?

이것은 오프라인 데이터 웨어하우스 또는 ES쿼리를 사용하는 것입니다. binlog 또는 MQ 메시지를 사용하여 데이터를 데이터베이스에 동기화하거나 ES. 이 쿼리 조건에 대해 지원하는 크기 순서는 간단합니다. 이 방법에는 확실히 약간의 지연이 있지만 제어 가능한 지연은 허용됩니다.

데이터를 확인해야 하는 운영, 비즈니스, 제품 등 관리 백엔드에 대한 쿼리의 경우 당연히 복잡한 쿼리 조건이 필요하며 이는 ES 또는 데이터 웨어하우스를 통해서도 달성할 수 있습니다. 이 솔루션을 사용하지 않고 shardingkey 없이 페이징 쿼리를 수행하면 형제님, 전체 테이블을 스캔하여 집계된 데이터를 쿼리한 다음 수동으로 페이징을 수행할 수 있지만 이 방법으로 찾은 결과는 제한적입니다.

예를 들어 샤드가 256개인 경우 쿼리할 때 모든 샤드를 주기적으로 스캔하고 각 샤드에서 20개의 데이터를 가져온 다음 마지막으로 데이터를 집계하고 수동으로 페이징하면 전체 샤드를 찾는 것은 절대 불가능합니다. 데이터.

요약

하위 데이터베이스 및 테이블 분할 후의 쿼리 문제는 경험이 많은 학생들에게는 실제로 알려져 있지만 실제로 대부분의 학생들이 수행하는 비즈니스는 이 정도 규모에 도달하지 못할 수 있다고 생각합니다. 그리고 테이블 분할도 모두 개념적인 단계에 갇혀 있었고, 경험이 없어서 어떻게 해야할지 몰라 면접에서 물어봤을 때 당황스러웠습니다.

서브 데이터베이스와 테이블은 기존 사업 규모와 향후 증가분을 기준으로 먼저 판단됩니다. 예를 들어 일일 주문량이 5천만 건인 핀둬둬(Pinduoduo)는 반년 만에 수백억 건의 데이터를 보유하고 있습니다. 점수는 4096입니다. 표는 맞지만 실제 운영은 동일합니다. 귀하의 비즈니스에 있어서 꼭 4096으로 나눌 필요는 없습니다. 비즈니스에 따라 합리적인 선택을 하십시오.

샤딩키를 기반으로 쿼리를 쉽게 해결할 수 있습니다. 비샤딩키에 대한 쿼리는 데이터, 데이터 웨어하우스, ES의 이중 복사본을 삭제하여 해결할 수 있습니다. 물론 분할 후 데이터 양이 매우 적다면 인덱스를 구축하세요. , 쿼리를 위해 전체 테이블을 스캔하는 것은 실제로 문제가 되지 않습니다.

관련 무료 학습 권장사항: mysql 비디오 튜토리얼

위 내용은 수백억 개의 데이터를 테이블로 나눈 후 페이징 쿼리 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!