mysql에서 데이터 분할을 구현하는 방법-MySQL 튜토리얼-php.cn

Mysql 데이터 분할 구현 방법: 1. 데이터의 수직 분할 사용 3. MySQL 프록시를 사용하여 데이터 분할 및 통합 달성 5. ,사용 HiveDB는 데이터 분할 및 통합을 달성합니다. ㅋㅋㅋ

넣으려면 간단히 말해서, 단일 장치의 부하를 분산시키는 효과를 얻기 위해 특정 특정 조건을 통해 동일한 데이터베이스에 저장된 데이터를 여러 데이터베이스(호스트)에 분산시키는 것을 의미합니다. 데이터 슬라이싱은 또한 시스템의 전반적인 가용성을 향상시킬 수 있습니다. 단일 장치가 충돌한 후 전체 데이터가 아닌 전체 데이터의 특정 부분만 사용할 수 없기 때문입니다. mysql에서 데이터 분할을 구현하는 방법

데이터 샤딩(Sharding)은 샤딩 규칙의 유형에 따라 두 가지 샤딩 모드로 나눌 수 있습니다. 하나는 서로 다른 테이블(또는 스키마)에 따라 서로 다른 데이터베이스(호스트)로 분할하는 것입니다. 이 분할은 데이터의 수직(수직) 분할이라고 할 수 있으며, 다른 하나는 테이블의 데이터에 따라 분할하는 것입니다. 논리적 관계에서 동일한 테이블의 데이터는 특정 조건에 따라 여러 데이터베이스(호스트)로 분할됩니다. 이러한 종류의 분할을 데이터의 수평(수평) 분할이라고 합니다.

수직 분할의 가장 큰 특징은 규칙이 간단하고 구현이 더 편리하다는 것입니다. 특히 다양한 비즈니스 간의 결합도가 매우 낮고 상호 영향이 적으며 비즈니스 로직이 매우 명확한 시스템에 적합합니다. 이러한 종류의 시스템에서는 다양한 비즈니스 모듈에서 사용되는 테이블을 다양한 데이터베이스로 쉽게 분할할 수 있습니다. 다른 테이블에 따라 분할하면 애플리케이션에 미치는 영향이 줄어들고 분할 규칙이 더 간단하고 명확해집니다. 수평 분할은 수직 분할보다 약간 더 복잡합니다. 동일한 테이블의 서로 다른 데이터를 서로 다른 데이터베이스로 분할해야 하기 때문에 애플리케이션의 경우 분할 규칙 자체가 테이블 이름을 기준으로 분할하는 것보다 더 복잡하며 후속 데이터 유지 관리도 더 복잡합니다. 특정(또는 일부) 테이블의 데이터 볼륨 및 액세스 볼륨이 유난히 크고, 수직 슬라이싱을 수행하여 독립된 장치에 배치한 후에도 여전히 성능 요구 사항을 충족하지 못하는 경우 수직 샤딩과 수평 슬라이싱을 결합하여 수행해야 합니다. , 먼저 수직으로 분할한 다음 수평으로 분할하면 이 매우 큰 테이블의 성능 문제를 해결할 수 있습니다. 다음은 수직, 수평, 결합 분할의 세 가지 데이터 분할 방법의 아키텍처 구현과 분할된 데이터의 통합에 대한 해당 분석입니다.
데이터의 수직 분할

먼저 데이터의 수직 분할이 어떻게 분할되는지 살펴보겠습니다. 데이터의 수직 분할은 수직 분할이라고도 합니다. 데이터베이스가 하나씩 많은 "데이터 블록"(테이블)으로 구성되어 있다고 생각하십시오. 이러한 "데이터 블록"을 수직으로 자른 다음 여러 데이터베이스 호스트에 분산시킵니다. 이러한 슬라이싱 방식이 수직(세로) 데이터 슬라이싱이다.

잘 설계된 아키텍처를 갖춘 애플리케이션 시스템의 전체 기능은 많은 기능 모듈로 구성되어야 하며, 각 기능 모듈에 필요한 데이터는 데이터베이스의 하나 이상의 테이블에 해당합니다. 아키텍처 설계에서는 각 기능 모듈 간의 상호 작용 지점이 더 통합되고 더 적을수록 시스템의 결합 정도가 낮아지고 시스템의 각 모듈의 유지 관리 및 확장성이 향상됩니다. 이러한 시스템을 사용하면 데이터를 수직적으로 분할하는 것이 더 쉬워집니다.

기능 모듈이 명확하고 결합도가 낮을수록 수직 데이터 분할 규칙을 정의하기가 더 쉽습니다. 데이터는 기능 모듈을 기반으로 분할될 수 있습니다. 서로 다른 기능 모듈의 데이터는 서로 다른 데이터베이스 호스트에 저장되며, 시스템 아키텍처도 매우 명확합니다.

물론, 시스템이 모든 기능 모듈이 사용하는 테이블을 완전히 독립적으로 만드는 것은 어렵고, 서로의 테이블에 전혀 접근할 필요가 없거나 두 모듈의 테이블을 조인해야 합니다. 이 경우 실제 적용 시나리오를 바탕으로 평가와 절충이 이루어져야 합니다. 응용 프로그램을 수용하고 동일한 데이터베이스에 조인해야 하는 테이블의 관련 모듈을 저장할지 또는 응용 프로그램이 더 많은 작업을 수행하도록 할 것인지 결정합니다. 즉, 모듈 인터페이스를 통해 완전히 다른 데이터베이스에서 데이터를 얻은 다음 다음에서 조인 작업을 완료합니다. 프로그램.

일반적으로 로드가 비교적 적고 테이블 상관 관계가 매우 빈번한 시스템인 경우 데이터베이스는 여러 관련 모듈을 포기하고 병합하여 애플리케이션 작업을 줄일 수 있으며, 이는 실현 가능한 솔루션입니다. .

물론, 데이터베이스의 양보를 통해 여러 모듈이 중앙에서 데이터 소스를 공유하도록 허용하는 것은 실제로 각 모듈 아키텍처의 결합 증가 개발을 간접적으로 묵인하여 향후 아키텍처를 악화시킬 수 있습니다. 특히 특정 개발 단계에 도달하고 데이터베이스가 이러한 테이블로 인한 압력을 견딜 수 없어 다시 분할에 직면해야 하는 경우 아키텍처 변환 비용은 분할을 사용한 초기 아키텍처 설계보다 훨씬 클 수 있습니다.

그래서 데이터베이스를 수직적으로 분할할 경우, 어떻게 분할할지, 어느 정도까지 분할할지가 어려운 문제입니다. 실제 적용 시나리오에서 모든 측면의 비용과 이점의 균형을 맞춰야 진정으로 적합한 분할 계획을 분석할 수 있습니다.

예를 들어, 이 글에서 사용된 예시 시스템의 예시 데이터베이스를 간략하게 분석한 후, 수직 분할을 수행하기 위한 간단한 분할 규칙을 설계합니다.

시스템 기능은 기본적으로 다음 표에 해당하는 사용자, 그룹 메시지, 사진 앨범 및 이벤트의 4가지 기능 모듈로 나눌 수 있습니다.

사용자 모듈 테이블: user, user_profile, user_group, user_photo_album
group 그룹 토론 테이블: groups, group_message, group_message_content, top_message
앨범 관련 테이블: photo, photo_album, photo_album_relation, photo_comment
이벤트 정보 테이블: event

얼핏 보면 모듈이 분리될 수 없습니다. 나머지 모듈은 독립적으로 존재하며, 모듈간에는 분리가 불가능한가요?

물론 그렇지 않습니다. 좀 더 심층적으로 분석해 보면 각 모듈에서 사용하는 테이블이 서로 관련되어 있지만 그 관계는 비교적 명확하고 단순하다는 것을 알 수 있습니다.

그룹 토론 모듈과 사용자 모듈은 주로 사용자 또는 그룹 관계를 통해 관련됩니다. 일반적으로 사용자의 id나 nick_name을 통해 연관이 이루어지며, 모듈 간 인터페이스를 통해 구현하면 큰 문제가 발생하지 않습니다.

사진 앨범 모듈은 사용자 모듈과만 사용자 연결을 갖습니다. 이 두 모듈 간의 연결은 기본적으로 사용자 ID와 관련된 콘텐츠일 뿐이며 이는 간단하고 명확하며 인터페이스도 명확합니다.

이벤트 모듈은 각 모듈과 관련될 수 있지만 각 모듈에 있는 개체의 ID 정보에만 중점을 두므로 분할하기도 쉽습니다.

그래서 첫 번째 단계는 기능 모듈과 관련된 테이블에 따라 데이터베이스를 수직으로 분할하는 것입니다. 각 모듈에 포함된 테이블은 별도의 데이터베이스로 구분됩니다. 모듈 간의 테이블 연결은 모두 응용 프로그램 시스템 측에서 전달됩니다. .처리할 인터페이스입니다. 수직적 데이터 분할의 개략도에서 볼 수 있듯이(그림 1):

이러한 수직적 분할 이후 이전에는 하나의 데이터베이스를 통해서만 제공할 수 있었던 서비스가 4개의 데이터베이스로 분할되어 서비스 제공 능력이 자연스럽게 여러 개 증가했습니다. 타임스.

수직 분할의 장점:

데이터베이스 분할이 간단하고 명확하며 분할 규칙이 명확합니다.
애플리케이션 모듈이 명확하고 명확하며 통합이 쉽습니다. 유지 보수가 편리하고 찾기 쉽습니다.
수직 분할의 단점:

일부 테이블 연결은 데이터베이스 수준에서 완료할 수 없으며 프로그램에서 완료해야 합니다.

매우 자주 액세스하고 반드시 그렇지 않을 수도 있는 대량의 데이터 요구 사항을 충족할 수 있습니다.
세그멘테이션이 특정 수준에 도달하면 확장성이 제한될 수 있습니다. 시스템을 너무 복잡하게 만들고 유지 관리를 어렵게 만듭니다.
수직 분할에서 발생할 수 있는 데이터 분할 및 트랜잭션 문제를 고려할 때 데이터베이스 수준에서 더 나은 솔루션을 찾는 것은 정말 어렵습니다. 실제 응용 사례에서 데이터베이스의 수직 분할은 대부분 응용 시스템의 모듈에 해당합니다. 동일한 모듈의 데이터 소스는 동일한 데이터베이스에 저장되어 모듈 내 데이터 연관 문제를 해결할 수 있습니다. 모듈간 필요한 데이터는 응용 프로그램을 통해 서비스 인터페이스 형태로 서로에게 제공됩니다. 이로 인해 전체 데이터베이스 작업 수가 실제로 증가하지만 전반적인 시스템 확장성과 아키텍처 모듈화 측면에서 유리합니다. 일부 작업의 단일 응답 시간은 약간 증가할 수 있지만 시스템의 전반적인 성능은 어느 정도 향상될 가능성이 높습니다. 확장 병목 현상 문제는 다음 섹션에서 소개할 데이터 수평 분할 아키텍처를 통해서만 해결할 수 있습니다.
데이터의 수평 분할
간단히 말하면, 데이터의 수평 분할은 데이터 행에 따른 분할, 즉 테이블의 일부 행을 하나의 데이터베이스로 분할하고, 다른 행을 다른 데이터베이스로 분할하는 것으로 이해될 수 있습니다. 물론, 각 데이터 행이 어떤 데이터베이스로 분할되었는지 쉽게 결정하려면 항상 특정 규칙에 따라 분할을 수행해야 합니다. 예를 들어 숫자 유형 필드를 기반으로 특정 숫자를 기반으로 모듈로를 취하는 것과 같이 특정 시간 유형 필드의 범위 또는 문자 유형 필드의 해시 값입니다. 전체 시스템의 핵심 테이블 대부분이 특정 필드를 통해 관련될 수 있다면 이 필드는 사용할 수 없는 매우 특별한 경우를 제외하고는 당연히 수평 파티셔닝을 위한 최선의 선택입니다.

일반적으로 현재 매우 인기 있는 Web 2.0 웹사이트처럼 기본적으로 대부분의 데이터는 회원 사용자 정보를 통해 연관될 수 있습니다. 아마도 많은 핵심 테이블은 회원 ID를 통한 데이터의 수평 분할에 매우 적합할 것입니다. 예를 들어, 포럼 커뮤니티 토론 시스템은 포럼 번호에 따라 수평으로 분할될 수 있습니다. 분할 후에는 기본적으로 라이브러리 간에 상호 작용이 없습니다.

예제 시스템의 모든 데이터가 사용자와 연관되어 있는 경우 사용자에 따라 수평으로 분할할 수 있으며, 서로 다른 사용자의 데이터를 서로 다른 데이터베이스로 분할할 수 있습니다. 물론 유일한 차이점은 사용자 모듈의 그룹 테이블은 사용자와 직접적인 관련이 없으므로 그룹을 사용자를 기준으로 수평으로 분할할 수 없다는 점입니다. 이 특수한 경우에는 테이블을 완전히 분리하여 독립된 데이터베이스에 배치할 수 있습니다. 실제로 이 접근 방식은 이전 절에서 소개한 "데이터의 수직 분할" 방식을 활용한 것이라고 할 수 있습니다. 수직 분할과 수평 분할을 동시에 사용하는 이러한 결합 분할 방법은 다음에서 자세히 소개하겠습니다. 부분.

그래서 샘플 데이터베이스의 경우 대부분의 테이블은 사용자 ID를 기준으로 수평으로 분할될 수 있습니다. 다양한 사용자와 관련된 데이터는 분할되어 다양한 데이터베이스에 저장됩니다. 예를 들어, 모든 사용자 ID는 모듈로 2를 사용하여 두 개의 서로 다른 데이터베이스에 저장됩니다. 사용자 ID와 연관된 각 테이블은 다음과 같이 분할될 수 있습니다. 이런 방식으로 기본적으로 모든 사용자 관련 데이터는 동일한 데이터베이스에 존재하며, 상관관계가 필요한 경우에도 구현이 매우 쉽습니다.

수평 분할 다이어그램을 통해 보다 직관적으로 수평 분할 관련 정보를 표시할 수 있습니다(그림 2).

수평 분할의 장점:
- 테이블 연결은 기본적으로 데이터베이스 측에서 완료할 수 있습니다.
- 아니요. 데이터 볼륨이 매우 크고 로드가 높은 일부 테이블에서는 병목 현상이 발생합니다.
- 애플리케이션 측면의 전체 아키텍처는 상대적으로 변경 사항이 적습니다.
- 트랜잭션 처리는 상대적으로 간단합니다. 규칙을 잘 정의할 수 있으면 기본적으로 확장성 제한이 발생하기 어렵습니다.
- 수평 분할의 단점:
분할 규칙이 상대적으로 복잡하고 전체 데이터베이스를 만족할 수 있는 분할 규칙을 추상화하기가 어렵습니다.
- 나중에 데이터를 유지하기가 어렵습니다. 증가하고 수동 위치 지정이 필요합니다. 데이터가 더 어렵습니다.
- 응용 시스템의 각 모듈의 결합 정도가 높아 후속 데이터의 마이그레이션 및 분할에 특정 어려움이 발생할 수 있습니다.
- 수직 및 수평 조인트 분할의 사용
- 앞의 두 섹션에서는 "수직"과 "수평"이라는 두 가지 분할 방법의 구현과 분할 후 아키텍처 정보에 대해 배웠습니다. 두 가지 각 아키텍처에는 고유한 장점과 단점이 있습니다. 그러나 실제 애플리케이션 시나리오에서는 부하가 너무 크지 않고 비즈니스 로직이 상대적으로 단순하여 위의 두 가지 분할 방법 중 하나를 통해 확장성 문제를 해결할 수 있는 시스템을 제외하고 대부분의 다른 시스템은 복잡한 비즈니스 로직과 복잡한 비즈니스 로직은 확장성 문제를 해결할 수 있습니다. 로드가 많은 시스템은 위의 데이터 분할 방법을 통해 더 나은 확장성을 달성할 수 없습니다. 이를 위해서는 위의 두 가지 분할 방법을 조합해야 하며, 다양한 시나리오에서는 서로 다른 분할 방법을 사용합니다.
일반적으로 데이터베이스의 모든 테이블을 특정(또는 소수) 필드를 통해 연결하는 것은 어렵기 때문에 데이터의 수평 분할만으로는 모든 문제를 해결할 수 없습니다. 수직 샤딩은 문제의 일부만 해결할 수 있습니다. 부하가 매우 높은 시스템의 경우 단일 테이블이라도 단일 데이터베이스 호스트를 통해 부하를 감당할 수 없습니다. 두 가지 분할 방법인 "수직"과 "수평" 분할 방법을 결합하여 두 가지의 장점을 최대한 활용하고 단점을 방지해야 합니다.

모든 애플리케이션 시스템의 로드는 단계적으로 증가합니다. 성능 병목 현상이 발생하기 시작하면 대부분의 설계자와 DBA는 먼저 데이터를 수직으로 분할하는 것을 선택합니다. 이는 비용이 가장 낮고 이에 가장 부합하기 때문입니다. 해당 기간 동안 추구된 비율입니다. 그러나 사업이 지속적으로 확장되고 시스템 부하가 지속적으로 증가함에 따라 일정 기간 시스템이 안정된 후에도 수직으로 분할되었던 데이터베이스 클러스터가 다시 과부하되어 성능 병목 현상이 발생할 수 있습니다.

이때 어떻게 선택해야 할까요? 모듈을 다시 세분화해야 할까요, 아니면 다른 솔루션을 찾아야 할까요? 계속해서 처음처럼 모듈을 세분화하고 데이터를 수직적으로 분할한다면 머지않아 지금과 같은 문제에 직면하게 될 수도 있습니다. 더욱이, 모듈이 계속해서 개선됨에 따라 애플리케이션 시스템의 아키텍처는 점점 더 복잡해지고 전체 시스템이 통제 불능 상태에 빠질 가능성이 높습니다.

이때 발생하는 문제를 해결하려면 수평적 데이터 분할을 활용해야 합니다. 또한 수평적 데이터 분할을 사용할 때 이전의 수직적 데이터 분할 결과를 뒤집을 필요가 없으며, 대신 수평 분할의 장점을 활용하여 수직 분할의 단점을 피하고 점점 더 복잡해지는 문제를 해결할 수 있습니다. 시스템.질문입니다. 가로 분할의 단점(규칙을 통일하기 어렵다)도 기존 세로 분할로 해결되어 가로 분할이 쉬워졌습니다.

예제 데이터베이스의 경우 처음에는 데이터가 수직으로 분할되었다고 가정했지만, 비즈니스가 계속 성장함에 따라 데이터베이스 시스템에 병목 현상이 발생하여 데이터베이스 클러스터의 아키텍처를 재구성하기로 결정했습니다. 리팩토링하는 방법? 이전에도 데이터의 수직적 분할이 이루어졌고, 모듈 구조가 명확하고 명확하며, 비즈니스 성장 모멘텀이 점점 더 강해지고 있다는 점을 고려하면, 지금 모듈을 다시 분할하더라도 오래 가지 못할 것입니다. 따라서 우리는 수직 분할을 기반으로 수평 분할을 수행하기로 결정했습니다.

수직 분할을 거친 데이터베이스 클러스터의 각 데이터베이스는 하나의 기능 모듈만 가지며, 각 기능 모듈의 모든 테이블은 기본적으로 특정 필드와 연관되어 있습니다. 예를 들어 모든 사용자 모듈은 사용자 ID로, 그룹 토론 모듈은 그룹 ID로, 사진 앨범 모듈은 앨범 ID로 분할할 수 있습니다. 최종 이벤트 알림 정보 테이블은 데이터의 시간 제한을 고려합니다. (최근 이벤트 부분의 정보만 접근 가능), 시간별로 나누어져 있습니다.

결합 분할은 분할 후 전체 아키텍처를 보여줍니다.

실제로 많은 대규모 응용 시스템에서는 수직 분할과 수평 분할이 기본적으로 공존하며 시스템 확장성을 높이기 위해 교대로 수행되는 경우가 많습니다. 다양한 애플리케이션 시나리오를 처리할 때는 이 두 가지 분할 방법의 한계와 장점을 충분히 고려하고 서로 다른 기간(부하 압력)에 서로 다른 방법을 사용해야 합니다.

조인트 슬라이싱의 장점:
- 수직 슬라이싱과 수평 슬라이싱의 장점을 최대한 활용하여 각각의 결함을 방지할 수 있습니다.
- 시스템 확장성을 극대화합니다.
공동 샤딩의 단점:
- 데이터베이스 시스템 아키텍처가 더 복잡하고 유지 관리가 더 어렵습니다.
- 애플리케이션 아키텍처도 더 복잡합니다.
- 데이터 분할 및 통합 솔루션
이전 장을 통해 데이터베이스를 통한 데이터 분할이 시스템의 확장성을 크게 향상시킬 수 있다는 것이 분명해졌습니다. 그러나 데이터베이스의 데이터가 수직 및/또는 수평 분할 후 다른 데이터베이스 호스트에 저장된 후 애플리케이션 시스템이 직면한 가장 큰 문제는 이러한 데이터 소스를 어떻게 더 잘 통합할 것인가 하는 것입니다. 이는 많은 독자들에게도 큰 관심사일 수 있습니다. 질문입니다. 이 섹션의 주요 내용은 데이터 분할 및 데이터 통합을 달성하는 데 도움이 될 수 있는 다양한 종합 솔루션을 분석하는 것입니다.

데이터 통합은 데이터베이스 자체에 의존하여 달성하기 어렵습니다. MySQL에는 유사한 문제를 해결할 수 있는 연합 스토리지 엔진이 있지만 실제 애플리케이션 시나리오에서는 이를 잘 사용하기가 어렵습니다. 그렇다면 다양한 MySQL 호스트에 흩어져 있는 이러한 데이터 소스를 어떻게 통합할 수 있을까요?

일반적으로 두 가지 솔루션이 있습니다.

각 애플리케이션 모듈에서 필요한 하나 이상의 데이터 소스를 구성 및 관리하고, 각 데이터베이스에 직접 액세스하고, 모듈 내에서 데이터 통합을 완료합니다.

모든 데이터 소스는 중간 프록시 계층을 통해 균일하게 관리되며 백엔드 데이터베이스 클러스터는 프런트엔드 애플리케이션에 투명합니다.

아마도 90% 이상의 사람들은 이 두 가지 솔루션에 직면할 때 두 번째 솔루션을 선택하는 경향이 있을 것입니다. 특히 시스템이 계속해서 더 크고 복잡해지면 더욱 그렇습니다. 실제로 이는 매우 올바른 선택입니다. 단기적으로 지불해야 할 비용이 상대적으로 클 수 있지만 전체 시스템의 확장성에 매우 도움이 됩니다.

그래서 첫 번째 솔루션에 대해서는 너무 많이 분석하지 않고 두 번째 아이디어의 몇 가지 솔루션을 집중적으로 분석하겠습니다.

자체 중간 프록시 레이어 개발

데이터 소스 통합의 아키텍처 방향을 해결하기 위해 데이터베이스의 중간 프록시 레이어를 사용하기로 결정한 후 많은 기업(또는 기업)이 특정 요구 사항을 충족하는 자체 프록시 레이어 애플리케이션을 개발했습니다. 응용 시나리오 프로그램.

자체 개발한 중간 프록시 레이어는 자체 애플리케이션의 특성에 최대한 대응할 수 있고 개인화된 요구 사항에 대한 사용자 정의를 극대화하며 변화에 직면할 때 유연하게 대응할 수 있습니다. 이것이 자체 프록시 레이어를 개발할 때 가장 큰 장점이 될 것입니다.

물론, 직접 개발하고 개인화 맞춤화의 즐거움을 최대한 누리는 동안 초기 연구 개발과 그에 따른 지속적인 업그레이드 및 개선에 더 많은 비용을 투자해야 하는 것은 당연하고 기술적인 한계점은 기존의 것보다 높을 수 있습니다. 간단한 웹 애플리케이션. 따라서 자체 개발을 결정하기 전에 보다 포괄적인 평가를 수행해야 합니다.

자체 개발은 자체 애플리케이션 시스템에 어떻게 더 잘 적응하고 자체 비즈니스 시나리오에 대처할 수 있는지 고려하는 경우가 많기 때문에 여기서 너무 많이 분석하는 것은 쉽지 않습니다. 다음에서는 현재 널리 사용되는 여러 데이터 소스 통합 솔루션을 주로 분석합니다.

MySQL 프록시를 사용하여 데이터 분할 및 통합 달성

MySQL 프록시는 MySQL에서 공식적으로 제공하는 데이터베이스 프록시 계층 제품으로, MySQL Server와 마찬가지로 GPL 오픈 소스 계약을 기반으로 하는 오픈 소스 제품입니다. 이들 간의 통신을 모니터링, 분석 또는 전송하는 데 사용할 수 있습니다. 유연성 덕분에 최대한 활용할 수 있으며 현재 기능에는 주로 연결 라우팅, 쿼리 분석, 쿼리 필터링 및 수정, 로드 밸런싱, 기본 HA 메커니즘이 포함됩니다.

사실 MySQL Proxy 자체에는 위의 기능이 모두 포함되어 있지는 않지만, 위의 기능을 구현하기 위한 기반을 제공합니다. 이러한 기능을 구현하려면 LUA 스크립트를 직접 작성해야 합니다.

MySQL 프록시는 실제로 클라이언트 요청과 MySQL 서버 사이에 연결 풀을 설정합니다. 모든 클라이언트 요청은 MySQL Proxy로 전송되며, MySQL Proxy는 해당 분석을 수행하여 읽기 작업인지 쓰기 작업인지 판단한 후 해당 MySQL Server에 배포합니다. 다중 노드 슬레이브 클러스터의 경우 로드 밸런싱을 달성할 수도 있습니다. 예를 들어 MySQL 프록시의 기본 아키텍처 다이어그램(그림 4):

위의 아키텍처 다이어그램을 통해 실제 애플리케이션에서 MySQL 프록시의 위치와 이것이 수행할 수 있는 기본 작업을 명확하게 볼 수 있습니다. MySQL 프록시의 자세한 구현 세부 사항은 공식 MySQL 문서에 아주 자세하게 소개되어 있습니다. 관심 있는 독자는 공식 MySQL 웹사이트에서 직접 무료로 다운로드하거나 온라인으로 읽을 수 있으므로 여기서는 자세히 설명하지 않겠습니다.

Amoeba를 사용하여 데이터 분할 달성

Amoeba는 Java 기반으로 개발된 오픈 소스 프레임워크로, 분산 데이터베이스 데이터 소스 통합 프록시 프로그램 해결에 중점을 두고 있습니다. 이는 GPL3 오픈 소스 계약을 기반으로 합니다. 현재 Amoeba에는 그림 5와 같이 쿼리 라우팅, 쿼리 필터링, 읽기-쓰기 분리, 로드 밸런싱, HA 메커니즘 및 기타 관련 내용이 이미 포함되어 있습니다.

Amoeba는 주로 다음 문제를 해결합니다.
- 데이터 분할 후 복잡한 데이터 소스 통합
- 데이터 분할 규칙을 제공하고 데이터 분할 규칙이 데이터베이스에 미치는 영향을 줄입니다. 데이터베이스와 클라이언트 간의 연결
- 읽기와 쓰기를 위한 별도의 라우팅.
- 아메바가 하는 일이 바로 데이터 세분화를 통해 데이터베이스의 확장성을 향상시키는 데 필요한 일임을 알 수 있습니다.
Amoeba For MySQL은 프런트엔드 애플리케이션에서 요청하는 프로토콜과 백엔드 연결을 위한 데이터 소스 데이터베이스가 MySQL이어야 합니다. 모든 클라이언트 애플리케이션의 경우 Amoeba For MySQL과 MySQL 데이터베이스 간에는 차이가 없습니다. MySQL 프로토콜을 사용하는 모든 클라이언트 요청은 Amoeba For MySQL에 의해 구문 분석되고 그에 따라 처리될 수 있습니다. Amoeba For는 Amoeba For MySQL의 아키텍처 정보를 알려줍니다(Amoeba 개발자 블로그 참조).

Amoeba For Aladin은 더 광범위하게 적용 가능하고 더 강력한 프록시 프로그램입니다. 동시에 다른 데이터베이스의 데이터 소스에 연결하여 프런트엔드 애플리케이션에 대한 서비스를 제공할 수 있지만 MySQL 프로토콜을 준수하는 클라이언트 애플리케이션 요청만 허용합니다. 즉, 프런트 엔드 애플리케이션이 MySQL 프로토콜을 통해 연결되어 있는 한 Amoeba For Aladin은 자동으로 Query 문을 분석하고 요청된 데이터를 기반으로 Query 데이터 소스가 어떤 유형의 데이터베이스의 물리적 호스트인지 자동으로 식별합니다. 쿼리 문이 우수합니다. Amoeba For Aladdin 아키텍처 다이어그램(그림 6)은 Amoeba For Aladin의 아키텍처 세부 정보를 보여줍니다(Amoeba 개발자 블로그 참조).

언뜻 보면 둘은 완전히 똑같은 것 같습니다. 자세히 살펴보면 둘 사이의 주요 차이점은 MySQL 프로토콜 어댑터로 처리한 후 분석 결과에 따라 데이터 소스 데이터베이스를 결정한 다음 특정 JDBC 드라이버와 해당 프로토콜을 선택하여 연결한다는 것입니다. 백엔드 데이터베이스.

사실 위의 두 가지 아키텍처 다이어그램을 통해 Amoeba의 특징을 발견하셨을 것입니다. 이는 단지 개발 프레임워크일 뿐이며, 이미 제공하고 있는 두 가지 제품인 For MySQL과 For Aladin을 기반으로 할 수도 있습니다. 2차 개발을 통해 귀하의 어플리케이션 특성에 더욱 적합한 Proxy 프로그램을 얻을 수 있습니다.

하지만 MySQL 데이터베이스를 사용하려면 Amoeba For MySQL과 Amoeba For Aladin을 모두 잘 사용할 수 있습니다. 물론, 시스템이 복잡할수록 성능은 확실히 손실을 입게 되며 유지 관리 비용도 자연스럽게 높아집니다. 따라서 MySQL 데이터베이스만 사용해야 하는 경우 Amoeba For MySQL을 사용하는 것이 좋습니다.

Amoeba For MySQL은 사용이 매우 간단합니다. 모든 구성 파일은 다음과 같이 총 4개입니다.

amoeba.xml - 모든 데이터 소스와 Amoeba 자체를 구성하는 기본 구성 파일입니다. ;
- rule.xml - 모든 쿼리 라우팅 규칙의 정보를 구성합니다.
- functionMap.xml - 쿼리의 함수에 해당하는 Java 구현 클래스를 구성합니다.
- rullFunctionMap.xml —— 라우팅 규칙에 사용해야 하는 특정 기능의 클래스입니다.
- 규칙이 너무 복잡하지 않다면 기본적으로 위의 4개 프로필 중 처음 두 개만 사용하면 모든 작업이 완료됩니다. 읽기-쓰기 분리, 로드 밸런싱, 기타 구성 등 Proxy 프로그램에서 일반적으로 사용되는 기능은 모두 amoeba.xml에 구성되어 있습니다. 또한 Amoeba는 이미 데이터의 수직 및 수평 분할을 위한 자동 라우팅을 지원합니다. 라우팅 규칙은 rule.xml에서 설정할 수 있습니다.
HiveDB를 사용하여 데이터 분할 및 통합 달성

이전 MySQL Proxy 및 Amoeba와 마찬가지로 HiveDB도 MySQL 데이터베이스에 대한 데이터 분할 및 통합을 제공하는 Java 기반 오픈 소스 프레임워크입니다. 그러나 현재 HiveDB는 데이터의 수평 분할만 지원합니다. 주로 대용량 데이터 볼륨에서 데이터베이스 확장성과 고성능 데이터 액세스 문제를 해결하는 동시에 데이터 중복성과 기본 HA 메커니즘을 지원합니다.

HiveDB의 구현 메커니즘은 MySQL 프록시 및 Amoeba와 다소 다릅니다. 데이터 중복성을 달성하기 위해 MySQL의 복제 기능을 사용하지 않지만 자체 데이터 중복성 메커니즘을 구현하며 기본 계층은 주로 Hibernate Shards를 구현합니다. 일하다.

HiveDB에서 데이터는 다양한 사용자 정의 파티션 키(예: 데이터 분할 규칙 공식화)를 통해 여러 MySQL 서버에 분산됩니다. 액세스 중에 쿼리 요청을 실행하면 필터 조건이 자동으로 분석되고 여러 MySQL 서버에서 병렬로 데이터가 읽혀지며 결과 세트가 병합되어 클라이언트 애플리케이션에 반환됩니다.

순전히 기능적 관점에서 보면 HiveDB는 MySQL Proxy 및 Amoeba만큼 강력하지 않을 수 있지만 데이터 분할 아이디어는 이전 두 가지와 본질적으로 다르지 않습니다. 또한, HiveDB는 단순히 오픈소스 애호가들이 공유하는 콘텐츠가 아니라, 상용 기업이 지원하는 오픈소스 프로젝트입니다.

HiveDB 공식 홈페이지에 있는 HiveDB 아키텍처 다이어그램(그림 7)에는 HiveDB가 데이터를 구성하는 방식에 대한 기본 정보가 설명되어 있습니다. 아키텍처 정보를 자세히 표시할 수는 없지만 기본적으로 데이터 분할에서 고유한 기능을 보여줄 수 있습니다.

데이터 분할 및 통합을 위한 기타 솔루션

위에 소개된 데이터 분할 및 통합을 위한 여러 가지 전체 솔루션 외에도 MySQL 프록시 기반 HSCALE에 대한 추가 확장, Rails로 구축된 Spock 프록시 등 다양한 솔루션이 있습니다. , Pathon 기반 Pyshards 등.

어떤 솔루션을 선택하더라도 전체적인 디자인 아이디어는 기본적으로 전혀 변하지 않아야 합니다. 즉, 데이터의 수직 및 수평 분할을 통해 데이터베이스의 전반적인 서비스 기능이 향상되어 전반적인 확장 기능이 향상되어야 합니다. 최대한 편리하게 개선하고 확장할 수 있습니다.

중간 계층 프록시 응용 프로그램을 통해 데이터 분할 및 데이터 소스 통합 문제가 잘 해결되는 한 데이터베이스의 선형 확장 기능은 응용 프로그램만큼 편리합니다. 저렴한 PC 서버 서버, 데이터베이스를 추가하기만 하면 선형적으로 증가할 수 있습니다. 클러스터의 전반적인 서비스 기능은 데이터베이스가 응용 시스템의 성능 병목 현상을 쉽게 일으키지 않도록 방지합니다.

데이터 분할 및 통합에 발생할 수 있는 문제

여기서 모든 사람은 데이터 분할 및 통합 구현에 대해 어느 정도 이해하고 있어야 합니다. 아마도 많은 독자들이 기본적으로 자신에게 적합한 솔루션을 찾은 후 다양한 솔루션을 선택했을 것입니다. 자체 애플리케이션 시나리오의 경우 다음 단계는 주로 구현을 준비하는 것입니다.

데이터 세분화 계획을 구현하기 전에 몇 가지 가능한 문제를 분석해야 합니다. 일반적으로 직면할 수 있는 주요 문제는 다음과 같습니다.
- 분산 트랜잭션 도입 문제
- 교차 노드 조인 문제
- 교차 노드 병합 정렬 문제; 페이징.
- 분산 트랜잭션의 문제점 소개
데이터가 여러 MySQL 서버에 분할되어 저장되면 분할 규칙이 아무리 완벽하게 설계되어 있더라도(사실 완벽한 분할 규칙은 없습니다), 일부 이전 트랜잭션과 관련된 데이터는 더 이상 동일한 MySQL 서버에 없습니다.

이러한 시나리오에서 애플리케이션이 여전히 이전 솔루션을 따르는 경우 이를 해결하기 위해 분산 트랜잭션을 도입해야 합니다. 다양한 MySQL 버전 중 MySQL 5.0부터 시작하는 버전만이 분산 트랜잭션을 지원하며, 현재는 Innodb만이 분산 트랜잭션 지원을 제공하고 있다. 그러나 분산 트랜잭션을 지원하는 MySQL 버전을 사용하고 Innodb 스토리지 엔진을 사용한다고 해도 분산 트랜잭션 자체가 많은 시스템 리소스를 소비하고 예외 처리 측면에서 분산 트랜잭션을 도입하면 성능이 그리 높지 않습니다. 통제하기 어려운 많은 문제가 발생할 것입니다.

무엇을 해야 할까요? 실제로 이 문제는 해결 방법을 통해 해결할 수 있습니다. 가장 먼저 고려해야 할 사항은 데이터베이스가 트랜잭션을 해결할 수 있는 유일한 장소입니까? 실제로 이는 데이터베이스와 애플리케이션을 결합하면 해결될 수 없습니다. 각 데이터베이스는 자체 트랜잭션을 해결하고 애플리케이션은 여러 데이터베이스의 트랜잭션을 제어합니다.

즉, 우리가 원하는 한 여러 데이터베이스에 걸친 분산 트랜잭션을 단일 데이터베이스에만 있는 여러 개의 작은 트랜잭션으로 분할하고 각 작은 트랜잭션을 애플리케이션을 통해 제어할 수 있습니다. 물론 그렇게 하려면 애플리케이션이 충분히 견고해야 하며, 물론 애플리케이션에 몇 가지 기술적 어려움도 가져올 것입니다.

교차 노드 조인 문제

위에서 분산 트랜잭션이 발생할 수 있는 문제가 소개되었습니다. 이제 크로스 노드 조인이 필요한 문제를 살펴보겠습니다. 데이터가 분할된 후에는 조인에 사용되는 데이터 소스가 여러 MySQL 서버로 분할될 수 있으므로 일부 이전 조인 문은 더 이상 사용되지 않을 수 있습니다.

무엇을 해야 할까요? MySQL 데이터베이스의 관점에서 볼 때, 이 문제를 데이터베이스 측에서 직접 해결해야 한다면 MySQL의 특수 스토리지 엔진인 Federated를 통해서만 처리할 수 있지 않을까 걱정됩니다. Federated Storage Engine은 Oracle의 DB Link와 유사한 문제에 대한 MySQL의 솔루션입니다. Oracle DB Link와의 주요 차이점은 Federated가 원격 테이블 구조의 정의 정보 사본을 로컬에 저장한다는 것입니다. 언뜻 보기에 Federated는 실제로 노드 간 조인에 대한 매우 좋은 솔루션입니다. 그러나 원격 테이블 구조가 변경되면 로컬 테이블 정의 정보도 그에 따라 변경되지 않는다는 점도 분명히 해야 합니다. 원격 테이블 구조를 업데이트할 때 로컬 연합 테이블 정의 정보가 업데이트되지 않으면 쿼리가 잘못 실행되어 올바른 결과를 얻지 못할 수 있습니다.

이러한 문제를 해결하려면 먼저 구동 테이블이 위치한 MySQL 서버에서 구동 결과 세트를 가져온 후, 해당 데이터를 MySQL 서버에서 가져와서 처리하는 것이 좋습니다. 여기서 구동 결과 세트를 기준으로 구동 테이블이 위치합니다. 많은 독자들은 그렇게 하면 성능에 일정한 영향을 미칠 것이라고 생각할 수 있습니다. 물론 부정적인 영향을 미치겠지만, 그 외에는 기본적으로 더 나은 솔루션이 많지 않습니다. 또한, 데이터베이스가 더 잘 확장되므로 각 MySQL 서버의 로드를 더 잘 제어할 수 있습니다. 단일 쿼리의 경우 분할되지 않은 전보다 응답 시간이 약간 높아질 수 있으므로 성능에 부정적인 영향을 미치지 않습니다. 엄청난. 게다가 이와 같은 크로스 노드 조인에 대한 수요도 많지 않고, 전체 성능에 비하면 작은 부분에 불과할 수도 있습니다. 따라서 전반적인 성능을 위해서는 실제로 가끔 약간씩 희생할 가치가 있습니다. 결국 시스템 최적화 자체는 많은 절충과 균형의 과정입니다.

교차 노드 병합, 정렬 및 페이징 문제

데이터가 수평으로 분할되면 제대로 실행되지 않는 교차 노드 조인뿐만 아니라 정렬 및 정렬을 위한 일부 쿼리 문의 데이터 소스도 발생할 수 있습니다. 여러 노드를 사용하면 페이징이 분할될 수도 있으며, 이로 인해 이러한 정렬 및 페이징 쿼리가 계속해서 정상적으로 실행될 수 없게 됩니다. 실제로 이는 Cross Node Join과 동일합니다. 데이터 소스는 여러 노드에 존재하며 Cross Node Join 작업인 Query를 통해 해결해야 합니다. 마찬가지로 Federated도 이를 부분적으로 해결할 수 있지만 위험은 동일합니다. 그러나 한 가지 차이점이 있습니다. 조인에는 드라이버 중심 관계가 있는 경우가 많으므로 관련된 여러 테이블 간의 데이터 읽기는 일반적으로 순차적 관계를 갖습니다. 하지만 정렬과 페이징은 다릅니다. 정렬과 페이징의 데이터 소스는 기본적으로 테이블(또는 결과 집합)이라고 할 수 있으며 순차적인 관계가 없으므로 여러 데이터 소스에서 데이터를 가져오는 프로세스가 완전히 병렬화될 수 있습니다. . 이러한 방식으로 정렬된 페이징 데이터의 데이터 검색 효율성은 교차 데이터베이스 조인보다 높을 수 있으므로 발생하는 성능 손실이 상대적으로 적은 경우에는 데이터 분할이 없는 원본 데이터베이스보다 더 효율적일 수 있습니다. 물론, 크로스 노드 조인이든 크로스 노드 정렬 및 페이징이든 응용 프로그램 서버는 더 많은 리소스, 특히 메모리 리소스를 소비하게 됩니다. 결과 집합을 읽고 액세스하고 병합하는 프로세스에는 병합을 처리하지 않을 때보다 더 많은 데이터가 필요하기 때문입니다. .