데이터베이스와 테이블로 분할되는 MYSQL 데이터베이스 데이터 요약_MySQL

데이터 스토리지 진화 아이디어 1: 단일 데이터베이스와 단일 테이블

단일 데이터베이스와 단일 테이블은 가장 일반적인 데이터베이스 설계입니다. 예를 들어 데이터베이스 db에 사용자 테이블이 있고 모든 사용자는 db 데이터베이스의 사용자 테이블에서 찾을 수 있습니다.

데이터 스토리지 진화 아이디어 2: 여러 테이블이 있는 단일 데이터베이스

사용자 수가 증가함에 따라 사용자 테이블의 데이터 양은 점점 더 많아질 것입니다. 데이터 양이 일정 수준에 도달하면 사용자 테이블의 쿼리 속도가 점차 느려져 전체 성능에 영향을 미치게 됩니다. DB. mysql을 사용하는 경우 더 심각한 문제는 열을 추가해야 할 때 mysql이 테이블을 잠그고 그 동안 모든 읽기 및 쓰기 작업은 대기만 할 수 있다는 것입니다.

사용자는 어떤 방식으로든 수평으로 분할되어 user_0000, user_0001 등 완전히 동일한 구조를 가진 두 개의 테이블을 생성할 수 있습니다. user_0000 + user_0001 + ...의 데이터는 정확히 완전한 데이터입니다.

데이터 스토리지 진화 아이디어 3: 다중 데이터베이스 및 다중 테이블

데이터의 양이 증가함에 따라 단일 DB의 저장 공간이 부족할 수 있고, 쿼리 수가 증가함에 따라 단일 데이터베이스 서버에서는 더 이상 이를 지원할 수 없게 됩니다. 이때 데이터베이스는 수평적으로 구분될 수 있다.

Mysql 데이터베이스 샤딩 규칙

테이블을 디자인할 때 테이블이 데이터베이스와 테이블로 구분되는 규칙을 결정해야 합니다. 예를 들어, 새로운 사용자가 있는 경우 프로그램은 사용자 정보를 추가할 테이블을 결정해야 합니다. 마찬가지로 로그인할 때 사용자 계정을 통해 데이터베이스에서 해당 레코드를 찾아야 합니다. 규칙.
경로

샤딩 규칙을 통해 해당 테이블과 라이브러리를 찾는 과정입니다. 예를 들어, 데이터베이스 및 테이블 샤딩 규칙은 user_id mod 4입니다. 사용자가 계정 ID 123으로 새 계정을 등록하면 id mod 4를 사용하여 이 계정이 User_0003 테이블에 저장되어야 하는지 결정할 수 있습니다. 사용자 123이 로그인하면 123 mod 4를 전달하고 User_0003에 기록되어 있음을 확인합니다.

하위 데이터베이스 및 하위 테이블로 인해 발생하는 문제 및 주의사항은 다음과 같습니다

1. 하위 데이터베이스 및 하위 테이블 차원 문제

사용자가 상품을 구매하면 거래기록을 저장하고 불러와야 합니다. 사용자의 위도에 따라 테이블을 구분하면 각 사용자의 거래기록이 동일한 테이블에 저장되므로 빠르고 편리합니다. 사용자의 구매현황을 조회할 수 있지만, 특정 상품의 구매현황은 여러 테이블에 분산되어 있어 검색이 더 까다롭습니다. 반대로, 상품 차원에 따라 표를 나누면 이 상품의 구매현황을 쉽게 알 수 있지만, 구매자의 거래기록을 찾는 것이 더 번거롭습니다.

일반적인 해결 방법은 다음과 같습니다.

a.미터를 스캔하여 해결하세요. 이 방법은 기본적으로 불가능하고 효율성이 너무 낮습니다.
b. 사용자 차원에 따라 테이블로 구분된 데이터와 제품 차원에 따라 테이블로 구분된 두 개의 데이터를 기록합니다.
c. 검색엔진을 통해 해결하되 실시간 요구사항이 매우 높을 경우 실시간 검색과 관련이 있어야 합니다.

2. 공동 질의 관련 문제

연합 쿼리는 관련 테이블이 동일한 데이터베이스에 없을 수 있으므로 기본적으로 불가능합니다.

3. 데이터베이스 간 거래 방지

트랜잭션에서 db0의 테이블을 수정하는 동안 db1의 테이블을 수정하지 마세요. 하나는 작업이 더 복잡해지고 효율성이 어느 정도 영향을 받는다는 것입니다.

4. 같은 DB 서버에 같은 데이터를 넣어보세요

예를 들어 A 판매자의 상품과 거래정보가 db0에 저장되어 있는데, db1이 다운되면 A 판매자의 관련 사항은 정상적으로 이용 가능합니다. 이는 데이터베이스의 데이터가 다른 데이터베이스의 데이터에 의존하는 것을 방지하는 것을 의미합니다.

하나의 마스터, 다양한 백업

실제 응용에서는 쓰기보다 읽기가 훨씬 더 큰 경우가 많습니다. MySQL은 읽기-쓰기 분리 메커니즘을 제공합니다. 모든 쓰기 작업은 마스터와 슬레이브 시스템에서 수행될 수 있습니다. 마스터는 여러 슬레이브를 가질 수 있습니다. 하나의 슬레이브를 연결하면 DB 클러스터의 QPS를 효과적으로 향상시킬 수 있습니다.

모든 쓰기 작업은 먼저 마스터에서 수행된 다음 슬레이브에 동기화됩니다. 따라서 마스터에서 슬레이브 시스템으로의 동기화에는 특정 지연이 있으며, 시스템 사용량이 많으면 지연 문제가 더 커집니다. 심각합니다. 슬레이브 머신의 수가 증가하면 이 문제도 더욱 심각해집니다.

또한 마스터가 클러스터의 병목 현상임을 알 수 있습니다. 쓰기 작업이 너무 많으면 마스터가 끊기면 전체 클러스터가 작동하지 않게 됩니다. 제대로.

그래서 1. 읽기 압력이 매우 높을 경우 분수 솔루션을 위해 슬레이브 머신 추가를 고려할 수 있습니다. 그러나 슬레이브 머신 수가 특정 수에 도달하면 하위 라이브러리를 고려해야 합니다. 2. 쓰기 압력이 매우 높을 경우 데이터베이스 하위 작업을 수행해야 합니다.

MySQL을 데이터베이스와 테이블로 나누어야 하는 이유는 무엇인가요?

MySQL을 사용하다 보면 데이터의 양이 많으면 데이터베이스와 테이블을 분할해야 하는 문제가 즉시 발생한다고 할 수 있습니다.
질문이 있습니다. 왜 데이터베이스와 테이블을 나누어야 합니까? MySQL은 큰 테이블을 처리할 수 없나요?
실제로 제가 경험한 프로젝트에서는 단일 테이블의 물리적 파일 크기가 80G가 넘고, 단일 테이블의 레코드 수가 5억 개가 넘는데 이 테이블은
매우 유용한 테이블입니다: 친구 관계 테이블입니다.

그러나 이 방법은 최선의 방법은 아니라고 할 수 있습니다. 왜냐하면 Ext3 파일 시스템과 같은 파일 시스템 역시 대용량 파일을 처리하는데 많은 문제가 있기 때문입니다.
이 레벨은 xfs 파일 시스템으로 대체할 수 있지만, 단일 MySQL 테이블이 너무 클 경우 해결하기 어려운 문제가 있습니다: 테이블 구조 조정과 관련된 작업 기반
따라서 주요 프로젝트에서는 사용 중에 하위 데이터베이스 및 하위 테이블의 적용을 감독합니다.

Innodb 자체에서는 데이터 파일의 Btree에 리프 노드 잠금과 하위 노드 잠금 두 가지 잠금만 있습니다. 페이지 분할이 발생하거나 페이지가 추가될 때를 상상할 수 있습니다.
새 잎으로 인해 데이터를 테이블에 쓸 수 없게 됩니다.
따라서 하위 데이터베이스와 하위 테이블을 선택하는 것이 더 좋습니다.

그렇다면 하위 데이터베이스와 테이블은 몇 개가 적절한가요?
단일 테이블에서 1천만 개의 레코드를 테스트한 후 쓰기 및 읽기 성능이 비교적 좋습니다. 이런 방식으로 일부 버퍼를 남겨두면 단일 테이블의 모든 데이터 글꼴이
에 유지됩니다. 레코드 수는 800만 개 이하, 문자가 포함된 단일 테이블 수는 500만 개 이하로 유지됩니다.

사용자 업무 등 데이터베이스 100개, 테이블 100개에 따라 계획하는 경우:
500만*100*100 = 500,000,000 = 5000억 개의 레코드

이제는 숫자를 염두에 두었으니 사업에 맞춰 계획을 세우기가 비교적 쉽습니다.