1. 머리말 的 데이터베이스의 데이터 양이 일정 수준에 도달한 후에는 시스템 성능 병목 현상을 방지합니다. 데이터는 파티셔닝, 샤딩, 데이터베이스, 테이블을 통해 처리되어야 합니다.

2. 샤딩(샤딩과 유사)

샤딩은 데이터베이스를 여러 물리적 노드로 확장하는 효과적인 방법으로, 주요 목적은 단일 노드 데이터베이스 서버의 용량 제한을 해결하는 것입니다. 데이터베이스 확장성 문제. 샤드(shard)라는 단어는 "조각"을 의미합니다. 데이터베이스를 큰 유리 조각으로 취급하고 유리가 깨진 경우 각 작은 조각을 데이터베이스 조각(데이터베이스 샤드)이라고 합니다. 전체 데이터베이스를 여러 조각으로 나누는 프로세스를 샤딩이라고 하며 이는 샤딩으로 번역될 수 있습니다. 공식적으로 샤딩은 대규모 데이터베이스를 여러 물리적 노드에 분산시키는 파티셔닝 방식으로 간단히 정의할 수 있습니다. 각 파티션에는 슬라이스라고 하는 데이터베이스의 특정 부분이 포함되어 있습니다. 파티셔닝 방법은 임의적일 수 있으며 기존의 수평 및 수직 파티셔닝에 국한되지 않습니다. 샤드는 여러 테이블의 내용이나 심지어 여러 데이터베이스 인스턴스를 포함할 수 있습니다. 각 샤드는 데이터베이스 서버에 배치됩니다. 데이터베이스 서버는 하나 이상의 데이터 샤드를 처리할 수 있습니다. 쿼리 라우팅 및 전달을 위해 시스템에 서버가 필요하며 쿼리 실행을 위해 액세스하는 데이터가 포함된 샤드 또는 샤드 수집 노드로 쿼리를 전달하는 역할을 담당합니다.

3. Scale Out/Scale Up 및 수직 분할/수평 분할

Mysql의 확장 솔루션에는 Scale Out 및 Scale Up이 포함됩니다. Scale Out(수평 확장)은 애플리케이션을 수평 방향으로 확장할 수 있다는 의미입니다. 일반적으로 데이터 센터 애플리케이션의 경우 스케일 아웃은 더 많은 머신이 추가되더라도 애플리케이션이 여전히 이러한 머신의 리소스를 잘 활용하여 자체 효율성을 향상하고 우수한 확장성을 달성할 수 있음을 의미합니다.

Scale Up(수직 확장)은 애플리케이션이 수직 방향으로 확장될 수 있음을 의미합니다. 일반적으로 단일 머신의 경우 Scale Up의 가치는 컴퓨팅 노드(머신)가 더 많은 CPU 코어, 저장 장치를 추가하고 더 큰 메모리를 사용할 때 애플리케이션이 이러한 리소스를 최대한 활용하여 효율성을 향상시킬 수 있다는 것입니다. 좋은 확장성을 달성합니다.

MySql의 샤딩 전략에는 수직 샤딩과 수평 샤딩이 포함됩니다.

수직(vertical) 분할: 테이블 간의 IO 경쟁을 해결하기 위해 기능 모듈별로 분할하는 것을 말합니다. 예를 들어 주문 데이터베이스, 상품 데이터베이스, 사용자 데이터베이스 등으로 나누어진다. 이처럼 여러 데이터베이스의 테이블 구조는 서로 다르다.

수평(수평) 분할: 동일한 테이블의 데이터를 블록으로 저장하고 다른 데이터베이스에 저장하여 단일 테이블의 데이터 양 증가에 대한 부담을 해결합니다. 이러한 데이터베이스의 테이블 구조는 완전히 동일합니다.

테이블 구조 디자인은 세로로 나누어져 있습니다. 몇 가지 일반적인 시나리오에는

대규모 필드의 수직 분할이 포함됩니다. 기본 테이블의 액세스 성능을 향상하려면 원칙적으로 큰 필드를 다른 테이블에 구축해야 합니다. 성능이 중요한 애플리케이션에서는 용도에 따라 수직 분할을 피해야 합니다. 예를 들어 기업의 자재 속성은 기본속성, 판매속성, 구매속성, 제조속성, 재무회계 속성 등에 따라 수직적으로 분할될 수 있다. 접근빈도에 따라 수직적으로 분할될 수 있다. 예를 들어 전자상거래나 Web 2.0 시스템에서 사용자 속성 설정이 많으면 기본, 자주 사용하는 속성과 자주 사용하지 않는 속성을 수직으로 분리하고, 테이블 구조 디자인을 수평으로 분리할 수 있다. 일반적인 시나리오는 다음과 같습니다.

예를 들어 온라인 전자상거래 웹사이트에서는 주문 테이블 데이터의 양이 너무 많고 연간 및 월별 수준으로 나누어져 있습니다.
Web 2.0 웹사이트에도 있습니다. 많은 등록 사용자와 온라인 활성 사용자를 사용자 ID 범위 등에 따라 수평으로 분할하는 방법. 해당 사용자와 사용자와 밀접하게 관련된 테이블을 수평으로 분할하는 방법
예를 들어, 포럼의 상단 게시물이 각 페이지에 표시되어야 합니다. 이 경우 페이징 문제로 인해 상단 포스트가 수평으로 분할될 수 있습니다. 고정된 포스트를 가져올 때 모든 포스트의 테이블에서 읽지 마세요.

하위 테이블 표면적으로는 테이블을 여러 개의 작은 테이블로 나누는 것을 의미하고, 파티셔닝은 테이블을 여러 개의 작은 테이블로 나누는 것을 의미합니다. 이러한 블록은 동일한 디스크에 있을 수도 있고 다른 디스크에 있을 수도 있습니다.
분할 테이블과 파티션의 차이점
구현 방법에 있어서

데이터 처리 측면에서

테이블을 분할한 후 데이터는 분할 테이블에 저장됩니다. 기본 테이블은 셸일 뿐이며 데이터 액세스는 각 분할 테이블에서 발생합니다. 파티셔닝에는 테이블 파티셔닝이라는 개념이 없습니다. 파티셔닝은 데이터를 저장하는 파일을 여러 개의 작은 블록으로 나누는 것뿐입니다. 파티셔닝된 테이블은 여전히 하나의 테이블이며, 데이터 처리는 여전히 스스로 완료됩니다.

성능 향상

테이블 분할 후 단일 테이블의 동시성 성능이 향상되었으며, 디스크 I/O 성능도 향상되었습니다. 파티션이 디스크 I/O 병목 현상을 해결하고 디스크의 읽기 및 쓰기 기능을 개선하여 mysql 성능을 높이고 싶습니다.

이 시점에서 파티션과 하위 테이블의 테스트 초점은 데이터에 액세스할 때 mysql의 동시성을 향상시키는 방법과 파티션의 읽기 및 쓰기 기능을 돌파하는 방법입니다. 디스크를 삭제하여 mysql의 성능을 향상시킵니다.

테이블을 나누는 방법은 구현이 어렵다는 점에서 여러 가지가 있지만, 병합을 사용하여 테이블을 나누는 것이 가장 간단한 방법입니다. 이 방법은 분할만큼 쉬우며 프로그램 코드에 투명할 수 있습니다. 다른 테이블 파티셔닝 방법을 사용하면 파티셔닝보다 더 번거롭습니다. 분할 구현은 비교적 간단합니다. 분할된 테이블을 만드는 것은 일반 테이블을 만드는 것과 다르지 않으며 코드 측면에서 투명합니다.

파티셔닝에 적용 가능한 시나리오

테이블의 쿼리 속도가 사용에 영향을 미칠 만큼 느린 경우.

테이블의 데이터는 분할되어 있습니다.
데이터에 대한 작업은 전체 데이터가 아닌 데이터의 일부만 포함하는 경우가 많습니다.

CREATE TABLE sales (

    id INT AUTO_INCREMENT,

    amount DOUBLE NOT NULL,

    order_day DATETIME NOT NULL,

    PRIMARY KEY(id, order_day)) ENGINE=InnodbPARTITION BY RANGE(YEAR(order_day)) (

    PARTITION p_2010 VALUES LESS THAN (2010),

    PARTITION p_2011 VALUES LESS THAN (2011),

    PARTITION p_2012 VALUES LESS THAN (2012),PARTITION p_catchall VALUES LESS THAN MAXVALUE);

로그인 후 복사

하위 테이블에 적용 가능한 시나리오

하나의 테이블 쿼리 속도가 너무 느려 사용량에 영향을 미칩니다.