테이블 파티셔닝은 어떻게 도움이됩니까?

테이블 파티셔닝의 장단점을 파악하기가 어렵습니다. 8 개의 테이블이있는 프로젝트에 대한 작업을 시작하려고하며 그 중 하나는 1 억 8 천 2 백만 2 천만 레코드를 보유 할 기본 데이터 테이블이됩니다. 제대로 인덱스 된 테이블이므로 테이블 레코드를이 방법으로 2 천만으로 제한하여 9-13 테이블을 만들어야한다고 생각합니다.

그러나 동일한 컴퓨터 (32GB RAM)에 앉아 있기 때문에 성능을 어떻게 향상 시킬지 잘 모르겠습니다.

나는 MySQL을 사용하고 있으며 테이블은 MyISAM이 될 것이고 큰 테이블은 id 필드에 인덱스를 가질 것이고 전체 텍스트 검색과 같은 더 복잡한 것은 없다.

또한 테이블 파티셔닝과 데이터베이스 파티셔닝에 대해 간략히 설명하십시오.

다음은 미친 짓과 욕설입니다 ...

모든 데이터를 하나의 테이블에두면 (파티셔닝 없음) 키를 사용하여 O (log n) 검색 시간이 발생합니다. 세계에서 최악의 인덱스 인 이진 트리를 보자. 각 트리 노드에는 정확히 하나의 키가 있습니다. 268,435,455 (2 ^ 28-1) 트리 노드가있는 완벽하게 균형 잡힌 이진 트리의 높이는 28입니다.이 이진 트리를 16 개의 개별 트리로 분할하면 16,777,215 (2 ^ 24-1)의 이진 트리가 각각 16 개가됩니다. 검색 경로는 14.2857 %의 높이 인 4 개의 노드로 줄어 듭니다. 검색 시간이 마이크로 초인 경우 검색 시간이 14.2857 % 감소하면 무시할 수 없습니다.

실제 환경에서 BTREE 인덱스에는 여러 키가있는 트리 노드가 있습니다. 각 BTREE 검색은 페이지 내에서 이진 검색을 수행하여 다른 페이지에 적절한 검색을 수행합니다. 예를 들어, 각 BTREE 페이지에 1024 개의 키가 포함 된 경우 3 또는 4의 트리 높이가 일반적으로 짧은 트리 높이입니다.

테이블의 참여가 이미 작은 BTREE의 높이를 줄이지는 않습니다. 260 백만 행의 분할로 인해 동일한 높이의 여러 BTREE를 가질 가능성이 높습니다. 키를 검색하면 매번 모든 루트 BTREE 페이지를 통과 할 수 있습니다. 하나만 필요한 검색 범위의 경로를 충족시킵니다.

이제 이것을 확장하십시오. 모든 파티션이 같은 머신에 존재합니다. 각 파티션에 별도의 디스크가없는 경우 파티션 검색 성능을 벗어나는 자동 병목 현상으로 디스크 I / O 및 스핀들 회전이 발생합니다.

이 경우 데이터베이스별로 분류하면 id가 유일한 검색 키인 경우 아무 것도 구매하지 않습니다.

데이터 분할은 동일한 클래스에 논리적이고 응집력이있는 데이터를 그룹화하는 역할을합니다. 데이터가 올바르게 그룹화되어 있으면 각 파티션 검색 성능을 고려해야합니다. 논리 파티셔닝을 달성하면 검색 시간에 집중하십시오. ID로만 데이터를 분리하는 경우 읽기 또는 쓰기를 위해 많은 데이터 행에 액세스하지 못할 수 있습니다. 이제, 그 주요 고려 사항이어야한다 : 모든 ID가 가장 자주하는 액세스 및 파티션 찾습니다 . 자주 액세스하지 않는 모든 ID는 하나의 큰 아카이브 테이블에 있어야하며,이 인덱스는 '블루 문에서 한 번'쿼리에 대한 인덱스 조회로 여전히 액세스 할 수 있습니다.

전체적으로 미치는 영향은 두 개 이상의 파티션을 가져야합니다. 하나는 자주 액세스하는 ID 용이고 다른 하나는 나머지 ID 용입니다. 자주 액세스하는 ID가 상당히 큰 경우 선택적으로 분할 할 수 있습니다.

2 억 개의 행이 확실히 테이블 파티셔닝의 혜택을 누릴 수있는 범위에 있습니다. 응용 프로그램에 따라 아래 나열된 장점 중 일부를 베팅 할 수 있습니다.

• 오래된 데이터 제거 용이 6 개월 이상 된 레코드를 삭제해야하는 경우 날짜를 기준으로 테이블을 분할 한 다음 이전 파티션을 교체 할 수 있습니다. 이는 테이블에서 데이터를 삭제하는 것보다 훨씬 빠르며 종종 라이브 시스템에서 수행 할 수 있습니다. OP의 경우 시스템 유지 관리에 도움이 될 수 있습니다.

• 다중 디스크 볼륨 분할을 사용하면 데이터를 분할하여 디스크 트래픽을 여러 디스크 볼륨에 분산시켜 속도를 높일 수 있습니다. 최신 RAID 컨트롤러에서는 OP에 문제가되지 않습니다.

• 더 빠른 테이블 및 범위 스캔 실제로 운영 체제는 이런 종류의 작업을 수행하지 않아야하지만 데이터웨어 하우스 또는 이와 유사한 시스템은 이러한 종류의 쿼리를 대량으로 수행합니다. 테이블 스캔은 주로 순차적 디스크 트래픽을 사용하므로 일반적으로 테이블에서 행의 몇 퍼센트 이상을 리턴하는 쿼리를 처리하는 가장 효율적인 방법입니다.
  
  공통 필터 (일반적으로 시간 또는 기간 기반)에 의한 파티셔닝은 술어가 파티셔닝 키에 대해 분석 될 수있는 경우 이러한 쿼리에서 테이블의 큰 청크를 제거 할 수 있도록합니다. 또한 테이블을 여러 볼륨으로 분할 할 수있어 큰 데이터 세트에 대해 상당한 성능 향상을 제공 할 수 있습니다. 일반적으로 이것은 운영 체제의 문제가 아닙니다.

OP의 목적 상 파티셔닝은 운영 쿼리에서 많은 성능 이점을 얻을 수는 없지만 시스템 관리에는 유용 ​​할 수 있습니다. 많은 양의 데이터에 걸쳐 집계를보고해야하는 중요한 요구 사항이있는 경우 적절한 파티션 구성표가 도움이 될 수 있습니다.

파티셔닝은 모든 인덱스가 파티셔닝 된 경우 파티션별로 동시 재구성을 허용합니다. 그렇지 않은 경우 파티션은 여전히 ​​더 작고 재구성하기 위해 더 적은 작업 공간을 사용합니다. 또한 내부적으로 "좋은"DBMS는 분할 된 테이블과 병렬로 작업을 수행 할 수 있습니다. 아마 MySQL이나 MyISAM을 포함하지 않을 것입니다 ...