MySQL 데이터베이스 하위 데이터베이스 및 테이블 구성표, 데이터베이스가 너무 크면, 특히 쓰기가 너무 빈번하고 하나의 호스트에서 지원하기 어려운 경우 확장 병목 현상이 계속 발생합니다. 이때 우리는 이 병목 현상을 해결하기 위한 다른 기술적 수단을 찾아야 하는데, 이것이 바로 이번 장에서 소개할 불량 데이터 분할 기술입니다.
MySQLReplication 기능을 통해 달성되는 확장은 항상 데이터베이스 크기에 의해 제한됩니다. 데이터베이스가 너무 크면, 특히 쓰기가 너무 빈번하고 하나의 호스트에서 지원하기 어려운 경우 확장 병목 현상이 계속 발생합니다. 이때 우리는 이 병목 현상을 해결하기 위한 다른 기술적 수단을 찾아야 하는데, 이것이 바로 이번 장에서 소개할 불량 데이터 분할 기술입니다.
많은 독자들이 데이터 샤딩에 관한 관련 기사를 인터넷이나 잡지에서 여러 번 접하셨을 텐데요, 일부 기사에서는 단순히 데이터 샤딩이라고만 부릅니다. 사실 데이터의 샤딩(Sharding)이라 부르든, 데이터의 분할(segmentation)이라 부르든 개념은 똑같다.是 간단히 말하면 특정 조건을 통해 동일한 데이터베이스에 저장한 데이터가 분산되어 여러 데이터베이스(호스트)에 배치되어 분산된 단일 장치 부하 효과를 얻는 것을 의미합니다. 데이터 세분화는 단일 장치 충돌 후 시스템의 전반적인 가용성을 향상시킬 수도 있습니다. 전체 데이터가 아닌 전체 데이터 중 일부만 사용할 수 있습니다.
데이터 샤딩은 샤딩 규칙 유형에 따라 결정됩니다. 두 가지 분할 모드로 나눌 수 있습니다. + 하나는 서로 다른 테이블(또는 스키마)에 따라 서로 다른 데이터베이스(호스트)로 분할하는 것입니다. 이러한 분할을 수직(수직) 분할이라고 합니다. 다른 하나는 테이블에 있는 데이터의 논리적 관계를 기반으로 특정 조건에 따라 동일한 테이블에 있는 데이터를 여러 데이터베이스(호스트)로 분할하는 것입니다. 이러한 분할을 데이터의 수평(수평) 분할이라고 합니다.
수직 분할의 가장 큰 특징은 규칙이 간단하고 구현이 더 편리하다는 것입니다. 특히 기업 간 결합도가 매우 낮은 경우에 적합합니다. 상호 작용이 거의 없고 비즈니스 논리가 매우 명확한 시스템입니다. 이러한 시스템에서는 다양한 비즈니스 모듈에서 사용되는 테이블을 다양한 데이터베이스로 분할하는 것이 매우 쉽습니다. 다른 테이블에 따라 분할됩니다. 애플리케이션에 미치는 영향도 작아지고 분할 규칙이 더 간단하고 명확해집니다.
수평 분할은 수직 분할과 비교됩니다. 상대적으로 말하면 조금 더 복잡합니다. 동일한 테이블의 서로 다른 데이터를 서로 다른 데이터베이스로 분할해야 하기 때문에 애플리케이션의 경우 테이블 이름을 기준으로 분할하는 것보다 분할 규칙 자체가 더 복잡하고 나중에 데이터 유지 관리도 더 복잡해집니다.
테이블 중 하나(또는 일부)의 데이터 볼륨 및 액세스 볼륨이 특히 크고 수직 슬라이싱 및 독립 장치에 배치한 후에도 여전히 성능 요구 사항을 충족할 수 없는 경우 수직으로 샤딩해야 합니다. .결합된 분할 및 수평 분할. 먼저 세로로 자른 다음 가로로 자릅니다. 이런 방법으로만 우리는 매우 큰 테이블의 성능 문제를 해결할 수 있습니다. 아래에서는 수직, 수평, 결합 분할 분할의 세 가지 데이터 절단 방법 구현에 대해 분석합니다.
데이터의 수직 분할
먼저 데이터의 수직 분할이 무엇인지 살펴보겠습니다. 데이터의 수직 분할. 수직 분할이라고도 합니다. 데이터베이스는 한 번에 한 덩어리씩 많은 "데이터 청크"(테이블)로 구성되어 있다고 생각하십시오. 우리는 이러한 "데이터 청크"를 수직으로 잘라서 여러 데이터베이스 호스트에 분산시켰습니다. 이러한 분할 방법은 수직(종단) 데이터 분할입니다.
건축 디자인이 좋은 응용 시스템. 전체 기능은 많은 기능 모듈로 구성되어야 합니다. 각 기능 모듈에 필요한 데이터는 데이터베이스의 하나 이상의 테이블에 해당합니다.
기능 모듈이 더 명확해지고 결합도가 낮아지면 수직 데이터 분할 규칙을 정의하기가 더 쉬워집니다. 데이터는 기능 모듈에 따라 분할될 수 있으며, 서로 다른 기능 모듈의 데이터는 서로 다른 데이터베이스 호스트에 저장되므로 교차 데이터베이스 조인의 존재를 쉽게 피할 수 있습니다. 동시에 시스템 아키텍처도 매우 명확합니다.
물론이죠. 조인 작업을 위해 서로의 테이블이나 두 모듈의 테이블에 액세스할 필요 없이 시스템이 모든 기능 모듈에서 사용하는 테이블을 완전히 독립적으로 만드는 것은 매우 어렵습니다. 이 경우 실제 적용 시나리오를 기반으로 평가하고 평가해야 합니다. 동일한 데이터베이스에 조인해야 하는 테이블의 모든 관련 데이터를 저장하도록 응용 프로그램을 수용할 것인지, 아니면 응용 프로그램이 다른 많은 작업(즉, 프로그램이 모듈 인터페이스를 통해 완전히 다른 데이터베이스에서 데이터를 얻음)을 수행하도록 할 것인지 결정합니다. 그런 다음 프로그램에서 조인 작업이 완료됩니다.
일반적으로 말하면. 비교적 부하가 적은 시스템이고 테이블 연결이 매우 빈번하다고 가정해 보겠습니다. 그러면 데이터베이스가 무너질 수 있습니다. 여러 관련 모듈을 병합하여 애플리케이션 작업을 줄이는 솔루션은 작업 부하를 더욱 줄일 수 있습니다. 가능한 솔루션입니다.
물론이죠. 데이터베이스의 양보를 통해 여러 모듈이 데이터 소스를 중앙에서 공유할 수 있게 되면서 실제로 각 모듈 아키텍처의 결합이 증가하여 미래 아키텍처를 더욱 악화시킬 수 있는 개발을 간략하게 소개합니다. 특히 특정 개발 단계에 도달하면 데이터베이스가 이러한 테이블로 인한 압력을 견딜 수 없는 것으로 나타났습니다. 다시 이별의 시간을 맞이해야 합니다. 구조적 변형 비용은 초기 비용보다 훨씬 클 수 있습니다.
그래서. 데이터베이스를 수직적으로 분할할 경우, 어떻게 분할할 것인지, 어느 정도까지 분할할 것인지가 어려운 문제입니다. 이는 실제 애플리케이션 시나리오에서 모든 측면의 비용과 이점의 균형을 유지해야만 가능합니다. 그래야만 자신에게 꼭 맞는 분할 계획을 분석할 수 있습니다.
예를 들어, 이 책에서 사용된 데모 시스템에 사용된 예제 데이터베이스를 간략하게 분석해 보겠습니다. 그런 다음 수직 분할을 수행하는 간단한 분할 규칙을 설계합니다.
시스템 기능은 기본적으로 사용자, 그룹 메시지, 사진 앨범, 이벤트의 네 가지 기능 모듈로 나눌 수 있습니다. 예를 들어,
1. 사용자 모듈 테이블: user, user_profile, user_group, user_photo_album
2. 그룹 토론 테이블: groups, group_message, group_message_content, top_message
3. , photo_album , photo_album_relation, photo_comment
4. 이벤트 정보 테이블: event
얼핏 보면 어떤 모듈도 다른 모듈과 독립적으로 존재할 수 없으며, 모듈 간에 관계가 있습니다. 나누어질 수 없는 것이 아닐까?
물론 아닙니다. 조금 더 심층적으로 분석해 보면 각 모듈에서 사용하는 테이블은 서로 관련되어 있지만 그 관계는 비교적 명확하고 단순하다는 것을 알 수 있습니다.
◆ 그룹 토론 모듈과 사용자 모듈은 주로 사용자 또는 그룹 관계를 통해 관련됩니다. 일반적으로 사용자의 id나 nick_name과 그룹의 id를 통해 연관이 이루어집니다. 모듈 간의 인터페이스를 통해 구현하면 큰 문제가 발생하지 않습니다.
◆ 사진첩 모듈은 사용자를 통한 사용자 모듈과만 관련됩니다. 이 두 모듈 간의 연결은 기본적으로 사용자 ID를 통한 콘텐츠와 관련됩니다. 간단하고 명확하며 인터페이스가 명확합니다.
◆ 이벤트 모듈은 각 모듈과 관련될 수 있지만 각 모듈에 있는 개체의 ID 정보에만 중점을 두고 매우 쉽게 분할할 수도 있습니다.
그래서. 첫 번째 단계는 기능 모듈과 관련된 테이블에 따라 데이터베이스를 수직으로 분할하는 것입니다. 각 모듈에 포함된 테이블은 별도의 데이터베이스에 저장되며, 모듈 간의 테이블 관계는 응용 시스템 측 인터페이스를 통해 처리됩니다. 예를 들어 아래 그림에서 볼 수 있듯이
이러한 수직 분할 후. 이전에는 데이터베이스를 통해서만 사용할 수 있었던 서비스입니다. 4개의 데이터베이스로 분할하여 서비스를 제공하게 되었고, 자연스럽게 서비스 능력도 몇 배로 늘어났습니다.
수직 분할의 장점
◆ 데이터베이스 분할이 간단하고 명확하며 분할 규칙이 명확합니다.
◆ 애플리케이션 모듈이 명확하고 통합이 쉽습니다.
◆ 데이터 관리가 편리하고 찾기 쉽습니다.
수직 샤딩의 단점
◆ 일부 테이블 연결은 데이터베이스 수준에서 완료할 수 없습니다. 프로그램에서 완료해야 합니다.
◆ 매우 자주 액세스하고 많은 양의 데이터가 있는 테이블의 경우 여전히 성능 저하가 있어 요구 사항을 반드시 충족하지 못할 수 있습니다.
◆ 트랜잭션 처리가 상대적으로 더 복잡합니다.
◆ 샤딩이 특정 수준에 도달하면 확장성이 제한됩니다.
◆ 과도한 읽기 샤딩으로 인해 시스템이 지나치게 복잡해지고 유지 관리가 어려워질 수 있습니다. 수직 절단의 경우 데이터 절단 및 트랜잭션 문제가 발생할 수 있으며 데이터베이스 수준에서 더 나은 처리 솔루션을 찾는 것은 정말 어렵습니다. 실제 응용 사례에서 데이터베이스의 수직 분할은 대부분 응용 시스템의 모듈에 해당합니다. 동일한 모듈의 데이터 소스는 동일한 데이터베이스에 저장되어 모듈 내 데이터 연관 문제를 해결할 수 있습니다. 모듈간 필요한 데이터는 응용 프로그램을 통해 서비스 인터페이스 형태로 서로에게 제공됩니다.
이는 실제로 데이터베이스의 전체 작업 수를 늘리지만 시스템의 전반적인 확장성과 아키텍처의 모듈성 측면에서 의도적인 것입니다. 일부 작업의 단일 응답 시간이 약간 늘어날 수 있습니다. 하지만 시스템의 전반적인 성능은 어느 정도 향상될 가능성이 매우 높습니다. 그리고 확장 병목 현상 문제. 이는 다음 섹션에서 소개할 데이터 수평 분할 아키텍처를 통해서만 극복할 수 있습니다.
위 섹션에서는 데이터의 수직 분할을 분석하고 소개합니다. 이 섹션에서는 데이터의 수평 분할을 분석합니다. 데이터의 수직적 분할은 기본적으로 단순히 데이터를 테이블과 모듈에 따라 분할하는 것으로 이해될 수 있으며, 수평적 분할은 더 이상 테이블이나 기능 모듈에 따라 분할되지 않습니다. 일반적으로 단순 수평 샤딩은 주로 특정 분야의 특정 규칙에 따라 매우 평범한 액세스 권한을 가진 테이블을 여러 테이블로 분산시키는 것입니다. 각 테이블에는 데이터의 일부가 포함되어 있습니다.
간단히 말해서. 데이터의 수평 분할은 데이터 행에 따른 분할로 이해할 수 있습니다. 이는 테이블의 일부 행이 하나의 데이터베이스로 분할되고 일부 다른 행이 다른 데이터베이스로 분할됨을 의미합니다. 물론, 각 데이터 행이 어떤 데이터베이스로 분할되는지 쉽게 결정하기 위해서는 항상 특정 규칙에 따라 분할이 수행되어야 합니다. ㅋㅋㅋ : 숫자 유형 필드, 특정 시간 유형 필드의 범위. 또는 문자 유형 필드의 해시 값입니다. 전체 시스템의 대부분의 핵심 테이블은 특정 필드를 통해 관련될 수 있다고 가정합니다. 그렇다면 이 필드는 당연히 수평 분할을 위한 최선의 선택입니다. 물론 매우 특별해서 사용할 수 없는 경우에는 다른 필드만 선택할 수 있습니다.
일반적으로 Web2.0 유형의 사이트는 오늘날 인터넷에서 매우 인기가 있습니다. 기본적으로 대부분의 데이터는 회원 사용자 정보를 통해 연관될 수 있으며, 많은 코어 테이블은 회원 ID를 통한 데이터의 수평적 분할에 매우 적합할 수 있습니다.
그리고 포럼 커뮤니티 토론 시스템과 같습니다. 포럼 번호에 따라 데이터를 수평으로 분할하는 것이 훨씬 쉽습니다.
분할 후에는 기본적으로 라이브러리 간 상호 작용이 없습니다.样 데모 샘플 시스템입니다. 모든 데이터는 사용자와 연결됩니다. 그런 다음 사용자를 기반으로 수평 분할을 수행하고 다른 사용자의 데이터를 다른 데이터베이스로 분할할 수 있습니다. 물론 유일한 차이점은 사용자 모듈의 그룹 테이블이 사용자와 직접 관련되지 않는다는 것입니다. 따라서 그룹은 사용자를 기준으로 수평적으로 분할될 수 없습니다. 이러한 특수한 경우에는 완전히 독립된 솔루션을 제공할 수 있습니다. 별도의 데이터베이스에 별도로 보관됩니다.
실제로 이 접근 방식은 이전 섹션에서 소개한 "데이터의 수직 분할" 방법을 활용한다고 할 수 있습니다. 다음 절에서는 수직 분할과 수평 분할에 동시에 사용되는 관절 분할 방법에 대해 좀 더 자세히 소개하겠습니다.
따라서 데모 샘플 데이터베이스의 경우 대부분의 테이블은 사용자 ID를 기준으로 수평으로 분할될 수 있습니다. 다양한 사용자와 관련된 데이터는 분할되어 다양한 데이터베이스에 저장됩니다. 예를 들어, 모든 사용자 ID는 모듈로 2를 사용하여 두 개의 서로 다른 데이터베이스에 저장됩니다. D 사용자 ID와 관련된 각 테이블은 다음과 같이 나눌 수 있습니다. 이런 방식으로 기본적으로 모든 사용자 관련 데이터가 생성됩니다. 그것들은 모두 동일한 데이터베이스에 있으며, 연관이 필요한 경우에도 매우 쉽게 연관시킬 수 있습니다.
다음 그림을 사용하면 수평 샤딩 관련 정보를 보다 직관적으로 표시할 수 있습니다. 수평 샤딩의 장점
◆ 테이블 연결은 기본적으로 데이터베이스 측에서 완료될 수 있습니다. ◆ 초대형 테이블은 없습니다. 많은 양의 데이터와 높은 로드로 인해 병목 현상이 발생합니다.
◆ 애플리케이션 측의 전체 아키텍처는 상대적으로 수정 사항이 적습니다.
◆ 트랜잭션 처리는 비교적 간단합니다.
◆ 분할 규칙만 정의할 수 있습니다. 기본적으로 확장성 제한이 발생하기 어렵습니다.
수평 샤딩의 단점
◆ 샤딩 규칙이 상대적으로 더 복잡하고, 전체 데이터베이스를 만족할 수 있는 샤딩 규칙을 추상화하기가 매우 어렵습니다.
◆ 나중에 유지 관리가 어렵습니다. 데이터 데이터를 수동으로 찾는 것이 더 어렵다는 내용이 추가되었습니다.
◆ 애플리케이션 시스템의 각 모듈의 결합 정도가 높아 후속 데이터의 마이그레이션 및 분할에 특정 어려움이 발생할 수 있습니다.
위의 두 섹션에서는 수직 절단과 수평 절단의 조합이 사용됩니다. 우리는 "수직"과 "수평"이라는 두 가지 분할 방법의 구현과 분할 후의 아키텍처 정보에 대해 각각 배웠습니다. 동시에 두 아키텍처의 장점과 단점도 분석했습니다. 하지만 실제 애플리케이션 시나리오에서는 이를 제외하면 부하가 그리 크지 않습니다. 상대적으로 간단한 비즈니스 로직을 갖춘 시스템은 위의 두 가지 분할 방법 중 하나를 통해 확장성 문제를 해결할 수 있습니다. 약간 더 복잡한 비즈니스 로직과 더 큰 시스템 로드를 가진 대부분의 다른 시스템은 위의 데이터 분할 방법을 통해 더 나은 확장성을 달성할 수 없다는 점이 유감입니다. 위의 두 가지 분할 방법을 결합하고 다양한 시나리오에서 서로 다른 분할 방법을 사용해야 합니다. 이 섹션에서는. 수직 슬라이싱과 수평 슬라이싱의 장점과 단점을 결합하여 전반적인 아키텍처를 더욱 개선하고 시스템의 확장성을 더욱 향상시키겠습니다. 일반적으로 말하면. 하나 또는 몇 개의 필드를 통해 데이터베이스의 모든 테이블을 연결하는 것은 매우 어렵기 때문에 단순히 데이터의 수평 분할만으로 모든 문제를 해결하는 것은 매우 어렵습니다. 수직 샤딩은 문제의 일부만 해결할 수 있습니다. 부하가 매우 높은 시스템의 경우 단일 테이블이라도 단일 데이터베이스 호스트를 통해 부하를 감당할 수 없습니다.垂 "수직"과 "수평"의 투컷 방식을 동시에 사용해야 하며, 둘의 장점을 최대한 활용하여 단점을 피해야 합니다. 모든 애플리케이션 시스템의 로드는 단계적으로 증가합니다. 성능 병목 현상이 발생하기 시작하면 대부분의 설계자와 DBA는 높은 비용 때문에 먼저 데이터를 수직으로 분할하는 것을 선택합니다. 이는 이 기간 동안 추구한 최대 입출력 비율과 가장 일치한다. 하지만. 사업이 계속 확장되면서. 시스템 부하가 지속적으로 증가함에 따라 시스템이 일정 기간 안정된 후에도 수직으로 분할되었던 데이터베이스 클러스터가 다시 과부하되어 성능 병목 현상이 발생할 수 있습니다. 이때 우리는 무엇을 선택해야 할까요? 모듈을 다시 세분화해야 할까요, 아니면 다른 솔루션을 찾아야 할까요? 처음처럼 계속해서 모듈을 세분화하고 데이터의 수직 분할을 수행한다고 가정하면 가까운 시일 내에 오늘날 직면하고 있는 것과 동일한 문제에 직면할 수 있습니다. 그리고 모듈이 지속적으로 개선됨에 따라 애플리케이션 시스템의 아키텍처는 점점 더 복잡해지고 전체 시스템이 통제 불능 상태가 될 수 있습니다. 이때 여기서 직면하는 문제를 해결하려면 데이터의 수평 분할을 활용해야 합니다. 또한 수평 데이터 분할을 사용할 때 이전의 수직 데이터 분할 결과를 뒤집을 필요가 없으며 대신 수직 분할의 단점을 피하기 위해 수평 분할의 장점을 사용합니다. 시스템 복잡성 확대 문제를 해결합니다. 수평 분할의 단점(규칙을 통일하기 어렵다)도 기존 수직 분할로 해결되었습니다. 수평 분할을 쉽게 만듭니다.样 데모 샘플 데이터베이스용입니다. 처음에는 가정하십시오. 데이터의 수직 분할을 수행했지만 비즈니스가 계속 성장함에 따라 데이터베이스 시스템에 병목 현상이 발생하여 데이터베이스 클러스터의 아키텍처를 재구성하기로 결정했습니다. 리팩토링하는 방법? 데이터의 수직 분할이 이전에 수행된 것을 고려하면 모듈 구조가 명확합니다. 그리고 비즈니스 성장의 모멘텀은 점점 더 강해지고 있습니다. 지금 모듈을 더 분할해도 오래 가지 못할 것입니다. 수직 분할을 기준으로 수평 분할을 선택했습니다.直 수직 분할 후 각 데이터베이스 클러스터에는 기능 모듈이 하나만 있습니다. 기본적으로 각 기능 모듈의 모든 테이블은 특정 필드와 연결됩니다. 예를 들어, 모든 사용자 모듈은 사용자 ID로 분할될 수 있고, 그룹 토론 모듈은 모두 그룹 ID로 분할될 수 있습니다. 사진 앨범 모듈은 앨범 ID를 기준으로 분류됩니다. 최종 이벤트 알림 정보 테이블은 데이터의 시간 제한(최근 이벤트 세그먼트의 정보만 접근 가능)을 고려하여 시간별로 구분된 것으로 간주됩니다. 다음 그림은 분할 후 전체 아키텍처를 보여줍니다.실제로 많은 대규모 응용 시스템에서는 수직 분할과 수평 분할이라는 두 가지 데이터 분할 방법이 기본적으로 공존합니다. 그리고 시스템의 확장 기능을 지속적으로 추가하기 위해 교대로 수행되는 경우가 많습니다. 다양한 애플리케이션 시나리오를 다룰 때는 이 두 가지 분할 방법의 한계와 장점도 충분히 고려해야 합니다. 서로 다른 시점(부하 압력)에 따라 서로 다른 접착 방법을 사용하십시오.
공동 샤딩의 장점
◆ 수직 슬라이싱과 수평 슬라이싱의 장점을 최대한 활용하고 각각의 단점을 피할 수 있습니다.
◆ 시스템 확장성을 극대화합니다.
관절 분할의 단점
◆ 데이터베이스 시스템 아키텍처는 비교적 복잡합니다. 유지관리가 더 어렵습니다.
◆ 이전 장을 통해 살펴본 애플리케이션 아키텍처는
보다 상대적으로 더 복잡합니다. 우리는 데이터베이스를 통한 데이터 분할이 시스템의 확장성을 크게 향상시킬 수 있다는 점을 이미 분명히 밝혔습니다. 그러나 데이터베이스의 데이터가 수직 및/또는 수평 분할을 통해 서로 다른 데이터베이스 호스트에 저장된 후 애플리케이션 시스템이 직면한 가장 큰 문제는 이러한 데이터 소스를 어떻게 더 잘 통합할 것인가입니다. 아마도 이것은 많은 독자들이 매우 우려하는 문제이기도 합니다. 이 섹션의 주요 초점은 데이터 분할 및 데이터 통합을 달성하는 데 사용할 수 있는 다양한 전체 솔루션을 분석하는 것입니다.
이러한 효과를 얻기 위해 데이터베이스 자체에 의존하여 데이터를 통합하는 것은 매우 어렵습니다. 하지만 MySQL에는 유사한 문제를 해결할 수 있는 통합 스토리지 엔진이 있습니다. 그러나 실제 응용 시나리오에서는 이를 잘 활용하기가 매우 어렵습니다. 그렇다면 다양한 MySQL 호스트에 분산된 이러한 데이터 소스를 어떻게 통합합니까?
일반적으로 두 가지 솔루션이 있습니다.
1. 각 애플리케이션 모듈에 필요한 하나 이상의 데이터 소스를 구성하고 관리합니다.
2. 중간 프록시 계층을 통해 모든 데이터 소스를 통합하고 관리합니다. 백엔드 데이터베이스 클러스터는 프런트엔드 애플리케이션에 투명합니다.
특히 시스템이 계속 크고 복잡해지면 위의 두 가지 솔루션에 직면할 때 90% 이상의 사람들이 다른 것을 선택하는 경향이 있습니다.
그렇죠. 이는 매우 올바른 선택입니다. 단기적인 비용은 상대적으로 클 수 있지만 전체 시스템의 확장성에 매우 도움이 됩니다.决 따라서 여기서는 첫 번째 솔루션에 대해 너무 많은 분석을 준비하지 않습니다. 다음은 다른 솔루션의 일부 솔루션을 분석하는 데 중점을 둡니다.
★ 자체 중간 프록시 레이어 개발
데이터 소스 통합의 아키텍처 방향을 해결하기 위해 데이터베이스의 중간 프록시 레이어를 사용하기로 결정한 후 많은 기업(또는 기업)이 특정 요구 사항을 충족하는 자체 프록시 레이어를 개발하기로 선택했습니다. 응용 프로그램 시나리오. ㅋㅋㅋ 자체 중간 프록시 레이어를 개발하여 애플리케이션의 특수성에 최대한 대처할 수 있습니다. 극대화된 커스터마이징으로 개인별 요구사항을 충족하고 변화에 유연하게 대응할 수 있습니다. 이것이 자체 프록시 레이어를 개발하는 것의 가장 큰 장점이라고 할 수 있습니다.
물론, 직접 개발을 선택하고 개인화된 맞춤화를 극대화하는 즐거움을 누리는 동안, 초기 연구 개발과 이후 지속적인 업그레이드 및 개선을 위해 당연히 다른 많은 비용을 투자해야 할 것입니다. 그리고 기술적인 한계점 자체가 단순한 웹 애플리케이션보다 높을 수도 있습니다. 따라서 직접 개발하기로 결정하기 전에 보다 포괄적인 평가를 수행해야 합니다.其 자신의 애플리케이션 시스템에 더 잘 적응하고 비즈니스 시나리오를 처리하는 방법을 고려하는 데 많은 시간을 투자했기 때문에 여기서 분석하는 것은 쉽지 않습니다. 나중에는 현재 널리 사용되는 여러 데이터 소스 통합 솔루션을 주로 분석하겠습니다.
★MySQLProxy를 사용하여 데이터 분할 및 통합 달성
MySQLProxy는 MySQL에서 공식적으로 제공하는 데이터베이스 프록시 계층 제품으로, MySQLServer와 마찬가지로 GPL 오픈 소스 계약을 기반으로 하는 오픈 소스 제품입니다. 이들 간의 통신 정보를 모니터링, 분석 또는 전송하는 데 사용할 수 있습니다. 유연성 덕분에 현재 기능에는 주로 연결 라우팅, 쿼리 분석, 쿼리 필터링 및 수정, 로드 밸런싱이 포함됩니다. 뿐만 아니라 주요 HA 메커니즘 등도 포함됩니다.
사실 MySQLProxy 자체에는 위의 기능이 모두 포함되어 있지 않습니다. 대신 위의 기능을 구현하기 위한 기반을 제공합니다.
이러한 기능을 구현하려면 자체 LUA 스크립트도 작성해야 합니다.
MySQLProxy는 실제로 클라이언트 요청과 MySQLServer 사이에 연결 풀을 설정합니다. 모든 클라이언트 요청은 MySQLProxy로 전송된 후 MySQLProxy를 통해 해당 분석이 수행됩니다. 읽기 작업인지 쓰기 작업인지 유추하여 해당 MySQL Server에 배포합니다. 다중 노드 슬레이브 클러스터의 경우 로드 밸런싱을 달성할 수도 있습니다. 다음은 MySQLProxy의 기본 아키텍처 다이어그램입니다.
위 아키텍처 다이어그램을 통해. 실제 애플리케이션에서 MySQLProxy의 위치와 이것이 수행할 수 있는 기본 작업을 매우 명확하게 볼 수 있습니다. MySQLProxy에 대한 보다 구체적인 구현 세부 사항은 매우 구체적인 소개 및 데모 예제가 포함된 MySQL 공식 문서에서 찾을 수 있습니다. 관심 있는 독자는 MySQL 공식 웹사이트에서 직접 무료로 다운로드하거나 온라인에서 읽을 수 있습니다. 여기서는 종이 낭비를 하지 않겠습니다.
★Amoeba를 사용하여 데이터 분할 및 통합 달성
Amoeba는 Java를 기반으로 개발된 오픈 소스 프레임워크로, 분산 데이터베이스 데이터 소스 통합 프록시 프로그램을 해결하는 데 중점을 두고 있습니다. 이는 GPL3 오픈 소스 계약을 기반으로 합니다. 현재 Amoeba에는 쿼리 라우팅, 쿼리 필터링, 읽기-쓰기 분리, 로드 밸런싱, HA 메커니즘 및 기타 관련 콘텐츠가 이미 있습니다.
Amoeba는 주로 다음 문제를 해결합니다.
1. 데이터 분할 후 복잡한 데이터 소스를 통합합니다.
2. 데이터 분할 규칙을 제공하고 데이터베이스에 대한 데이터 분할 규칙의 영향을 줄입니다.
3. 데이터베이스와 클라이언트 간의 연결 수를 줄입니다.
4. 읽기-쓰기 분리 라우팅
Amoeba가 수행하는 작업이 바로 데이터 분할을 통해 데이터베이스의 확장성을 향상시키는 데 필요한 작업임을 알 수 있습니다.
Amoeba는 프록시 레이어 프록시 프로그램이 아니라 데이터베이스 프록시 레이어 프록시 프로그램 개발을 위한 개발 프레임워크입니다. 현재 Amoeba를 기반으로 개발된 프록시 프로그램은 AmoebaForMySQL과 AmoebaForAladin입니다.
AmoebaForMySQL은 주로 MySQL 데이터베이스 전용 솔루션입니다. 프런트엔드 애플리케이션에서 요청하는 프로토콜과 백엔드에서 연결하는 데이터 소스 데이터베이스는 MySQL이어야 합니다. 모든 클라이언트 애플리케이션의 경우 AmoebaForMySQL과 MySQL 데이터베이스 간에는 차이가 없습니다. MySQL 프로토콜을 사용하는 모든 클라이언트 요청은 AmoebaForMySQL에 의해 구문 분석되고 그에 따라 처리될 수 있습니다. 다음은 AmoebaForMySQL의 아키텍처 정보를 알려줍니다(Amoeba 개발자 블로그에서 제공).
AmoebaForAladin은 더 광범위하게 적용할 수 있는 정보입니다. 더욱 강력한 프록시 프로그램입니다.
프런트 엔드 애플리케이션에 대한 서비스를 제공하기 위해 동시에 다른 데이터베이스의 데이터 소스에 연결할 수 있지만 MySQL 프로토콜을 준수하는 클라이언트 애플리케이션 요청만 허용합니다. 즉, 프런트 엔드 애플리케이션이 MySQL 프로토콜을 통해 연결되어 있는 한 AmoebaForAladin은 Query 문을 적극적으로 분석하고 물리적 호스트에서 Query 문에서 요청한 데이터를 기반으로 Query의 데이터 소스를 자동으로 식별합니다. 다음 그림은 AmoebaForAladin(Amoeba 개발자 블로그에서)의 아키텍처 세부 사항을 보여줍니다.
언뜻 보기에 둘은 정확히 동일한 것처럼 보입니다. 자세히 살펴보면 둘 사이의 주요 차이점은 MySQLProtocalAdapter를 통해 처리한 후에만 발생한다는 것을 알 수 있습니다. 분석 결과를 바탕으로 데이터 소스 데이터베이스를 추론합니다. 그런 다음 특정 JDBC 드라이버와 해당 프로토콜을 선택하여 백엔드 데이터베이스에 연결합니다.
사실 위의 두 아키텍처 다이어그램을 통해 Amoeba의 특징을 발견했을 수도 있습니다. 그것은 단지 개발 프레임워크일 뿐입니다. 그가 제공한 두 가지 제품 외에도 ForMySQL과 ForAladin이 있습니다. 또한 자체 필요에 따라 해당하는 2차 개발을 수행할 수도 있습니다. 우리의 응용프로그램 특성에 더 적합한 Proxy 프로그램을 받으세요.
MySQL 데이터베이스를 사용하는 경우. AmoebaForMySQL과 AmoebaForAladin은 모두 매우 잘 사용할 수 있습니다. 물론, 시스템이 복잡할수록 성능은 확실히 어느 정도 손실을 입게 되며, 유지 관리 비용도 당연히 상대적으로 높아지게 됩니다. 따라서 MySQL 데이터베이스만 사용해야 하는 경우에도 AmoebaForMySQL을 사용하는 것이 좋습니다.
AmoebaForMySQL은 사용이 매우 간단합니다. 모든 구성 파일은 표준 XML 파일이며 총 4개의 구성 파일이 있습니다.
◆ amoeba.xml: 기본 구성 파일로 모든 데이터 소스와 Amoeba의 자체 매개변수 설정을 구성합니다.
◆ rule.xml: 모든 쿼리 라우팅 규칙 정보를 구성합니다.
◆ functionMap.xml: 쿼리의 함수에 해당하는 Java 구현 클래스를 구성합니다.
◆ rullFunctionMap.xml: 라우팅 규칙에 사용해야 하는 특정 함수의 구현 클래스를 구성합니다.
규칙이 그렇지 않은 경우 너무 복잡합니다. 기본적으로 위의 네 가지 구성 파일 중 처음 두 개만 사용하면 모든 작업을 완료할 수 있습니다. 프록시 프로그램에서 자주 사용하는 기능에는 읽기와 쓰기의 분리가 포함됩니다. 로드 밸런싱 및 기타 구성은 amoeba.xml에서 수행됩니다. 또한. Amoeba는 이미 데이터의 수직 및 수평 샤딩을 구현하는 자체 활성 라우팅을 지원합니다. 라우팅 규칙은 rule.xml에서 설정할 수 있습니다. 현재 AMOEBA는 드물고 온라인 관리 기능과 트랜잭션 지원이 주요 내용입니다. 관련 개발자들과 소통하는 과정에서 관련 제안을 하여 온라인 유지 관리를 제공할 수 있는 기능을 제공하고 싶습니다. 온라인 유지 관리에 도구가 편리하다는 피드백을 받았습니다. 개발 일정에 전용 관리 모듈이 포함되었다는 것입니다. 또한, 아메바는 일시적으로 거래를 지원할 수 없습니다. 클라이언트 애플리케이션이 아메바에 제출한 요청에 거래 정보를 포함하더라도 아메바는 거래 관련 정보를 무시합니다. 물론 지속적인 개선을 거쳐 거래 지원은 확실히 아메바가 추가를 고려할 기능이라고 생각합니다.
좀 더 구체적인 아메바 사용법이 있는 독자들은 아메바 개발자 블로그(http://amoeba.sf.net)에서 제공하는 사용설명서를 통해 구할 수 있으며, 여기서는 자세한 설명을 생략하겠습니다.
★HiveDB를 사용하여 데이터 분할 및 통합
이전 MySQLProxy 및 Amoeba와 마찬가지로 HiveDB도 데이터 분할 및 통합을 제공하는 MySQL 데이터베이스용 Java 기반 오픈 소스 프레임워크입니다. 그러나 현재 HiveDB는 데이터 컷만 지원합니다. 수평으로.
주로 대용량 데이터에서 데이터베이스 확장성과 고성능 데이터 액세스 문제를 해결하는 동시에 데이터 중복성과 주요 HA 메커니즘을 지원합니다.
HiveDB의 구현 메커니즘은 MySQLProxy 및 Amoeba와 다소 다릅니다. 데이터 중복성을 달성하기 위해 MySQL의 복제 기능을 사용하지 않고 자체 데이터 중복성 메커니즘을 구현하며 기본 계층은 주로 HibernateShards로 구현된 데이터를 기반으로 합니다. 일. B HiveDB에서는 사용자 자신의 정의를 통해 다양한 partitionKeys(실제로 데이터 분할 규칙을 공식화하기 위한 것)를 통해 데이터가 여러 MySQLServer로 분산됩니다. 방문 당시. 쿼리 요청을 실행할 때. 필터 조건을 자체적으로 적극적으로 분석하고, 여러 MySQL 서버에서 병렬로 데이터를 읽고, 결과 세트를 병합하여 클라이언트 애플리케이션에 반환합니다.讲 기능적인 관점에서 볼 때 HiveDB는 MySQLProxy와 Amoeba만큼 강력하지는 않을 수 있지만 데이터 절단에 대한 아이디어는 이전 두 가지와 본질적으로 다르지 않습니다. 또한, HiveDB는 단순히 오픈소스 애호가들이 공유하는 콘텐츠가 아니라, 상용 기업이 지원하는 오픈소스 프로젝트입니다.
다음은 HiveDB 공식 웹사이트의 첫 번째 장에 나오는 사진으로, HiveDB가 데이터를 구성하는 방법에 대한 기본 정보를 설명하고 있습니다. 비록 구체적으로 많은 아키텍처 정보를 표시할 수는 없지만 기본적으로 데이터 분할 측면에서 고유성을 보여줄 수 있습니다.
★ mycat 데이터 통합: 세부 정보 http://www.songwie.com/articlelist/11
★ 데이터 분할 및 통합을 달성하기 위한 기타 솔루션
위에 소개된 여러 데이터 분할 및 통합 외에도 추가로 전체 솔루션 외에도 데이터 분할 및 통합을 제공하는 다른 솔루션도 많이 있습니다. 예를 들어 HSCALE은 MySQLProxy를 기반으로 더욱 확장되고 SpockProxy는 Rails를 통해 구축됩니다. Pathon 기반 Pyshards 등도 있습니다.
어떤 솔루션을 선택하더라도 기본적으로 전체적인 디자인 아이디어에는 변화가 없어야 합니다. 즉, 데이터의 수직적, 수평적 분할을 통해 데이터베이스의 전반적인 서비스 능력을 향상시켜, 응용 시스템의 전체적인 확장성을 최대한 향상시킬 수 있다는 것이다. 확장 방법은 최대한 편리합니다.
중간 계층 프록시 애플리케이션을 통해 데이터 분할 및 데이터 소스 통합 문제를 더 잘 극복할 수 있다는 것입니다. 그러면 데이터베이스의 선형 확장성은 우리 애플리케이션만큼 편리해지기 매우 쉬울 것입니다. 저렴한 PCServer서버를 추가하는 것만으로도 데이터베이스 클러스터의 전체 서비스 용량을 선형적으로 늘릴 수 있으므로 데이터베이스가 더 이상 애플리케이션 시스템의 성능 병목 현상을 쉽게 일으키지 않습니다. 합 데이터 절단 및 통합 문제
여기. 모든 사람은 데이터 분할 및 통합 구현에 대해 어느 정도 이해하고 있어야 합니다. 아마도 많은 독자와 친구들은 기본적으로 다양한 솔루션의 각 특성의 장단점을 기반으로 자신의 응용 시나리오에 적합한 솔루션을 선택했을 것입니다. 후속 작업은 주로 구현 준비입니다.
데이터 분할 계획을 구현하기 전에 발생할 수 있는 몇 가지 문제에 대한 분석을 수행해야 합니다.
◆ 분산 트랜잭션 도입의 문제.
◆ 교차 노드 조인 문제
◆ 교차 노드 병합 정렬 및 페이징 문제.
1. 분산 트랜잭션의 문제 소개
데이터가 여러 MySQL 서버에 분할되어 저장되면 분할 규칙이 아무리 완벽하게 설계되었더라도(실제로 완벽한 분할 규칙은 없습니다) 관련 데이터가 발생할 수 있습니다. 일부 이전 트랜잭션에서는 더 이상 동일한 MySQL 서버에 있지 않습니다.
이 시나리오에서는 애플리케이션이 여전히 이전 솔루션을 따른다고 가정합니다. 그렇다면 이를 해결하기 위해 분산 트랜잭션을 도입해야 합니다. 다양한 MySQL 버전 중 MySQL 5.0부터 시작하는 버전만이 분산 트랜잭션을 지원하기 시작했으며, 현재는 Innodb만이 분산 트랜잭션 지원을 제공하고 있다. 그뿐만이 아닙니다. 분산 트랜잭션을 지원하는 MySQL 버전을 사용하더라도 마찬가지입니다. 동시에 Innodb 스토리지 엔진도 사용되었으며, 분산 트랜잭션 자체가 많은 시스템 리소스를 소비하며 성능 자체도 그리 높지 않습니다. 그리고 분산 트랜잭션의 도입 자체로 인해 예외 처리 측면에서 제어하기 어려운 요소가 더 많아질 것입니다.
어떻게 해야 하나요? 실제로 해결 방법을 통해 이 문제를 해결할 수 있습니다. 가장 먼저 고려해야 할 사항은 데이터베이스가 트랜잭션을 해결할 수 있는 유일한 장소입니까? 실제로는 그렇지 않습니다. 데이터베이스와 애플리케이션을 결합하면 문제를 완전히 해결할 수 있습니다. 각 데이터베이스는 자체 업무를 처리합니다. 그런 다음 애플리케이션을 사용하여 여러 데이터베이스의 트랜잭션을 제어합니다.
즉 말입니다. 우리가 원한다면. 여러 데이터베이스에 걸친 분산 트랜잭션을 단일 데이터베이스에만 존재하는 여러 개의 작은 트랜잭션으로 분할하는 것은 완전히 가능합니다. 그리고 애플리케이션을 사용하여 다양한 소액 거래를 제어할 수 있습니다.
물론 이를 위한 요구 사항은 러시아어 애플리케이션이 충분히 강력해야 한다는 것입니다. 물론, 이는 응용 프로그램에 몇 가지 기술적인 어려움을 가져올 수도 있습니다.
2. Cross-node Join 문제
위에서는 분산 트랜잭션이 발생할 수 있는 문제를 소개했습니다. 이제 Cross-node Join이 필요한 문제를 살펴보겠습니다.
데이터 분할 후. 이로 인해 일부 이전 Join 문이 더 이상 사용되지 않을 수 있습니다. Join에서 사용하는 데이터 소스가 여러 MySQL 서버로 분할될 수 있기 때문입니다.
무엇을 해야 할까요? MySQL 데이터베이스의 관점에서 볼 때 이 문제를 데이터베이스 측에서 직접 해결해야 한다면 MySQL의 특수 스토리지 엔진인 Federated를 통해서만 극복할 수 있지 않을까 걱정됩니다. Federated Storage Engine은 Oracle의 DBLink와 유사한 문제에 대한 MySQL의 솔루션입니다.
과 OracleDBLink의 주요 차이점은 Federated가 원격 테이블 구조의 정의 정보 사본을 로컬에 저장한다는 것입니다. 언뜻 보기에 Federated는 실제로 노드 간 조인에 대한 매우 좋은 솔루션입니다. 그러나 원격 테이블 구조가 변경되면 로컬 테이블 정의 정보도 그에 따라 변경되지 않는 것 같습니다. 원격 테이블 구조를 업데이트할 때 로컬 연합 테이블 정의 정보는 업데이트되지 않는 것으로 가정합니다. Query 실행 오류가 발생하여 올바른 결과를 얻지 못할 가능성이 매우 높습니다.我 이러한 문제를 처리하려면 먼저 응용 프로그램을 통해 처리하는 것이 좋습니다. 먼저 드라이버가 있는 mysqlserver에 해당 운전 결과 세트를 가져옵니다. 그런 다음 드라이버 결과 세트를 기반으로 구동 테이블이 있는 MySQL 서버에서 해당 데이터를 검색합니다. 많은 독자들은 이것이 성능에 어떤 영향을 미칠 것이라고 생각할 수도 있습니다. 그렇습니다. 실제로 성능에 부정적인 영향을 미칠 것입니다. 그러나 이 방법 외에는 기본적으로 더 나은 솔루션이 많지 않습니다.
그리고 데이터베이스가 더 잘 확장되었기 때문에 각 MySQL 서버의 로드를 더 잘 제어할 수 있습니다. 단일 쿼리의 경우 분할되지 않은 전보다 응답 시간이 약간 높아질 수 있으므로 성능에 미치는 부정적인 영향은 그리 크지 않습니다. 말할 것도 없이. 이와 유사한 교차 노드 조인에 대한 요구 사항은 그리 많지 않습니다. 전체적인 성능에 비하면 아주 작은 부분일 수도 있습니다. 따라서 전반적인 성능을 위해 때로는 약간의 희생을 가하는 경우도 있습니다. 실제로 그만한 가치가 있습니다. 결국 시스템 최적화 자체는 많은 절충안과 균형점이 있는 프로세스입니다.
3. 크로스 노드 병합 정렬 및 페이징 문제
데이터가 수평으로 분할되면 정상적으로 실행되지 않는 크로스 노드 조인뿐만 아니라 정렬 및 페이징을 위한 일부 쿼리문의 데이터 소스가 될 수도 있습니다. 여러 노드로 분할될 수도 있습니다. 이로 인한 직접적인 결과는 이러한 정렬 및 페이징 쿼리가 정상적으로 계속 실행될 수 없다는 것입니다. 실제로 이는 교차 노드 조인과 동일합니다. 데이터 소스는 여러 노드에 존재하며, Cross Node Join과 동일한 작업인 Query를 통해 해결해야 합니다. 마찬가지로 Federated도 이 문제를 부분적으로 해결할 수 있습니다. 물론 위험도 있습니다.
그래도 같은 문제가 발생하는데 어떻게 해야 하나요? 그래도 계속해서 응용프로그램을 통해 해결하는 것이 좋습니다.
어떻게 해결하나요? 솔루션 아이디어는 일반적으로 Cross-Node Join 솔루션과 유사하지만 Cross-Node Join과 다른 점이 하나 있습니다. Join에는 운전자 중심 관계가 있는 경우가 많습니다. 따라서 Join 자체와 관련된 여러 테이블 간의 데이터 읽기는 일반적으로 순차적 관계를 갖습니다. 그러나 정렬 페이징의 데이터 소스는 기본적으로 테이블(또는 결과 집합)이라고 할 수 있습니다. 그 자체에는 순차적 관계가 없으므로 여러 데이터 소스에서 데이터를 가져오는 프로세스를 완전히 병렬화할 수 있습니다.
바로 그거예요. 교차 데이터베이스 조인보다 정렬된 페이징 데이터를 검색하는 데 더 높은 효율성을 얻을 수 있습니다. 따라서 발생하는 성능 손실은 상대적으로 적으며 경우에 따라 데이터 분할이 없는 원본 데이터베이스보다 더 효율적일 수 있습니다.
물론, 노드 간 조인이든 노드 간 정렬 및 페이징이든 마찬가지입니다. 결과 세트를 읽고 액세스하고 병합하는 프로세스에는 이전보다 훨씬 더 많은 데이터를 처리해야 하기 때문에 이로 인해 애플리케이션 서버가 많은 다른 리소스, 특히 메모리 리소스를 소비하게 됩니다.
이것을 분석한 후 많은 독자들은 위의 모든 문제가 기본적으로 애플리케이션에 의해 해결된다는 것을 알 수 있습니다. 누구나 마음속으로 불평을 하기 시작할 것입니다. 내가 DBA이기 때문에 애플리케이션 아키텍트와 개발자에게 많은 일이 맡겨진 걸까?
사실 이것은 전혀 사실이 아닙니다. 우선 응용 프로그램의 특수성 때문입니다. 매우 우수한 확장성을 달성하는 것은 매우 쉽지만 데이터베이스는 다릅니다. 확장은 다양한 방법으로 이루어져야 합니다. 그리고 이러한 확장 과정에서 중앙 집중식 데이터베이스에서는 해결할 수 있지만 데이터베이스 클러스터로 분할된 후에는 어려운 문제가 되는 상황을 피하기가 매우 어렵습니다.
???? 데이터베이스 클러스터로 잘 해결할 수 없는 문제를 해결합니다. 요약 데이터 분할 기술을 사용하여 대규모 MySQLServer를 여러 개의 작은 MySQLServer로 분할하면 쓰기 성능 병목 현상 문제를 극복할 수 있을 뿐만 아니라 전체 데이터베이스 클러스터의 확장성이 다시 한 번 향상됩니다. 수직 분할을 통해서든 수평 분할을 통해서든. 이 모든 방법을 사용하면 시스템에서 병목 현상이 발생할 가능성이 줄어듭니다. 특히 수직 및 수평 슬라이싱 방법을 조합하여 사용하면 이론적으로 더 이상 확장 병목 현상이 발생하지 않습니다. 관련 권장 사항:Mysql 데이터베이스 하위 데이터베이스 및 하위 테이블 방법(일반적으로 사용됨)_MySQL
mysql 마스터-슬레이브 데이터베이스, 하위 데이터베이스 및 하위 테이블 Notes_MySQL
Old boy mysql 동영상:MySQL 데이터베이스 다중 인스턴스 시작 문제 해결 방법 및 실제 문제 해결
위 내용은 mysql 데이터베이스 하위 데이터베이스 및 테이블 하위 테이블의 기술적인 어려움을 해결하기 위한 전략의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
