Mysql 대용량 데이터 저장 및 접근에 대한 설계 논의

1. 소개

인터넷 애플리케이션의 대중화로 인해 대용량 데이터의 저장 및 액세스가 시스템 설계에 병목 현상을 일으키고 있습니다. 대규모 인터넷 애플리케이션의 경우 매일 수십억 개의 PV가 데이터베이스에 상당한 부하를 준다는 것은 의심할 여지가 없습니다. 이는 시스템의 안정성과 확장성에 큰 문제를 일으켰습니다. 데이터 세분화를 통해 웹 사이트 성능을 향상시키기 위해 데이터 계층을 수평으로 확장하는 것은 아키텍처 개발자가 선호하는 방법이 되었습니다. 데이터베이스를 수평으로 샤딩하면 단일 머신의 부하를 줄이고 가동 중지 시간으로 인한 손실을 최소화할 수 있습니다. 로드 밸런싱 전략을 통해 단일 머신의 액세스 로드가 효과적으로 감소하고, 클러스터 솔루션을 통해 읽기-쓰기 분리를 통해 데이터베이스 다운타임으로 인한 단일 지점 데이터베이스 액세스 불가 문제가 해결됩니다. strategy, more 애플리케이션에서 데이터 읽기(Read) 속도와 동시성을 극대화합니다. 현재 다수의 국내 대규모 인터넷 애플리케이션은 Taobao, Alibaba, Tencent와 같은 데이터 분할 솔루션을 사용하고 있으며 대부분은 자체 분산 데이터 액세스 계층(DDAL)을 구현했습니다. 구현 방법과 구현 수준에 따라 크게 두 가지 수준(예: Java 애플리케이션), 즉 JDBC 계층 캡슐화와 ORM 프레임워크 계층 구현으로 나눌 수 있습니다. JDBC 계층의 직접 캡슐화에 관한 한 중국에서 더 잘 개발된 프로젝트 중 하나는 "Amoeba"라는 프로젝트입니다. 이 프로젝트는 Alibaba Group 연구소에서 개발되었으며 아직 테스트 단계에 있습니다(베타 버전). ) 운영 효율성과 생산 적시성을 연구해야 합니다. ORM 프레임워크 계층의 구현과 관련하여 Taobao의 ibatis 및 Spring 기반 분산 데이터 액세스 계층은 수년 동안 사용되어 왔으며 그 운영 효율성과 생산 효율성은 개발자와 사용자로부터 인정을 받았습니다. 이 문서는 ORM 프레임워크 계층을 기반으로 하는 분산 데이터 액세스 계층입니다. 이 주제의 어려움은 최소한의 데이터 마이그레이션으로 데이터베이스 용량 확장(머신 노드 추가) 목적을 달성하는 방법과 같이 라우팅 규칙의 공식화 및 선택과 데이터베이스 분할 후 이후의 확장성에 있습니다. 핵심 문제는 데이터베이스 샤드와 테이블의 라우팅 규칙과 로드 밸런싱 전략을 중심으로 전개됩니다.

2. 기본원리 및 개념

2.1 기본원리 :

인간의 인지적 문제의 과정은 항상 이렇다: 뭐(what) -? 왜(왜)-? 어떻게(How to do it), 다음으로 이 기사에서는 다음 세 가지 문제에 대해 논의하고 연구할 것입니다.

　2.1.1 데이터 분할이란 무엇입니까

　"Shard"라는 단어의 영어 의미는 " 프래그먼트(Fragment)'는 데이터베이스와 관련된 기술 용어로 대규모 다중 접속 온라인 롤플레잉 게임에서 처음 등장한 것으로 보인다. "샤딩"은 가칭 "샤딩"이라고 합니다. 샤딩은 새로운 기술이 아니라 비교적 단순한 소프트웨어 개념입니다. 우리 모두 알고 있듯이 데이터 테이블 분할 기능은 MySQL5 이후에만 사용할 수 있었습니다. 그 전에는 MySQL의 많은 잠재 사용자가 분할 기능이 있는지 여부가 데이터베이스 확장성의 척도가 되었습니다. 지표(물론 유일한 지표는 아닙니다). 데이터베이스 확장성은 영원한 주제입니다. MySQL 프로모터는 다음과 같은 질문을 자주 받습니다. 단일 데이터베이스의 애플리케이션 데이터 처리가 확장되어 분할이 필요한 경우 어떻게 수행할 수 있습니까? 대답은 다음과 같습니다. 샤딩은 특정 데이터베이스 소프트웨어에 붙어 있는 기능이 아니라 특정 기술적 세부 사항을 기반으로 한 추상화입니다. 수평 확장(ScaleOut 또는 수평 확장, 외부 확장)을 위한 솔루션입니다. O 노드 데이터베이스 서버의 용량 제한은 데이터베이스 확장성 문제를 해결합니다.

일련의 Segmentation Rule을 통해 데이터를 서로 다른 DB나 테이블에 수평적으로 분산시키고, 해당 DB 라우팅이나 테이블 라우팅 규칙을 통해 Query 작업이 필요한 특정 DB나 테이블을 찾아 Query 연산을 수행합니다. 여기서 언급되는 "샤딩"은 일반적으로 "수평 슬라이싱"을 의미하며, 이 기사에서도 중점적으로 다루고 있습니다. 어떤 구체적인 분할 및 라우팅 방법이 사용됩니까? 이 시점에서 독자는 필연적으로 질문을 갖게 될 것입니다. 간단한 예를 들어 보겠습니다. 블로그 애플리케이션의 로그를 예로 들어 보겠습니다. , title(varchar(128)),content(varchar(1024)),user_id(int)

이러한 테이블이 나타나면 어떻게 분할합니까? 이러한 데이터를 다른 데이터베이스의 테이블에 배포하는 방법은 무엇입니까? 실제로 블로그 애플리케이션을 분석하면 결론을 내리는 것이 어렵지 않습니다. 블로그 애플리케이션에서 사용자는 방문자와 블로그 소유자라는 두 가지 유형으로 나뉩니다. 시청자가 블로그를 탐색할 때 실제로는 특정 사용자의 블로그 아래를 탐색하고 있는 것이며, 자신의 블로그를 관리하는 블로그 소유자도 특정 사용자의 블로그 아래(자신의 공간)에서 운영하고 있는 것입니다. 소위 특정 사용자는 데이터베이스 필드에서 "user_id"로 표시됩니다. 하위 라이브러리의 기초이자 우리에게 필요한 규칙의 기초가 되는 것이 바로 이 "user_id"입니다. user_id가 1에서 10000 사이인 모든 기사 정보를 DB1의 기사 테이블에 넣고, user_id가 10001에서 20000 사이인 모든 기사 정보를 DB2의 기사 테이블에 넣는 식으로 DBn까지 계속할 수 있습니다. 이런 방식으로 기사 데이터는 자연스럽게 다양한 데이터베이스로 분할되어 데이터 세분화 목적을 달성합니다. 해결해야 할 다음 문제는 특정 데이터베이스를 찾는 방법입니다. 사실 문제는 간단하고 명백합니다. 데이터베이스를 분할할 때 user_id 구별 필드를 사용했기 때문에 여전히 user_id 데이터베이스 라우팅 프로세스가 필수인 것은 당연합니다. 방금 제시한 블로그 애플리케이션을 생각해 보세요. 다른 사람의 블로그에 액세스하든, 내 블로그를 관리하든, 간단히 말해서 이 블로그의 사용자가 누구인지 알아야 합니다. user_id는 데이터베이스를 나눌 때 특정 데이터베이스를 찾는다. 예를 들어 user_id가 234라면 그 사람의 룰을 사용한다면 DB1을 찾아야 한다. 그 사람을 찾으려면 DB2를 찾아야 합니다. 비유적으로 샤딩 규칙은 특정 DB로 역방향 라우팅을 수행하는 데 사용됩니다. 이 프로세스를 "DB 라우팅"이라고 합니다.

물론 데이터 세분화를 고려한 DB 설계는 파격적이고 비정통적인 DB 설계여야 합니다. 그렇다면 정통 DB 디자인은 어떤 DB 디자인일까요?

기본적으로 우리가 정기적으로 사용하는 것입니다. 일반적으로 우리는 패러다임에 따라 데이터베이스를 의식적으로 설계합니다. 로드가 높을 때 읽기 및 쓰기 성능과 처리량을 향상시키기 위해 관련 복제 메커니즘을 사용하는 것을 고려할 수 있습니다. 이 메커니즘 자체는 여전히 상대적으로 분명합니다(아래에 언급됨). 위에서 언급한 “패러다임에 따른 의식적인 디자인”입니다. 데이터 분할의 DB 설계를 고려하면 이러한 일반적인 규칙과 제약 조건을 위반하게 됩니다. 분할하려면 데이터베이스 테이블에 중복 필드가 있어야 하며, 이는 하위 데이터베이스라고 불리는 구분 필드로 사용됩니다. 위의 기사 예에서 user_id와 같은 필드(물론 지금 예에서는 user_id의 중복성을 잘 반영하지 않습니다. user_id 필드는 데이터베이스로 분할되지 않아도 계속 나타나기 때문에 이를 활용했습니다. ). 물론 중복 필드의 출현은 하위 데이터베이스 시나리오에서만 나타나는 것은 아닙니다. 많은 대규모 애플리케이션에서는 중복도 필요합니다. 이는 효율적인 DB 설계와 관련되므로 이 기사에서는 자세히 다루지 않습니다.

　2.1.2 데이터 분할이 필요한 이유

위에서 데이터 분할이 무엇인지에 대한 간단한 설명과 설명을 제공했습니다. 독자들은 데이터 분할이 왜 필요한지 궁금할 것입니다. Oracle과 같은 성숙하고 안정적인 데이터베이스가 대용량 데이터의 저장 및 쿼리를 지원하기에 충분합니까? 데이터 슬라이싱이 필요한 이유는 무엇입니까? 실제로 오라클의 DB는 매우 성숙하고 안정적이지만, 높은 사용료와 고급 하드웨어 지원은 모든 기업이 감당할 수 있는 수준은 아닙니다. 연간 수천만 달러의 사용 비용과 수천만 달러에 달하는 미니컴퓨터의 하드웨어 지원 비용을 상상해 보십시오. 이것이 일반 기업이 감당할 수 있는 수준입니까? 감당할 수 있다고 하더라도 더 나은 솔루션, 더 나은 수평 확장성을 갖춘 더 저렴한 솔루션이 있다면 왜 그것을 선택하지 않겠습니까?

그러나 상황은 항상 만족스럽지 않습니다. 일반적으로 우리는 패러다임에 따라 데이터베이스를 의식적으로 설계합니다. 로드가 높을 때 읽기 및 쓰기 성능과 처리량을 향상시키기 위해 관련 복제 메커니즘을 사용하는 것을 고려할 수 있습니다. 이 메커니즘 자체는 여전히 상대적으로 분명합니다. 우선, 그 효율성은 읽기 작업의 비율에 따라 달라집니다. 쓰기 작업이 실행되기 위해서는 먼저 대기해야 하며, 마스터가 이를 먼저 처리할 수 없습니다. 슬레이브의 용량도 상대적으로 클 수 있으며 쓰기 작업이 마스터에서 실행된 후에도 각 슬레이브 시스템에서 실행되어야 하기 때문에 CPU의 컴퓨팅 성능이 매우 비쌉니다. 현재로서는 샤딩이 쓸모 없게 될 수 있습니다. 복제도 불가능한데 왜 샤딩이 가능할까요? 이유는 간단합니다. 확장성이 좋기 때문입니다. 우리는 각 시스템이 아무리 잘 구성되었더라도 자체적인 물리적 상한선이 있다는 것을 알고 있습니다. 따라서 애플리케이션이 단일 시스템의 특정 상한선에 도달하거나 훨씬 초과한 경우 다른 시스템의 도움을 구하거나 계속 업그레이드할 수만 있습니다. 우리의 하드웨어이지만 일반적인 솔루션은 압력을 공유하기 위해 더 많은 시스템을 추가하여 수평으로 확장하는 것입니다. 또한 비즈니스 로직이 지속적으로 성장함에 따라 기계가 선형적 성장을 통해 수요를 충족할 수 있는지도 고려해야 합니다. 샤딩은 컴퓨팅, 스토리지 및 I/O를 여러 시스템에 병렬로 쉽게 배포할 수 있으므로 단일 실패 지점을 방지하고 시스템 가용성을 제공하며 우수한 오류 격리를 수행하는 동시에 여러 시스템의 다양한 처리 기능을 최대한 활용할 수 있습니다.

위의 요소를 바탕으로 데이터 분할은 매우 필요한데, 여기서 논의하는 데이터 분할도 MySql을 배경으로 사용합니다. 비용을 고려하여 많은 회사에서는 Free 및 Open MySql도 선택했습니다. MySQL에 대해 조금 아는 개발자라면 데이터 테이블 파티셔닝 기능이 MySQL5 이후에만 가능하다는 사실을 알고 있을 것입니다. 그 전에는 MySQL의 많은 잠재 사용자가 MySQL의 확장성에 대해 우려했고, 파티셔닝 기능이 있는지 여부가 핵심 지표가 되었습니다. (물론 유일한 지표는 아님) 데이터베이스의 확장성을 측정합니다. 데이터베이스 확장성은 영원한 주제입니다. MySQL 프로모터는 종종 다음과 같은 질문을 받습니다. 단일 데이터베이스의 애플리케이션 데이터가 확장되어 분할되어야 하는 경우, 이에 대한 대답도 샤딩입니다. 계획.

저희는 무료 MySQL과 저렴한 서버, 심지어 PC까지 클러스터로 활용하여 미니컴퓨터+대형 상업용 DB의 효과를 구현하고, 많은 자본 투자를 절감하며, 운영 비용도 절감해 보는 것은 어떨까요? 따라서 우리는 Sharding을 선택하고 Sharding을 수용합니다.

　2.1.3 데이터 세분화를 이루는 방법

데이터 세분화에 관해서는 다시 한번 데이터 세분화의 방법과 형태를 좀 더 자세히 설명하고 설명하겠습니다.

데이터 세분화는 일련의 세분화 규칙을 통해 여러 DB 서버에 분산될 수 있으며, 이러한 방식으로 각 액세스는 단일 서버가 아닙니다. , 그러나 N개의 서버를 사용하므로 단일 시스템의 로드 압력을 줄일 수 있습니다.

데이터 분할은 데이터베이스 내에서 이루어질 수도 있습니다. 데이터는 일련의 분할 규칙을 통해 데이터베이스의 여러 테이블에 배포됩니다. 예를 들어 기사는 기사_001, 기사_002 및 기타 하위 테이블로 나누어집니다. 하위 테이블은 논리적으로 완전한 기사 테이블을 형성하기 위해 수평으로 결합됩니다. 이것의 목적은 실제로 매우 간단합니다. 예를 들어, 현재 기사 테이블에는 5천만 개의 데이터가 있으며, 이 테이블에 새 데이터를 추가(삽입)해야 합니다. 데이터베이스는 이 테이블을 다시 인덱싱합니다. 5천만 행의 데이터를 생성하고 인덱싱에 따른 시스템 오버헤드를 무시할 수 없습니다. 하지만 반대로 이 테이블을 Article_001부터 Article_100까지 100개의 테이블로 나누면 평균 5천만 행의 데이터가 계산되며 각 하위 테이블에는 50만 행의 데이터만 포함됩니다. 이때 50만 행만 있는 테이블을 추가합니다. 데이터를 삽입한 후 인덱스 생성 시간이 대폭 단축되어 DB의 런타임 효율성이 크게 향상되고 DB의 동시성이 향상됩니다. 물론 샤딩의 이점은 아직 알려지지 않았습니다. 쓰기 작업에 대한 잠금 작업과 같은 명백한 이점도 많이 있습니다.

요약하면 하위 라이브러리는 단일 머신의 부하를 줄이고, 하위 테이블은 데이터 작업의 효율성, 특히 쓰기 작업의 효율성을 향상시킵니다. 이 글을 쓰는 시점에서는 분할 방법에 대한 문제를 아직 다루지 않았습니다. 다음으로 분할 규칙을 자세히 설명하고 설명하겠습니다.

위에서 언급했듯이 데이터의 수평 분할을 달성하려면 분할 및 표시 필드의 기반으로 각 테이블에 중복 문자가 있어야 합니다. 일반적인 응용 프로그램에서는 user_id를 기반으로 구분 필드로 사용합니다. 여기에는 하위 라이브러리의 세 가지 방법과 규칙이 있습니다. (물론 다른 방법도 있을 수 있습니다)

숫자 세그먼트로 구분:

(1) user_id는 구분, 1 ~1000은 DB1에 해당하고, 1001~2000은 DB2에 해당합니다.

장점: 부분 마이그레이션이 가능합니다.

단점: 고르지 않은 데이터 분포

(2) 해시 모듈로 포인트:

user_id를 해시한 다음(또는 user_id가 숫자 유형인 경우 user_id 값을 직접 사용) 특정 숫자를 사용합니다. 예를 들어 애플리케이션이 데이터베이스를 4개의 데이터베이스로 분할해야 하는 경우 4를 사용합니다. 숫자는 user_id%4인 user_id의 해시 값에 대해 모듈로 연산을 수행합니다. 이 경우 각 연산에 ​​대해 4가지 가능성이 있습니다. 결과가 1이면 DB1에 해당하고, 결과가 2이면 해당합니다. 결과가 3이면 DB2에 해당하고, 결과가 0이면 DB4에 해당하므로 데이터가 4개의 DB에 균등하게 분산됩니다.

장점: 데이터가 고르게 분포됨

단점: 데이터 마이그레이션이 번거롭고 시스템 성능에 따라 데이터를 할당할 수 없음

(3) 데이터베이스 구성을 인증 데이터베이스에 저장

DB를 구축하는 것입니다. 이 DB는 데이터베이스에 접근할 때마다 먼저 이 데이터베이스를 쿼리하여 특정 DB 정보를 얻어야 합니다. 우리에게 필요한 쿼리 작업.

장점: 강력한 유연성, 일대일 관계

단점: 각 쿼리 전에 하나의 쿼리가 더 필요하므로 성능이 크게 저하됩니다.

위의 내용은 일반적으로 우리가 개발 중 선택할 수 있는 세 가지 방법이 있으며 일부 복잡한 프로젝트에서는 이 세 가지 방법을 혼합하여 사용할 수 있습니다. 위의 설명을 통해 우리는 서브라이브러리의 규칙도 간단하게 이해할 수 있게 되었습니다. 물론 하위 라이브러리에 대한 더 좋고 완전한 방법이 있을 것이며 우리는 여전히 계속 탐색하고 발견해야 합니다.

3. 본 논의의 기본 개요

위의 본문에서는 인간의 인지 사물의 규칙에 따라 데이터베이스 분할의 몇 가지 개념과 개념을 설명하고 있는데, 어떻게 의미합니까? 몇 가지 기존 분할 규칙에 대한 간략한 소개입니다. 이 주제에서 논의되는 분산 데이터 계층은 단순한 데이터 계층 솔루션이 아니라 어떤 모습일까요? 다음 글에서는 본 연구 주제의 전체적인 아이디어와 구현 방법에 대해 자세히 설명하겠습니다.

분산 데이터 솔루션은 다음과 같은 기능을 제공합니다.

(1) 위에서 언급한 세 가지 분할 규칙을 직접 변환하는 샤딩 규칙 및 라우팅 규칙(RouteRule을 RR이라고 함)을 제공합니다. 이 시스템을 임베드하는 구체적인 임베딩 방법은 다음 내용에서 자세히 설명하고 논의할 것입니다.

(2) 데이터의 고가용성을 보장하기 위한 클러스터(그룹) 개념을 소개합니다. (3) 로드 밸런싱 정책(LB로 축약되는 LoadBalancePolicy)을 도입합니다.

(4) LB 정책이 올바르게 구현되도록 단일 지점 시스템의 가용성을 정기적으로 감지하는 클러스터 노드 가용성 감지 메커니즘을 도입합니다. 높은 수준의 시스템 안정성;

(5) 데이터 쿼리 속도를 향상시키기 위해 읽기/쓰기 분리를 도입합니다.

단지 하위 데이터베이스와 하위 테이블의 데이터 계층 디자인은 그렇지 않습니다. 충분히 완벽합니다. 특정 노드의 DB 서버가 다운되면 어떻게 될까요? 예, 우리는 데이터베이스 분할 방식을 채택했습니다. 이는 완전한 DB를 구성하는 N개의 머신이 있음을 의미합니다. 한 머신이 다운되면 DB에 있는 데이터 중 N/N개만 액세스할 수 없습니다. 적어도 분할 전의 상황보다는 훨씬 나아졌고, 전체 DB에 접근할 수 없게 되는 일은 없을 것입니다. 일반 애플리케이션에서는 이러한 기계 오류로 인해 데이터 접근이 불가능해지는 것이 허용됩니다. 우리 시스템이 고도로 동시 발생하는 전자 상거래 웹사이트라면 어떻게 될까요? 단일 노드 시스템 가동 중지 시간으로 인한 경제적 손실은 매우 심각합니다. 즉, 현재 솔루션에는 여전히 문제가 있으며 내결함성 성능이 테스트를 견딜 수 없습니다. 물론 문제에는 항상 해결책이 있습니다. 여기서는 그룹이라고 부르는 클러스터 개념을 소개합니다. 즉, 각 하위 라이브러리 노드에 여러 머신을 도입합니다. 일반적인 상황에서는 이러한 여러 머신이 로드를 공유합니다. 다운타임이 발생하는 경우 로드 밸런서는 다운된 시스템에 로드를 분산합니다. 이런 방식으로 내결함성 문제가 해결됩니다. 그래서 우리는 클러스터 개념을 도입하고 이를 프레임워크에 포함시켜 프레임워크의 일부가 되었습니다.

위 그림과 같이 전체 데이터 계층은 Group1, Group2, Group3의 세 개의 클러스터로 구성됩니다. 이 세 개의 클러스터는 데이터를 수평적으로 분할한 결과입니다. 물론 이 3개의 클러스터도 완전한 데이터를 담고 있는 DB를 형성한다. 각 그룹에는 1개의 마스터(물론 여러 개의 마스터가 있을 수 있음)와 N개의 슬레이브가 포함됩니다. 이러한 마스터와 슬레이브의 데이터는 동일합니다. 예를 들어, 그룹 1의 슬레이브 하나가 다운되면 두 개의 슬레이브를 사용할 수 있습니다. 이 모델은 전체 그룹의 모든 머신이 다운되지 않는 한 데이터의 특정 부분에 접근할 수 없는 문제를 일으키지 않습니다. 그런 일이 일어날 가능성은 매우 적습니다(정전이 발생하지 않는 한 쉽게 발생하지는 않습니다).

클러스터가 도입되기 전에는 쿼리 프로세스가 대략 다음과 같았습니다. 데이터 계층을 요청하고 필요한 하위 데이터베이스 구별 필드(보통 user_id)를 전달합니까? 데이터 계층이 구별 필드를 기반으로 특정 DB로 라우팅됩니까? 이 결정된 DB 내에서 작업이 수행됩니다. 클러스터가 도입되지 않은 상황은 이렇습니다. 이때 클러스터가 도입된다면 어떤 모습일까요? 그림 1에서 볼 수 있듯이 라우터의 규칙과 정책은 실제로 특정 그룹으로만 라우팅될 수 있습니다. 즉, 가상 그룹으로만 라우팅될 수 있습니다. 이 그룹은 특정 물리적 서버가 아닙니다. 다음으로 해야 할 일은 특정 데이터 작업을 수행할 특정 물리적 DB 서버를 찾는 것입니다. 이 링크의 요구 사항을 기반으로 로드 밸런서(LB) 개념을 도입했습니다. 로드 밸런서의 역할은 특정 DB 서버를 찾는 것입니다. 구체적인 규칙은 다음과 같습니다. 로드 밸런서는 현재 SQL의 읽기 및 쓰기 특성을 분석합니다. 쓰기 작업이거나 강력한 실시간 성능이 필요한 작업인 경우 쿼리 부하를 마스터에 직접 할당합니다. 읽기 작업인 경우 로드 밸런싱 정책을 통해 할당됩니다. 우리 로드 밸런서의 주요 연구 방향은 로드 분산 전략입니다. 일반적으로 로드 밸런싱에는 무작위 로드 밸런싱과 가중 로드 밸런싱이 포함됩니다. 무작위 로드 밸런싱은 이해하기 쉽습니다. 즉, N개의 슬레이브 중에서 하나의 슬레이브를 무작위로 선택하는 것입니다. 이러한 무작위 로드 밸런싱은 시스템 성능을 고려하지 않으며 기본적으로 각 시스템의 성능이 동일합니다. 이것이 실제 상황이라면 그렇게 해도 아무런 문제가 없습니다. 그렇지 않다면 어떻게 될까요? 각 슬레이브 시스템의 물리적 성능과 구성은 다릅니다. 성능을 고려하지 않고 임의 로드 밸런싱을 사용하는 것은 매우 비과학적인 것입니다. 이는 시스템 성능이 좋지 않은 시스템에 불필요하게 높은 로드를 가져오며 심지어 가동 중지 시간의 위험도 초래합니다. 동시에 고성능 데이터베이스 서버는 물리적 성능을 완전히 활용할 수 없습니다. 이러한 고려 사항을 바탕으로 가중치 로드 밸런싱을 도입했습니다. 즉, 시스템 내의 특정 인터페이스를 통해 각 DB 서버에 가중치를 할당한 다음 실행 시 클러스터의 가중치 비율에 따라 LB를 할당하는 것입니다. . 일정 비율의 부하가 DB 서버에 전달됩니다. 물론, 그러한 개념의 도입은 의심할 여지 없이 시스템의 복잡성과 유지 관리 가능성을 증가시킬 것입니다. 득실도 있고 손해도 있고, 우리는 그것을 피할 길이 없습니다.

이제 하위 데이터베이스, 클러스터, 로드 밸런서가 생겼으니 모든 것이 괜찮을까요? 상황은 우리가 생각하는 것만큼 간단하지 않습니다. 이러한 사항을 통해 기본적으로 데이터 계층이 많은 압력을 견딜 수 있도록 보장할 수 있지만 이러한 설계로 데이터베이스 가동 중지 시간의 위험을 완전히 피할 수는 없습니다. Group1의 슬레이브2가 다운되면 시스템의 LB는 이를 알 수 없습니다. LB는 이를 모르고 슬레이브2가 사용 가능한 것으로 생각하여 여전히 슬레이브2에 부하를 할당하기 때문에 이는 실제로 매우 위험합니다. 이런 식으로 문제가 발생하고 클라이언트에서는 자연스럽게 데이터 작업 실패 오류나 예외가 발생하게 됩니다. 이것은 매우 불친절합니다! 이 문제를 해결하는 방법? 클러스터 노드에 대한 가용성 감지 메커니즘 또는 가용성 데이터 푸시 메커니즘을 도입합니다. 이 두 메커니즘의 차이점은 무엇입니까? 먼저 탐지 메커니즘에 대해 이야기해 보겠습니다. 이름에서 알 수 있듯이 탐지는 때때로 클러스터에 있는 각 데이터베이스의 가용성을 시도하는 데이터 계층 클라이언트입니다. 구현 원칙은 데이터베이스 포트에 대한 평가판 액세스입니다. 물론 JDBC를 사용하여 연결을 시도하고 Java의 예외 메커니즘을 사용하여 가용성을 판단할 수도 있습니다. 그렇다면 데이터 푸시 메커니즘은 무엇입니까? 실제로 이 문제는 실제 애플리케이션 시나리오에서 논의해야 하는데, 일반적인 상황에서는 적용된 DB 데이터베이스가 다운되면 DBA가 이를 확실히 알 수 있을 것으로 본다. 클라이언트, 즉 분산 데이터 레이어의 애플리케이션 측에는 이때 로컬 DB 상태 목록이 업데이트됩니다. 그리고 이 데이터베이스 노드를 사용할 수 없음을 LB에 알리고 로드를 할당하지 마십시오. 하나는 능동 모니터링 메커니즘이고, 다른 하나는 수동 알림 메커니즘입니다. 둘 다 나름의 장점이 있습니다. 하지만 모두 동일한 효과를 얻을 수 있습니다. 이렇게 하면 방금 가정한 문제가 발생하지 않더라도 발생 가능성이 최소화됩니다.

위 글에서 언급된 마스터와 슬레이브에 대해서는 아직 자세한 설명을 하지 않았습니다. 그림 1과 같이 그룹은 1개의 마스터와 N개의 슬레이브로 구성됩니다. 왜 이런 일을 하는가? 마스터는 쓰기 작업의 로드를 담당합니다. 즉, 모든 쓰기 작업은 마스터에서 수행되고 읽기 작업은 슬레이브에 할당됩니다. 이렇게 하면 읽기 효율성이 크게 향상될 수 있습니다. 일반적인 인터넷 응용 프로그램에서는 일부 데이터 조사를 통해 읽기/쓰기 비율이 약 10:1이라는 결론을 내렸습니다. 이는 많은 수의 데이터 작업이 읽기 작업에 집중되어 있음을 의미하므로 다중 슬레이브 이유가 있습니다. 그런데 왜 읽기와 쓰기를 분리해야 할까요? DB에 익숙한 R&D 인력은 쓰기 작업에 행 잠금, 테이블 잠금, 블록 잠금 등 잠금 문제가 포함되어 시스템 실행 효율성이 상대적으로 떨어진다는 것을 모두 알고 있습니다. 우리의 분리는 쓰기 작업을 한 노드에 집중하고 읽기 작업은 다른 N 노드에서 수행하는 것입니다. 이를 통해 읽기 효율성이 효과적으로 향상되고 시스템의 고가용성이 보장됩니다. 읽기와 쓰기를 분리하면 마스터의 데이터를 클러스터의 다른 슬레이브 시스템과 동기화하고 일관성을 유지하는 방법과 같은 새로운 문제가 발생합니다. 이는 MySql에 너무 많은 관심을 기울일 필요가 없는 문제입니다. 프록시 메커니즘은 이를 수행하는 데 도움이 될 수 있습니다. 프록시 메커니즘은 이 주제와 그다지 관련이 없으므로 여기서는 자세히 소개하지 않겠습니다.

요약하면, 이번 주제에서 연구한 분산 데이터 레이어의 일반적인 기능은 이렇습니다.