2000w 데이터 테이블의 최적화 프로세스를위한 세 가지 솔루션 제공

MySQL 데이터베이스 (즉, MySQL 5.6 버전)에 Alibaba Cloud rds를 사용하면 6 개월 동안 데이터 볼륨이 거의 2 천만 건에 달하는 사용자의 온라인 레코드 테이블이 있으며 최근 1 년 동안 데이터 볼륨이 4 천만에 도달했습니다. 쿼리 속도가 매우 느리고 매일 멈춰 있습니다. . 비즈니스에 심각한 영향을 미칩니다.

문제 전제 : 구 시스템, 당시 시스템을 설계 한 사람은 아마도 대학을 졸업하지 않았을 것입니다. 테이블 디자인과 SQL 문은 쓰레기가 아니었고 직접 볼 수 없었습니다. 원래 개발자들은 모두 떠나서 유지 보수를 위해 나에게옵니다. 이것은 유지 보수없이 도망 치는 전설적인 사람이고, 그리고 나서 구멍에 빠진 사람입니다! ! !

나는 문제를 해결하려고 노력한다. 그래서이 일지가있다.

프로그램 개요

옵션 1 : 기존 mysql 데이터베이스를 최적화합니다.

장점 : 기존 비즈니스에 영향을주지 않고 소스 프로그램이 코드를 수정할 필요가 없으며 비용이 가장 낮습니다. 단점 : 최적화 병목 현상이 있으며 데이터 양이 1 억이 넘습니다.

옵션 2 : 데이터베이스 유형을 mysql과 100 % 호환되는 데이터베이스로 업그레이드합니다.

장점 : 기존 비즈니스에 영향을주지 않고 소스 프로그램이 코드를 수정할 필요가 없으며 데이터베이스 성능을 향상시키기 위해 어떤 작업도 할 필요가 거의 없습니다. 단점 : 더 많은 비용

옵션 3 : 한 단계, 빅 데이터 솔루션, newsql / nosql 데이터베이스 교체.

장점 : 강력한 확장 성, 저렴한 비용, 데이터 용량 병목 현상 없음, 단점 : 소스 코드 수정 필요

위의 세 가지 방식을 순서대로 사용할 수 있으며 데이터 량이 1 억 미만이면 nosql로 변경할 필요가 없으며 개발 비용이 너무 많이 든다. 나는 세 가지 옵션을 모두 시도해 보았고 모두 착륙 솔루션을 형성했습니다. 그 과정에서 만번 도망친 개발자들에게 애도를 표했다. :)

옵션 1 : 기존 mysql 데이터베이스 최적화

Alibaba Cloud 데이터베이스 보스, Google 솔루션과 의사 소통하고 그룹 보스에게 다음과 같이 요약하여 묻습니다 (모든 본질).

데이터베이스 설계 및 테이블 생성시 성능을 고려해야합니다.
SQL 준비에는 최적화에 대한주의가 필요합니다.
분할
하위 테이블
하위 도서관

1. 데이터베이스 설계 및 테이블 생성시 성능 고려

mysql 데이터베이스 자체는 매우 유연하여 성능이 불충분하고 개발자의 능력에 크게 의존합니다. 즉, 개발자의 능력이 높으면 mysql 성능이 높다. 이것은 또한 많은 관계형 데이터베이스의 일반적인 문제이므로 회사의 dba는 일반적으로 막대한 급여를받습니다.

테이블을 디자인 할 때주의하십시오.

테이블 필드는 null 값의 발생을 방지합니다. Null 값은 쿼리 및 최적화가 어렵고 추가 인덱스 공간을 차지합니다. null을 대체하려면 기본값 0을 사용하는 것이 좋습니다.
BIGINT 대신 INT를 사용하십시오. 음수가 아닌 경우 UNSIGNED를 추가하십시오 (값 용량이 두 배가 됨). 물론 TINYINT, SMALLINT 및 MEDIUM_INT를 사용하는 것이 좋습니다.
문자열 유형 대신 열거 형 또는 정수 사용
DATETIME 대신 TIMESTAMP를 사용하십시오.
단일 테이블에 너무 많은 필드를 포함하지 마십시오. 20 개 이내를 권장합니다.
정수를 사용하여 IP 저장

인덱스

인덱스는 가능한 한 많지 않습니다. 쿼리에 따라 대상 지정 방식으로 생성해야합니다. WHERE 및 ORDER BY 명령과 관련된 열에 인덱스 생성을 고려하십시오. 인덱스 사용 여부 또는 EXPLAIN에 따라 전체 테이블 스캔을 확인할 수 있습니다.
WHERE 절에서 필드의 NULL 값 판단을 피해야합니다. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 전체 테이블 스캔을 수행하게됩니다.
값이 두 개 또는 세 개 뿐인 '성별'필드와 같이 값이 분산 된 필드는 인덱싱에 적합하지 않습니다.
문자 필드에 대한 접두사 색인 만
문자 필드는 기본 키가 아닌 것이 가장 좋습니다.
프로그램에서 보장하는 외래 키 없음
UNIQUE를 사용하지 마십시오. 프로그램 보증에 구속됩니다.
다중 열 인덱스를 사용하는 경우 아이디어 순서와 쿼리 조건이 일관되고 불필요한 단일 열 인덱스가 삭제됩니다.

요컨대, 적절한 데이터 유형을 사용하고 적절한 인덱스를 선택하십시오.

올바른 데이터 유형 선택

(1) 데이터를 저장할 수있는 가장 작은 데이터 유형, 정수 <날짜, 시간 <char, varchar <blob 사용
(2) 단순 데이터 유형 사용 문자열 비교가 더 복잡하기 때문에 정수는 문자 처리보다 저렴합니다. 예를 들어 int 유형 저장 시간 유형, bigint 유형에서 ip 함수로
(3) 합리적인 필드 속성 길이를 사용하면 고정 길이 테이블이 더 빠릅니다. varchar 대신 enum, char 사용
(4) 가능한 한 필드를 정의하려면 null이 아님을 사용하십시오.
(5) 텍스트를 가능한 한 적게 사용하고 표를 분리하는 것이 가장 좋습니다.

적절한 색인 열 선택

(1) 자주 쿼리하는 열, where, group by, order by 및 on 절에 나타나는 열
(2) where 조건에서 <, <=, =,>,> =, between, in 및 like string + wildcard (%)가 나타나는 열
(3) 길이가 작은 컬럼의 경우 인덱스 필드가 작을수록 데이터베이스의 저장 단위가 페이지이므로 한 페이지에 저장할 수있는 데이터가 많을수록 좋습니다.
(4) 큰 분산 (많은 다른 값)을 가진 열은 조인트 인덱스 앞에 배치됩니다. 다른 열 값을 세어 얻어지는 분산 정도를 확인합니다. 카운트가 클수록 분산 정도가 높아집니다.

원래 개발자가 도망 쳤습니다. 테이블이 이미 생성되어 수정할 수 없습니다. 따라서 문구를 구현할 수 없습니다. 포기하십시오!

2. SQL 준비에는 최적화에주의가 필요합니다.

제한을 사용하여 쿼리 결과 기록 제한
*를 선택하지 말고 찾아야하는 필드를 나열하십시오.
하위 쿼리 대신 조인 사용
큰 삭제 또는 삽입 문 분할
느린 쿼리 로그를 켜서 느린 SQL을 찾을 수 있습니다.
열 계산을 수행하지 마십시오 : SELECT id WHERE age + 1 = 10, 열에 대한 모든 작업은 데이터베이스 자습서 함수, 계산 식 등을 포함하는 테이블 스캔을 수행합니다. 쿼리 할 때 작업을 가능한 한 등호 오른쪽으로 이동합니다.
SQL 문은 가능한 한 간단합니다. 하나의 SQL은 하나의 CPU에서만 작동 할 수 있습니다. 큰 문은 잠금 시간을 줄이기 위해 작은 문을 분할합니다. 하나의 큰 SQL은 전체 라이브러리를 차단할 수 있습니다.
OR은 IN으로 재 작성 : OR의 효율은 n 레벨, IN의 효율은 log (n) 레벨, in 수는 200 이내로 제어하는 것이 좋습니다.
기능 및 트리거없이 애플리케이션에서 구현
% xxx 스타일 쿼리 방지
더 적게 JOIN 사용
'123'과 '123'의 비율, 123과 123의 비율과 같은 동일한 유형을 비교에 사용하십시오.
WHERE 절에서! = 또는 <> 연산자를 사용하지 마십시오. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 전체 테이블 스캔을 수행합니다.
연속 값의 경우 IN없이 BETWEEN 사용 : SELECT id FROM t WHERE num BETWEEN 1 AND 5
목록 데이터를 위해 전체 테이블을 사용하지 말고 페이지에 LIMIT를 사용하고 페이지 수가 너무 많으면 안됩니다.

원래 개발자가 달아 났고 프로그램이 완료되고 온라인 상태가되었으며 SQL을 수정할 수 없으므로 문구를 실행할 수 없습니다. 포기하십시오!

엔진

현재 MyISAM과 InnoDB의 두 가지 엔진이 널리 사용됩니다.

MyISAM

MyISAM 엔진은 MySQL 5.1 및 이전 버전의 기본 엔진입니다. 그 특징은 다음과 같습니다.

행 잠금은 지원되지 않으며, 읽어야하는 모든 테이블은 읽을 때 잠기 며, 쓰기시 테이블에 배타적 잠금이 추가됩니다.
거래를 지원하지 않습니다
외래 키를 지원하지 않습니다.
충돌 후 안전한 복구를 지원하지 않습니다.
테이블에 읽기 쿼리가있는 동안 테이블에 새 레코드 삽입을 지원합니다.
BLOB 및 TEXT의 처음 500 자 인덱스 지원, 전체 텍스트 인덱스 지원
쓰기 성능을 크게 향상시키는 지연된 인덱스 업데이트 지원
수정되지 않는 테이블의 경우 압축 된 테이블이 지원되므로 디스크 공간 사용량이 크게 줄어 듭니다.

InnoDB

InnoDB는 MySQL 5.5 이후 기본 인덱스가되었습니다. 특징은 다음과 같습니다.

행 잠금 지원, MVCC를 사용하여 높은 동시성 지원
지원 업무
외래 키 지원
충돌 후 안전한 복구 지원
전체 텍스트 인덱싱을 지원하지 않습니다.

일반적으로 MyISAM은 SELECT 집약적 테이블에 적합하고 InnoDB는 INSERT 및 UPDATE 집약적 테이블에 적합합니다.

MyISAM은 매우 빠르고 작은 저장 공간을 차지할 수 있지만 프로그램에는 트랜잭션 지원이 필요하므로 InnoDB가 필요하므로 프로그램을 구현할 수 없습니다. 포기하십시오!

3. 파티션

버전 5.1에서 MySQL이 도입 한 분할은 단순한 수평 분할로, 사용자는 테이블을 생성 할 때 파티션 매개 변수를 추가해야하므로 코드 수정없이 애플리케이션에 투명합니다.

사용자의 경우 분할 테이블은 독립적 인 논리 테이블이지만 맨 아래 계층은 여러 개의 물리적 하위 테이블로 구성됩니다. 분할을 달성하기위한 코드는 실제로 맨 아래 테이블의 개체 집합에 의해 캡슐화되지만 SQL 계층에 대한 완전한 테이블입니다. 하단 블랙 박스를 캡슐화합니다. MySQL이 파티셔닝을 구현하는 방식은 인덱스도 파티션의 하위 테이블에 따라 정의되고 전역 인덱스가 없음을 의미합니다.

사용자의 SQL 문은 파티션 테이블에 맞게 최적화되어야합니다. SQL 조건에는 파티션 조건의 열이 포함되어 쿼리가 소수의 파티션에 위치해야합니다. 그렇지 않으면 모든 파티션이 스캔됩니다. EXPLAIN PARTITIONS를 통해 SQL 문을 볼 수 있습니다. SQL 최적화를 위해 해당 파티션에 해당됩니다. 쿼리 할 때 파티션 조건이없는 열도 속도가 빨라지는 것으로 테스트 했으므로이 방법을 시도해 볼 가치가 있습니다.

파티셔닝의 이점은 다음과 같습니다.

단일 테이블에 더 많은 데이터를 저장할 수 있음
파티션 테이블의 데이터는 유지 관리가 용이하며 전체 파티션을 삭제하여 대량의 데이터를 일괄 삭제하거나 새로 삽입 된 데이터를 지원하기 위해 새 파티션을 추가 할 수 있습니다. 또한 독립 파티션을 최적화, 확인 및 복구 할 수 있습니다.
쿼리의 일부는 쿼리 조건에서 몇 개의 파티션에만 속하도록 결정할 수 있으며 속도는 매우 빠릅니다.
파티션 테이블의 데이터는 여러 물리적 장치에 분산되어 여러 하드웨어 장치를 사용할 수도 있습니다.
파티션 테이블은 InnoDB 단일 인덱스의 상호 배타적 액세스, ext3 파일 시스템의 inode 잠금 경쟁과 같은 특수 병목 현상을 방지하는 데 사용할 수 있습니다.
단일 파티션 백업 및 복원 가능

파티션의 한계 및 단점 :

테이블에는 최대 1024 개의 파티션 만있을 수 있습니다.
파티션 필드에 기본 키 또는 고유 인덱스 열이있는 경우 모든 기본 키 열과 고유 인덱스 열이 포함되어야합니다.
파티션을 나눈 테이블은 외래 키 제약 조건을 사용할 수 없습니다.
NULL 값은 파티션 필터링을 무효화합니다.
모든 파티션은 동일한 스토리지 엔진을 사용해야합니다.

파티션 유형 :

RANGE 파티션 : 주어진 연속 간격에 속하는 열 값을 기반으로 파티션에 여러 행을 할당합니다.
LIST 파티션 : RANGE 별 파티션과 유사하지만 차이점은 개별 값 집합의 값과 일치하는 열 값을 기준으로 LIST 파티션이 선택된다는 것입니다.
HASH 파티션 : 테이블에 삽입 할 이러한 행의 열 값을 사용하여 계산되는 사용자 정의 식의 반환 값을 기반으로 선택되는 파티션입니다. 이 함수는 MySQL에서 유효하고 음이 아닌 정수 값을 생성하는 모든 표현식을 포함 할 수 있습니다.
KEY 파티션 : HASH 별 파티션과 유사하게 차이점은 KEY 파티션은 하나 이상의 열 계산 만 지원하고 MySQL 서버는 자체 해시 기능을 제공한다는 것입니다. 하나 이상의 열에 정수 값이 포함되어야합니다.

mysql 파티션의 개념에 대한 자세한 내용은 직접 google 또는 공식 문서를 문의하십시오.

먼저 인터넷 기록 테이블 RANGE를 월별로 12 개로 분할했는데 쿼리 효율이 약 6 배 증가했지만 그 효과가 분명하지 않았기 때문에 ID를 HASH 파티션으로 변경하고 64 개 파티션으로 나누었고 쿼리 속도가 크게 증가했습니다. 문제 해결됨!

결과는 다음과 같습니다. PARTITION BY HASH (id) PARTITIONS 64

readroom_website에서 count () 선택; --11901336 행

/ 영향을받는 행 수 : 0 발견 된 레코드 : 1 경고 : 0 기간 1 쿼리 : 5.734 초 /

select * from readroom_website where month (accesstime) = 11 limit 10;

/ 영향을받는 행 수 : 0 발견 된 레코드 : 10 경고 : 0 기간 1 쿼리 : 0.719 초 * /

4. 하위 테이블

테이블 분할은 위의 프로세스에 따라 큰 테이블을 최적화하거나 쿼리가 멈춘 다음 테이블을 여러 테이블로 나누고 쿼리를 여러 쿼리로 분할 한 다음 결과 조합을 사용자에게 반환하는 것입니다.

하위 테이블은 세로 분할과 가로 분할로 구분되며 일반적으로 분할 항목으로 특정 필드를 사용합니다. 예를 들어 id 필드를 100 개의 테이블로 분할합니다. 테이블 이름은 tableName_id % 100입니다.

그러나 서브 테이블의 소스 코드를 수정해야하므로 개발에 많은 작업이 필요하고 개발 비용이 크게 증가하므로 개발 초기 단계에서 대량의 데이터가 존재하는 경우에만 적합하며 서브 테이블 처리는 적용에 적합하지 않습니다. 온라인 상태에서 변경하기에는 너무 비쌉니다! ! ! 그리고이 계획을 선택하는 것은 내가 제공 한 두 번째와 세 번째 계획을 선택하는 것만 큼 낮지 않습니다! 권장하지 않습니다.

5. 하위 도서관

데이터베이스를 여러 개로 나누면 읽기-쓰기 분리를 수행하는 것이 좋습니다. 데이터베이스의 실제 분할도 많은 개발 비용을 가져 오며 이득은 손실의 가치가 없습니다! 권장하지 않습니다.

옵션 2 : 데이터베이스를 mysql과 100 % 호환되는 데이터베이스로 업그레이드

MySQL 성능이 좋지 않다면 변경하십시오. 소스 코드가 수정되지 않고 기존 비즈니스의 원활한 마이그레이션을 보장하려면 MySQL과 100 % 호환되는 데이터베이스로 변경해야합니다.

오픈 소스 옵션

tiDB https://github.com/pingcap/tidb
큐브리드 https://www.cubrid.org/

오픈 소스 데이터베이스는 많은 운영 및 유지 관리 비용을 가져 오지만 여전히 산업 품질과 MySQL 사이에는 격차가 있습니다. 단계가 많이 있습니다. 회사에서 자체 데이터베이스를 구축해야하는 경우이 유형의 제품을 선택하십시오.

클라우드 데이터 선택

알리바바 클라우드 PolarDB

https://www.aliyun.com/product/polardb?spm=a2c4g.11174283.cloudEssentials.47.7a984b5cS7h4wH

공식 소개 : PolarDB는 Alibaba Cloud에서 자체 개발 한 차세대 관계형 분산 클라우드 네이티브 데이터베이스입니다. MySQL과 100 % 호환되며 최대 100T의 스토리지 용량과 MySQL의 최대 6 배의 성능을 제공합니다. POLARDB는 상용 데이터베이스의 안정적이고 신뢰할 수있는 고성능 특성을 결합 할뿐만 아니라 오픈 소스 데이터베이스의 단순하고 확장 가능하며 지속적인 반복이라는 장점도 가지고 있으며 비용은 상용 데이터베이스의 1/10에 불과합니다.

나는 테스트를 열었고, 무료 mysql 데이터 마이그레이션을 지원하고, 운영 비용이 없으며, 약 10 배의 성능 향상, 가격이 rds와 비슷하며 좋은 대안 솔루션입니다!

Alibaba Cloud OcenanBase

Taobao에서 사용하는 것은 Double Eleven에서 살아남을 수 있고 뛰어난 성능을 가지고 있지만 공개 베타에서는 시도 할 수 없지만 기대할 가치가 있습니다.

MySQL 용 Alibaba Cloud HybridDB (이전 명칭 : PetaData)

https://www.aliyun.com/product/petadata?spm=a2c4g.11174283.cloudEssentials.54.7a984b5cS7h4wH

공식 소개 : MySQL 용 HybridDB (이전 PetaData)는 대량 데이터의 온라인 트랜잭션 (OLTP)과 온라인 분석 (OLAP)을 모두 지원하는 HTAP (Hybrid Transaction / Analytical Processing) 관계형 데이터베이스입니다.

나는 또한 그것을 테스트했습니다. 그것은 olap 및 oltp 호환 솔루션이지만 가격이 너무 높고 시간당 10 위안만큼 높고 저장하기에 너무 낭비이며 저장 및 분석에 적합합니다.

Tencent 클라우드 DCDB

https://cloud.tencent.com/product/dcdb_for_tdsql

공식 소개 : TDSQL이라고도하는 DCDB는 MySQL 프로토콜 및 구문과 호환되고 자동 수평 분할을 지원하는 고성능 분산 데이터베이스입니다. 즉, 비즈니스는 완전한 논리 테이블로 표시되지만 데이터는 여러 분할로 균등하게 분할됩니다. ; 각 샤드는 기본적으로 마스터 백업 아키텍처를 채택하여 TB 또는 PB 수준의 대규모 데이터 시나리오에 적합한 재해 복구, 복구, 모니터링 및 논스톱 확장을위한 전체 솔루션 세트를 제공합니다.

나는 Tencent를 사용하는 것을 좋아하지 않으므로 더 이상 말하지 않겠습니다. 그 이유는 문제가 있으면 아무도 찾을 수없고 온라인 문제도 해결할 수 없기 때문입니다. 그러나 그는 저렴하고 초소형 회사에 적합합니다.

해결 방법 3 : mysql 제거, 데이터 처리를 위해 빅 데이터 엔진으로 변경

데이터의 양은 1 억이 넘고, 빅 데이터를 사용할 수밖에 없습니다.

오픈 소스 솔루션

hadoop 가족. Hbase / hive가 작동 중입니다. 그러나 운영 및 유지 비용이 높고 평균적인 회사는 그것을 감당할 수 없으며 100,000을 투자하지 않으면 좋은 결과를 얻을 수 없습니다!

클라우드 솔루션

그 이상이며 미래의 트렌드이기도합니다. 빅 데이터는 전문 기업과 중소기업 또는 개인이 서비스를 구매하여 제공합니다. 빅 데이터는 물 / 전기 및 기타 공공 시설과 같으며 사회의 모든 측면에 존재합니다.

중국 최고는 Alibaba Cloud입니다.

저는 Alibaba Cloud의 MaxCompute with DataWorks를 선택했습니다. 사용하기 매우 편리하고 종량제이며 매우 저렴한 비용입니다.

MaxCompute는 데이터를 조작하기 위해 sql / mapreduce / ai 알고리즘 / python 스크립트 / 셸 스크립트를 제공하는 오픈 소스 Hive로 이해할 수 있습니다. 데이터는 테이블 형태로 표시되고 분산 방식으로 저장되며 시간이 지정된 작업과 일괄 처리로 처리됩니다. DataWorks는 데이터 처리 작업을 관리하고 모니터링을 예약하는 워크 플로 방식을 제공합니다.

물론 Alibaba Cloud hbase와 같은 다른 제품을 선택할 수도 있습니다. 여기서는 주로 오프라인 처리를 사용하므로 기본적으로 그래픽 인터페이스 작업 인 MaxCompute를 선택합니다. 약 300 줄의 SQL이 작성되고 데이터 처리 문제를 해결하기위한 비용은 100 위안 이하입니다.