MyBatis가 Mysql 데이터베이스 하위 데이터베이스 및 테이블 하위 테이블을 구현하는 방법에 대한 자세한 예

이 글은 주로 MyBatis의 Mysql 데이터베이스 하위 데이터베이스 및 하위 테이블 구현에 대한 작업 및 요약을 소개합니다. 필요한 친구들은 이를 참고할 수 있습니다.

머리말

데이터베이스로, 테이블로 데이터베이스, 사용자로서 시간이 지남에 따라 언젠가는 데이터의 양이 감당할 수 없게 될 것입니다. 이때 하나의 테이블에 있는 데이터가 수천만 개가 넘습니다. 쿼리하든 수정하든 작업에 많은 시간이 소요됩니다. 이때 데이터베이스 분할 작업이 필요합니다.

MyBatis에서 하위 테이블을 구현하는 가장 간단한 단계

글 제목이 이렇게 작성되었으므로 실제적인 정보로 바로 넘어가는 것이 더 실용적입니다. 가장 간단한 하위 테이블을 구현합니다.

1. 시뮬레이션된 사용자 테이블의 데이터 양은 수천만 개를 초과합니다(실제로는 그럴 가능성이 낮음)

2. 사용자 테이블의 원래 이름은 user_tab이며, 이를 다음과 같이 분할합니다. user_tab_0 및 user_tab_1(실제로는 그렇게 임의의 이름이 아닐 수도 있음)을 사용하여 원래 수천만 개의 데이터를 2개의 테이블로 분리할 수 있습니다. 200만. user_tab，我们切分为user_tab_0和user_tab_1（实际也可能不是这么随意的名字），这样就能把原来千万的数据分离成两个百万的数据量的两张表了。

3、如何操作这两张表呢？我们利用userId也就是用户的唯一标识进行区分。

4、userId%2 == 0的用户操作表user_tab_0，同理userId%2 == 1的用户操作表user_tab_1

3. 이 두 테이블을 어떻게 운영하나요? 이를 구분하기 위해 사용자의 고유 식별자인 userId를 사용합니다.

4. userId%2 == 0의 사용자 작업 테이블 user_tab_0은 사용자 작업 테이블 userId%2 == 1과 동일합니다. >.code>user_tab_1

5. 그러면 MyBatis에서 SQL 문을 어떻게 구현할까요? 다음은 user

<select id="getUser" parameterType="java.util.Map" resultType="UserDO"> 
    SELECT userId, name 
    FROM user_tab_#{tabIndex} 
    WHERE userId = #{userId} 
</select>

를 쿼리하는 SQL 문의 예입니다. 여기서 tabIndex와 userId라는 두 개의 매개 변수를 전달합니다. tabIndex는 작업 테이블의 표시 값(0 또는 1)이므로 필요한 경우 userId가 5인 사용자를 쿼리하면 최종 SQL 문은 다음과 같습니다.

SELECT userId, name 
FROM user_tab_1 
WHERE userId = 5

여기서 다른 중복 DAO 서비스 및 구현을 더 이상 보여주지 않겠습니다. 똑똑하신 분이라면 아실 것입니다.

위는 하위 테이블의 요구 사항을 충족하기 위해 추가 프레임워크나 플러그인이 필요하지 않은 가장 간단한 구현입니다.

이상은 기본적으로 모든 구현 내용입니다. 이제 본격적으로 이별에 대한 이야기를 시작하겠습니다. 설렘을 지켜보고 계신 분들은 기본적으로 떠나셔도 됩니다.

다음과 같은 각도에서 이야기해보겠습니다. 가능한 한 가장 간단한 언어로 표현했습니다.

분리 방법

분할에는 크게 수평분할과 수직분할의 두 가지 방법이 있습니다.

1. 수평 분할

간단히 말하면, 테이블을 여러 개의 동일한 테이블로 분리한 후 테이블 이름이 다릅니다. 위의 가장 간단한 예와 같습니다.

이러한 세분화는 일부 저장된 레코드 테이블과 같이 테이블의 데이터 양이 너무 많아 작업 시간이 느려지는 상황에 적합합니다.

2. 수직적 분할

서로 다른 비즈니스 모듈을 서로 다른 데이터베이스로 나눕니다. 이러한 비즈니스 모듈은 직접 0으로 결합되는 것이 좋습니다(간단히 말하면 서로 관련이 없습니다).

이는 일반적으로 데이터의 양이 많고 비즈니스 시나리오가 분산되어 있으며 둘 사이에 논리적 관계가 없는 상황에 주로 적합합니다.

분리 전략

구체적인 전략은 다양하며, 자신만의 전략을 설계할 수도 있습니다. 일반적인 전략은 다음과 같습니다. 단지 나열했을 뿐, 자세히 설명하지는 않습니다.

1. "%" 모듈로는 위의 예에서 구현되었으며 가장 간단한 모듈이기도 합니다.

2. MD5 해시

3. 날짜 및 시간(한 달에 한 테이블씩 다른 날짜에 따라 테이블 구분, 이번 달에는 이 테이블을 운영하고 다음 달에는 다음 테이블을 운영)

5. 범위 (사용자 1-10000이 첫 번째 테이블을 조작하고, 사용자 10001-20000이 두 번째 테이블을 조작함)

분리 문제

마지막 포인트와 발생한 문제에 대해 이야기해 보겠습니다.

데이터베이스는 절대 혼자서 나눌 수 있는 것이 아닙니다. (사람들은 더 감정적입니다. 어떻게 헤어질 수 있습니까?)

진심하게 말해서, 이별이 야기할 뿐인 다음과 같은 문제들을 나열했습니다.

1. 추가 시 기본 키의 고유성 문제; 여러 테이블을 분리한 후 원래 자체 증가 기본 키는 고유하지 않으므로 자체 증가할 방법이 없으며 문제가 발생합니다. 별도 유지 관리 등의 솔루션 현재 기본 키를 저장하기 위해 특별히 기본 키 테이블을 사용하거나 다른 미들웨어를 사용합니다.

2. 새로운 데이터를 추가할 때 효율성 문제는 큰 문제가 아니지만, 새로운 데이터를 추가하면 계산량이 확실히 늘어나게 되기 때문에 이 문제는 무시할 수 있습니다.

3. 쿼리로 인해 발생하는 페이징 문제. 여러 테이블로 분리된 후에는 페이징 쿼리가 매우 어려워집니다. 즉, 서로 다른 분리에는 서로 다른 솔루션이 필요하다는 점도 고려합니다.

4. 마찬가지로 관련 쿼리도 원래는 하나의 테이블을 다른 테이블과 연결하거나 다른 테이블을 하나의 테이블과 연결하는 것이 매우 간단했지만 이제는 분리된 후에는 어렵습니다.

5. 트랜잭션 문제, 트랜잭션으로 원래 작업을 완료하려면 여러 테이블에서 분산 트랜잭션을 사용해야 합니다. 원래 트랜잭션은 하나의 테이블만 잠갔기 때문에 이제는 여러 테이블을 잠가야 할 수도 있습니다.

6. 확장성 문제. 일부 샤딩 전략은 데이터 확장성이 좋지 않습니다. 나중에 더 많은 데이터가 들어오면 확장할 수 있는 새 테이블을 만들 수 있나요? 🎜

분리의 원칙

다음은 실제 근거 없이 주로 인터넷상의 참고자료를 바탕으로 몇 가지 분리의 원칙을 요약한 것입니다. 자료가 너무 많아서) 실사하러 가세요) 궁금하신 점 있으시면 지적해주세요.

1. 나눌 수 없다면 나누지 마세요

2. 최소한으로 나눌 수 있다면 최대한 나누지 마세요

3. 너무 중복되고 관련성이 없습니다

4. 분산 트랜잭션은 주로 너무 어렵고 어떻게 해야 할지 모르겠습니다.

5. 하나의 테이블에 수천만 개의 레코드가 분리되지 않습니다

6. , 나중에 분리할 시간을 갖게 될 것입니다

7. 분리를 달성하는 방법을 확장하고, 결합하고, 신중하게 고려하세요

마지막으로 분리에 대해 이야기해 보겠습니다. 가장 인기 있는 DAO 프레임워크는 MyBatis이며, 다른 프레임워크도 많이 있습니다. 분리는 주로 다음과 같은 방식으로 구현됩니다. 1. 위의 예와 마찬가지로 네이티브 구현에는 다른 것이 필요하지 않습니다. 네이티브 프레임워크를 사용하여 구현을 직접 제어하세요.

장점은 제어가 쉽고 주도권을 갖는다는 것입니다.

단점은 코드가 많고, 명확히 알아야 하고, 수정이 불편하고, 복잡한 분할을 지원하지 않는다는 점입니다. 예를 들어 분할 후 몇 가지 페이징 쿼리를 수행해야 할 뿐만 아니라, 위에서 언급한 주요 핵심 문제.

2. 플러그인 구현, 프레임워크 자체에서 개발한 일부 플러그인을 사용하여 이러한 플러그인을 구현한 다음 플러그인을 사용하여 데이터베이스에 액세스하여 직접 분리를 달성합니다.

장점은 코드가 적고 구현이 간단하며 확장성이 좋다는 것입니다.

단점은 제어가 어렵고, 분리 방법이 제한적이며, 문제 해결이 어렵다는 것입니다. 특히 성숙한 플러그인이 발견되지 않았습니다.

3. 미들웨어 구현. 일부 데이터베이스 액세스 미들웨어를 사용하여 데이터베이스에 액세스하기 전에 일부 작업을 수행하여 SQL에서 해당 변경을 수행하여 분리를 달성합니다.

장점은 결합이 적고 확장성이 좋으며 분산 트랜잭션 문제를 해결할 수 있다는 것입니다.

확실히: 구현이 더 복잡하고 미들웨어 학습이 필요하며 비용이 많이 듭니다. 실패할 경우를 대비해 유지 관리도 큰 문제입니다. .

간단히 각 방법마다 장단점이 있지만 비용을 고려하면 첫 번째 방법은 비용이 거의 0에 가깝고 위에 예시와 같이 시작할 수 있고 제어하기도 더 쉽고 현재 제가 가지고 있는 데이터는 처리가 아직 해당 수준에 도달하지 않았으므로 모든 곳에 분리 지점이 있으므로 첫 번째 옵션을 선택합니다. 또한 추천합니다. 더 사용하기 쉬운 플러그인이나 미들웨어를 찾으셨다면 댓글로 추천해 주세요.

요약

실제 프로젝트에서는 사용자 계정 레코드가 너무 많고, 더 많은 계정 레코드가 수정이나 삭제 없이 추가만 되었고, 쿼리도 몇 개밖에 없어서 분리해야만 했습니다. 나는 가장 간단한 분리 방법을 선택하고 가장 간단한 전략을 선택했습니다. 위의 원칙, 전략, 방법 및 문제 요약이 귀하에게 도움이 되고 참고 자료가 되기를 바랍니다. 궁금한 점이 있으시면 메시지를 남겨주시면 시간 내에 답변해 드리겠습니다. 또한 Script House 웹사이트를 지원해 주시는 모든 분들께 감사의 말씀을 전하고 싶습니다!

위 내용은 MyBatis가 Mysql 데이터베이스 하위 데이터베이스 및 테이블 하위 테이블을 구현하는 방법에 대한 자세한 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!