오늘 드디어 MySQL 서브 데이터베이스와 서브 테이블을 알아냈으니 인터뷰에서 자랑할 수 있겠네요!

머리말

회사에서는 최근 서비스 분리 및 데이터 세분화에 힘쓰고 있습니다. 단일 패키지 테이블에 담긴 데이터의 양이 정말 너무 많고, 아직도 하루 60W씩 증가하고 있기 때문입니다.

이전에도 서브데이터베이스와 데이터베이스의 서브테이블에 대해 배워본 적이 있고 블로그 글도 몇개 읽어봤지만 막연한 개념만 알고 있었는데 지금 생각해보면 모든게 막연하네요.

오후 내내 데이터베이스 하위 테이블을 읽고 많은 기사를 읽었습니다. 이제 요약하겠습니다.

1부: 실제 웹사이트 개발 과정에서 직면한 문제.

2부: 다양한 분할 방법, 수직과 수평의 차이점 및 적용 가능한 측면은 무엇입니까?

3부: 현재 시장에 나와 있는 일부 오픈 소스 제품 및 기술과 그 장점과 단점은 무엇입니까?

4부: 아마도 가장 중요한 것은 데이터베이스를 수평으로 분할하는 것이 권장되지 않는 이유입니다! ? 이를 통해 계획 초기 단계에서 신중하게 처리하고 분할로 인해 발생하는 문제를 피할 수 있습니다.

용어 설명

라이브러리: 데이터베이스; 테이블: 테이블; 하위 데이터베이스 및 하위 테이블: 샤딩

데이터베이스 아키텍처의 진화 처음에는 단일 머신 데이터베이스만 사용하다가 직면했습니다. 점점 더 많은 요청이 발생하고 있습니다. 데이터베이스의 쓰기 작업과 읽기 작업을 분리하고 여러 슬레이브 데이터베이스 복사본(Slaver 복제)을 사용하여 읽기를 담당하며 마스터 데이터베이스(마스터)를 사용하여 쓰기를 담당합니다. 데이터 일관성을 유지하기 위해 마스터 데이터베이스에서 데이터를 동기식으로 가져옵니다. 구조적으로는 데이터베이스 마스터-슬레이브 동기화입니다. 슬레이브 라이브러리는 수평으로 확장할 수 있으므로 더 많은 읽기 요청이 문제가 되지 않습니다.

하지만 사용자 레벨이 높아지고 쓰기 요청이 점점 더 많아지면 어떻게 해야 할까요? 데이터는 일관되어야 하고 쓰기 작업에는 두 마스터 간의 동기화가 필요하기 때문에 마스터를 추가해도 문제가 해결되지 않습니다. 이는 복제와 동일하고 더 복잡합니다.

이때 쓰기 작업을 분할하려면 샤딩을 사용해야 합니다.

데이터베이스 및 테이블을 샤딩하기 전의 문제

모든 문제는 너무 크거나 작습니다. 여기서 직면하는 문제는 데이터의 양이 너무 크다는 것입니다.

사용자 요청량이 너무 많습니다

단일 서버 TPS, 메모리, IO가 제한되어 있기 때문입니다.

해결책: 요청을 여러 서버에 분산합니다. 실제로 사용자 요청과 SQL 쿼리 실행은 모두 리소스를 요청한다는 점에서 본질적으로 동일하지만 사용자 요청은 게이트웨이, 라우팅, http 서버 등을 통과합니다.

단일 데이터베이스가 너무 큽니다.

단일 데이터베이스의 처리 용량이 제한되어 있습니다.

단일 데이터베이스가 있는 서버의 디스크 공간이 부족합니다.

단일 데이터베이스 작업의 IO 병목 현상. 해결 방법: 더 작은 라이브러리로 분할

단일 테이블이 너무 큰 경우

CRUD가 문제입니다.

색인 확장, 쿼리 시간 초과

해결 방법: 더 작은 데이터 세트를 사용하여 여러 테이블로 분할합니다.

데이터베이스와 테이블을 샤딩하는 방법

은 일반적으로 수직 분할과 수평 분할이 있는데 이는 결과 집합으로 설명되는 분할 방법으로 물리적인 공간 분할입니다.

우리는 직면한 문제에서 시작하여 해결합니다.

설명:

첫째, 사용자 요청 수가 너무 많아서 이를 처리하기 위해 머신을 쌓아둡니다(이 기사의 초점은 아닙니다)

그리고 이때 단일 라이브러리가 너무 큽니다. 테이블이 너무 많아서 데이터가 너무 많은지, 아니면 단일 데이터베이스 때문인지 확인하려면

테이블이 많고 데이터가 많은 경우 수직 분할을 사용하여 업무에 따라 서로 다른 라이브러리로 나눕니다.
단일 테이블의 데이터 양이 너무 많으면 수평 분할을 사용해야 합니다. 즉, 테이블 데이터를 특정 규칙에 따라 여러 테이블로 나누거나 여러 라이브러리의 여러 테이블로 나누는 것입니다.

. 왜냐하면 수직적 분할은 우리가 실제 문제를 다루는 방식과 더 간단하고 일관성이 있기 때문입니다.

수직 분할

수직 테이블 분할

은 열 필드를 기반으로 하는 "큰 테이블을 작은 테이블로 분할"이기도 합니다. 일반적으로 테이블에는 많은 필드가 있으며 일반적으로 사용되지 않는 필드, 대용량 데이터, 긴 필드(예: 텍스트 유형 필드)는 "확장 테이블"로 분할됩니다. 일반적으로 수백 개의 열이 있는 대규모 테이블을 목표로 하며 쿼리 시 너무 많은 데이터로 인해 발생하는 "페이지 간" 문제도 방지합니다.

수직형 하위 라이브러리

수직형 하위 라이브러리는 사용자용 데이터베이스, 제품용 데이터베이스, 주문용 데이터베이스 등 시스템 내에서 서로 다른 비즈니스를 분할하는 것을 목표로 합니다. 분할한 후에는 하나의 서버가 아닌 여러 서버에 배치해야 합니다. 왜? 쇼핑 웹사이트가 외부 세계에 서비스를 제공하고 사용자, 제품, 주문 등에 대한 CRUD를 가지고 있다고 가정해 보겠습니다. 분할하기 전에는 모든 것이 단일 라이브러리에 포함되어 데이터베이스가 단일 데이터베이스의 처리 능력이 병목 현상을 일으켰습니다. 데이터베이스를 수직으로 분할한 후에도 여전히 데이터베이스 서버에 배치하면 사용자 수가 증가함에 따라 단일 데이터베이스의 처리 용량에 병목 현상이 발생하여 단일 서버의 디스크 공간, 메모리, tps 등이 매우 부족합니다. 따라서 위의 문제를 해결하고 향후 단일 시스템 리소스 문제에 직면하지 않도록 여러 서버로 분할해야 합니다. 单库处理能力成为瓶颈。按垂直分库后，如果还是放在一个数据库服务器上， 随着用户量增大，这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧。所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题。

数据库业务层面的拆分，和服务的治理，降级机制类似，也能对不同业务的数据分别的进行管理，维护，监控，扩展等。数据库往往最容易成为应用系统的瓶颈，而数据库本身属于有状态的，相对于Web和应用服务器来讲，是比较难实现横向扩展

데이터베이스 비즈니스 수준 및 서비스 분할 rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(239 , 112, 96);">거버넌스 , 다운그레이드 메커니즘은 유사하며, 다양한 비즈니스의 데이터를 별도로 관리, 유지, 모니터링, 확장 등을 할 수도 있습니다. 데이터베이스는 종종 응용 프로그램 시스템의 병목 현상이 될 가능성이 가장 높으며 데이터베이스 자체는 color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(239, 112, 96);" >Stateful은 웹 및 애플리케이션 서버보다 구현하기가 더 어렵습니다수평 확장. 데이터베이스 연결 리소스는 소중하며 단일 시스템 처리 기능은 제한되어 있습니다. 동시성이 높은 시나리오에서는 수직 하위 데이터베이스가 IO 병목 현상, 연결 수 및 단일 시스템 하드웨어 리소스를 어느 정도 돌파할 수 있습니다. 🎜

수평 분할

수평 하위 테이블

방대한 양의 데이터(예: 주문 테이블)가 포함된 단일 테이블의 경우 특정 규칙에 따라(RANGE,HASH取模等），切分到多张表里面去。但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈. 권장하지 않습니다.

수평 하위- 데이터베이스 및 하위 테이블

은 단일 테이블의 데이터가 여러 서버로 분할됩니다. 각 서버에는 해당 데이터베이스와 테이블이 있지만 테이블의 데이터 수집은 다릅니다. 수평 샤딩은 성능 병목 현상과 부담을 효과적으로 완화할 수 있습니다. IO의 병목 현상, 연결 수, 하드웨어 리소스 등을 돌파합니다.

수평 샤딩 규칙

• RANGE

  0에서 10000까지의 테이블 1개, 10001에서 10001까지의 테이블 1개 20000;

• HASH 추출 모델

  쇼핑몰 시스템은 일반적으로 사용자와 주문을 기본 테이블로 사용하고 관련 테이블을 보조 테이블로 사용하므로 데이터베이스 간 거래와 같은 문제가 발생하지 않습니다. 사용자 ID를 가져온 다음 해시를 가져와 다른 데이터베이스에 배포합니다.

  지리적 지역
• 예를 들어 Qiniu Cloud는 6개월 전의 데이터를 잘라내야 합니다. 1년 전이라도 다른 테이블에 넣어두면 시간이 지날수록 이 테이블의 데이터가 쿼리될 확률이 작아지므로 "핫 데이터"와 함께 넣을 필요가 없습니다. 핫 데이터와 콜드 데이터 분리"
  .

하위 데이터베이스 및 테이블 이후에 발생하는 문제

트랜잭션 지원

하위 데이터베이스 및 테이블 이후에는 분산 트랜잭션. 分布式事务了。

如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

多库结果集合并（group by，order by）

类似于group by，order by

데이터베이스 자체의 분산 트랜잭션 관리 기능에 의존하여 트랜잭션을 실행하는 경우 높은 성능 비용을 지불하게 됩니다. 애플리케이션이 이를 제어하는 ​​데 도움을 주면 프로그램 로직에서 트랜잭션을 형성하므로 프로그래밍 부담이 발생합니다.

여러 데이터베이스 결과 세트 병합(그룹화, 정렬)

🎜 Group by, order by이러한 그룹화 및 정렬 문은 사용할 수 없습니다🎜🎜Cross-database Join🎜🎜데이터베이스가 테이블로 분할된 후에는 테이블 간의 연결 작업이 제한되며, 서로 다른 위치에 있는 테이블을 조인할 수 없습니다. 하위 데이터베이스의 테이블은 서로 다른 하위 테이블 단위로 조인될 수 없습니다. 따라서 하나의 쿼리로 완료할 수 있는 비즈니스를 완료하려면 여러 쿼리가 필요할 수 있습니다. 대략적인 해결책: 전역 테이블: 기본 데이터, 모든 라이브러리에 복사본이 있습니다. 필드 중복성: 이러한 방식으로 일부 필드는 조인으로 쿼리할 필요가 없습니다. 시스템 레이어 어셈블리: 모든 것을 개별적으로 쿼리한 다음 이를 어셈블하는 것이 더 복잡합니다. 🎜

하위 데이터베이스 및 하위 테이블 솔루션 제품

시중에는 상대적으로 많은 하위 데이터베이스 및 하위 테이블 미들웨어가 있으며, 그중 프록시 기반 미들웨어에는 MySQL 프록시 및 Amoeba는 Hibernate 프레임워크를 기반으로 Hibernate 샤드, jdbc Dangdangsharding-jdbc, Mogujie와 유사한 mybatis 기반 Maven 플러그인 TSharding, spring의 ibatis 템플릿 클래스의 Cobar 클라이언트. MySQL Proxy和Amoeba， 基于Hibernate框架的是Hibernate Shards，基于jdbc的有当当sharding-jdbc， 基于mybatis的类似maven插件式的有蘑菇街的蘑菇街TSharding， 通过重写spring的ibatis template类的Cobar Client。

还有一些大公司的开源产品：

---

我是程序员青戈，一个爱生活、爱分享的90后程序员。

本期关于Mysql分库分表的介绍和解决方案介绍到这里，希望能帮助到大家，后续更多Java面试类的文章请持续关注公众号Java学习指南일부 대기업의 오픈 소스 제품도 있습니다:

🎜🎜나는프로그래머 Qingge, 삶과 공유를 사랑하는 90년대 이후 프로그래머. 🎜

이 문제에서는 Mysql 하위 데이터베이스 및 하위 테이블이 소개됩니다. 여기에 솔루션이 소개되어 있습니다. 앞으로 더 많은 Java 인터뷰 기사를 보려면 공식 계정에 계속 관심을 가져주시기 바랍니다.Java 학습 가이드🎜. 🎜🎜

위 내용은 오늘 드디어 MySQL 서브 데이터베이스와 서브 테이블을 알아냈으니 인터뷰에서 자랑할 수 있겠네요!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!