1 기본 아이디어: 하위 데이터베이스와 하위 테이블이란 무엇입니까?
문자 그대로의 의미로 간단히 이해하면, 원래 하나의 데이터베이스에 저장된 데이터를 블록 단위로 여러 라이브러리에 저장하고, 원래 하나의 테이블에 저장된 데이터를 블록 단위로 여러 테이블에 저장한다는 의미입니다.
2 기본 아이디어: 왜 데이터베이스와 테이블을 분리해야 할까요?
데이터
하위 데이터베이스와 테이블이 없으면 시간과 비즈니스의 발전에 따라 데이터베이스의 데이터 양이 반드시 제어 가능한 것은 아닙니다. 변경 사항은 점점 더 많아지고 테이블의 데이터 양도 점점 더 많아질 것입니다. 이에 따라 데이터 작업, 추가, 삭제, 수정 및 쿼리 비용도 점점 더 커질 것입니다. 서버의 자원(CPU, 디스크, 메모리, IO 등)은 제한되어 있으며, 결국 데이터베이스가 운반할 수 있는 데이터의 양과 데이터 처리 능력에 병목 현상이 발생하게 됩니다.
3 데이터베이스 및 테이블 샤딩 구현 전략.
데이터베이스 및 테이블 샤딩에는 수직 샤딩과 수평 샤딩의 두 가지 유형이 있습니다.
3.1
수직 분할이란, 즉 기능 모듈과 긴밀한 관계에 따라 테이블을 나누고 이를 다른 라이브러리에 배포하는 것입니다. 예를 들어, 프로젝트 데이터 정의 테이블, 제품 정의 테이블, 사용자 데이터 테이블 및 로그 데이터 테이블을 각각 저장하는 데 사용되는 정의 데이터베이스 workDB, 제품 데이터베이스 payDB, 사용자 데이터 라이브러리 userDB, 로그 데이터베이스 logDB 등을 구축합니다. . 기다리다.
3.2
수평 분할이란 무엇인가요? 테이블의 데이터 양이 너무 많은 경우 userID 해싱과 같은 특정 규칙에 따라 테이블의 데이터를 나눌 수 있습니다. , 동일한 구조와 다른 라이브러리를 사용하여 여러 테이블에 저장됩니다
. 예를 들어, 우리 userDB의 사용자 데이터 테이블에서는 각 테이블에 많은 양의 데이터가 있으므로 userDB는 part0DB,
part1DB 등 동일한 구조를 가진 여러 userDB로 나눌 수 있으며, 그런 다음 userDB의 사용자 데이터 테이블 userTable은 userTable0, userTable1 등 여러 userTable로 나뉩니다.
그런 다음 이러한 테이블은 특정 규칙에 따라 여러 userDB에 저장됩니다.
3.3 데이터베이스 샤딩과 테이블 샤딩을 구현하기 위해 어떤 방법을 사용해야 하는지는 데이터베이스 내 데이터 볼륨의 병목 현상과 프로젝트의 비즈니스 유형에 따라 다릅니다.
데이터베이스에서 테이블이 너무 많아 대용량 데이터가 발생하고, 프로젝트의 비즈니스 로직이 명확하게 구분되고 낮은 결합을 이루고 있다면 간단하고 구현하기 쉬운 규칙을 사용한 수직적 세분화가 반드시 필요합니다. 첫 번째 선택.
그리고
데이터베이스에 테이블이 많지 않지만 단일 테이블에 포함된 데이터의 양이 많거나 데이터의 인기가 매우 높은 경우에는 이 경우를 선택해야 합니다. 수평 분할은 수직 분할보다 더 복잡합니다. 원래 논리적으로 하나의 엔터티에 속한 데이터를 물리적으로 분리합니다. 분할 중 분할의 세분성을 평가하는 것 외에도 데이터의 평균 합계를 고려해야 합니다. 또한 향후 프로젝트 인력과 애플리케이션에 추가적인 데이터 관리 부담을 부과합니다.
실제 프로젝트에서는 이 두 가지 상황이 결합되는 경우가 많아 절충이 필요하며, 수직적, 수평적 분할이 모두 필요한 경우도 있습니다. 우리 게임 프로젝트는 수직 분할과 수평 분할의 조합을 사용합니다. 먼저 데이터베이스를 수직 분할한 다음 테이블의 일부(일반적으로 사용자 데이터 테이블)를 수평 분할합니다.
4 하위 데이터베이스 및 하위 테이블에 문제가 있습니다.
4.1 거래 문제.
데이터베이스와 테이블 파티셔닝을 수행한 후 데이터가 서로 다른 라이브러리에 저장되어 데이터베이스 트랜잭션 관리가 어려워졌습니다. 트랜잭션을 실행하기 위해 데이터베이스 자체의 분산 트랜잭션 관리 기능에 의존한다면 높은 성능 비용을 지불하게 되며, 애플리케이션이 제어를 지원하고 프로그램 논리 트랜잭션을 구성하면 프로그래밍 부담도 발생합니다.
4.2 교차 데이터베이스 및 교차 테이블 조인 문제.
데이터베이스 및 테이블 샤딩을 수행한 후에는 원래 논리적 관련성이 높은 데이터가 다른 테이블과 다른 라이브러리로 분할되는 것이 불가피합니다. 이때 테이블의 연결 작업은 제한될 수 없습니다. 서로 다른 하위 데이터베이스에 있는 테이블을 조인하거나 서로 다른 하위 테이블 단위로 테이블을 조인할 수 없습니다. 따라서 하나의 쿼리로 완료할 수 있는 비즈니스를 완료하려면 여러 쿼리가 필요할 수 있습니다.
4.3 추가적인 데이터 관리 부담 및 데이터 컴퓨팅 부담.
추가적인 데이터 관리 부담
가장 눈에 띄는 문제는 데이터 위치 문제와 데이터 추가, 삭제, 수정, 쿼리의 반복적인 실행 문제입니다. 이는 애플리케이션을 통해 해결할 수 있지만. 예를 들어
사용자 결과를 기록하는 사용자 데이터 테이블 userTable의 경우 비즈니스에서는 테이블을 나누기 전에 100개의 최상의 결과를 찾아야 합니다.
By 문도 가능하지만 테이블을 나눈 후 각 테이블의 상위 100개 사용자 데이터를 찾아 비교하려면 n개의 순서
by 문이 필요합니다. 결과를 얻기 위해 계산되었습니다.