MySQL-하위 데이터베이스 및 테이블 하위 데이터베이스에 대한 팁 공유

샤딩은 데이터베이스에 대한 부담을 분산시키는 좋은 방법입니다.

가장 간단한 의미는 테이블 구조를 여러 테이블로 나눈 다음 동일한 라이브러리나 다른 라이브러리에 배치할 수 있다는 것입니다.
물론 어떤 상황에서 테이블을 나누어야 하는지 먼저 알아야 합니다. 개인적으로 하나의 테이블에 포함된 레코드의 개수가 수백만에서 수천만개에 이르게 되면 하위 테이블을 활용하는 것이 필요하다고 생각합니다.
1. 하위 테이블 분류
1> 세로 하위 테이블
은 같은 테이블에 있을 수 있는 내용을 인위적으로 여러 테이블로 나눕니다. (소위 원본이란 관계형 데이터베이스의 세 번째 패러다임의 요구 사항에 따라 동일한 테이블에 있어야 함을 의미합니다.)
테이블을 분할하는 이유: 데이터의 활동에 따라 분리합니다(활성 데이터가 다르기 때문). 처리 방법이 다릅니다)
사례:
블로그 시스템의 경우 기사 제목, 작성자, 카테고리, 생성 시간 등이 변경되는 빈도가 느리고 쿼리 수가 많고, 좋은 실시간 데이터를 보유하는 것이 가장 좋습니다. 이를 콜드 데이터라고 부릅니다. 블로그 조회수, 답글수 등 유사한 통계정보, 기타 상대적으로 높은 빈도로 변화하는 데이터를 우리는 활성 데이터라고 부릅니다. 따라서 데이터베이스 구조를 설계할 때 테이블 파티셔닝을 고려해야 합니다. 첫 번째는 수직 테이블 파티셔닝 처리입니다.
이런 방식으로 테이블을 수직으로 분할한 후:
우선, 스토리지 엔진을 다르게 사용하여 콜드 데이터에 대해 데이터를 더 잘 쿼리할 수 있습니다. 활성 데이터의 경우 업데이트 속도가 더 빠른 Innodb를 사용할 수 있습니다.
둘째, 더 많은 작업이 쿼리되므로 쿼리 속도가 빨라지므로 콜드 데이터에 대해 더 많은 슬레이브 데이터베이스를 구성합니다. 핫 데이터의 경우 기본 데이터베이스에서 상대적으로 수평 하위 테이블 처리가 더 많을 수 있습니다.
실제로 일부 특수한 활성 데이터의 경우 Memcache, Redis 등의 캐시 사용을 고려한 후 누적량이 일정량에 도달하면 데이터베이스를 업데이트할 수도 있습니다. 또는 mongodb와 같은 nosql 데이터베이스는 예시일 뿐이므로 이에 대해서는 먼저 이야기하지 않겠습니다.
2>가로 테이블 분할
문자 그대로의 의미에서 알 수 있듯이 큰 테이블 구조를 사용자 정보 테이블, user_1, user_2 등 동일한 구조의 여러 테이블로 수평으로 자르는 것입니다. 테이블 구조는 완전히 동일하지만 사용자 ID를 기준으로 모듈식 분할과 같은 특정 규칙에 따라 테이블이 구분됩니다.
테이블 분할 이유: 단일 테이블의 용량이 너무 크지 않도록 데이터 볼륨의 크기에 따라 분할하여 단일 테이블의 쿼리 및 기타 처리 기능을 보장합니다.
사례: 위의 예시와 동일, 블로그 시스템. 블로그의 양이 큰 수준에 도달하면 각 단일 테이블에 대한 부담을 줄이고 성능을 향상시키기 위해 수평 분할을 채택해야 합니다. 예를 들어, 블로그의 콜드 데이터 테이블을 100개의 테이블로 나눈다면, 100만 명의 사용자가 동시에 탐색할 때 단일 테이블이라면 100만 개의 요청이 발생합니다. 그러나 이제 테이블을 나눈 후에는, 10,000개의 데이터 요청을 수행하면(절대 평균을 얻는 것이 불가능하고 가정일 뿐이므로) 부담이 많이 줄어듭니다.

데이터베이스 복제는 접근 문제를 해결할 수 있지만, 대규모 동시 쓰기 문제는 해결할 수 없습니다. 이 문제를 해결하려면 이름처럼 mysql 데이터 분할을 고려해야 합니다.

데이터 분할 즉, 데이터가 분산되어 있으며, 단일 호스트의 부하 부담을 줄이기 위해 하나의 호스트에 있는 데이터가 여러 호스트에 분산됩니다. 분할 방법에는 두 가지가 있습니다. 하나는 비즈니스 모듈에 따라 데이터베이스를 여러 개의 데이터베이스로 나누는 것입니다. 데이터베이스에는 테이블이 다릅니다. 또 다른 방법은 특정 비즈니스 규칙이나 논리에 따라 데이터를 여러 호스트로 분할하는 것입니다. 이는 Oracle의 테이블 파티셔닝과 다소 유사합니다.

하위 라이브러리는 수직 분할이라고도 합니다. 이 방법은 구현이 비교적 간단합니다. 중요한 것은 비즈니스를 세분화할 때 각 비즈니스 모듈 간의 상호 작용을 명확하게 생각해야 한다는 것입니다. 앞으로 프로그램 작성을 피하기 위한 모듈입니다. 데이터베이스 간 작업이 너무 많습니다.

테이블 파티셔닝은 수평 파티셔닝이라고도 합니다. 이 방법은 수직 파티셔닝보다 구현하기가 더 복잡하지만 수직 파티셔닝이 해결할 수 없는 문제, 즉 단일 테이블에 대한 액세스 및 쓰기가 매우 까다롭다는 문제를 해결할 수 있습니다. 이때 테이블은 특정 비즈니스 규칙에 따라 분할될 수 있습니다(PS: 예를 들어 인터넷 BBS 포럼의 회원 등급 개념: 테이블은 회원 등급에 따라 구분됩니다). 단일 테이블을 사용하여 다양한 모듈 간의 빈번한 충돌을 해결합니다.

하위 데이터베이스의 장점은 구현이 간단하고 라이브러리 간의 경계가 명확하며 유지 관리가 쉽다는 점입니다. 단점은 데이터베이스 간 작업을 자주 수행하는 데 도움이 되지 않으며 대규모 데이터 볼륨의 문제가 있다는 것입니다. 단일 테이블은 해결할 수 없습니다.

하위 테이블의 장점은 하위 데이터베이스의 단점을 해결할 수 있다는 점이지만, 단점은 바로 하위 데이터베이스의 장점입니다. 하위 테이블의 구현은 특히 분할이 더 복잡합니다. 테이블 하위 규칙, 프로그램 작성, 나중에 데이터베이스 분할 마이그레이션 및 유지 관리.

실제 적용에서 인터넷 회사의 일반적인 경로는 데이터베이스를 먼저 나눈 다음 테이블을 나누어 서로의 장점을 배우기 위해 결합하는 것입니다. mysql 확장이 가능하지만 아키텍처가 크고 복잡하다는 단점이 있습니다.

위 내용은 MySQL-하위 데이터베이스 및 테이블 하위 데이터베이스에 대한 팁 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!