ProxySQL - Sharding

ProxySQL의 샤딩

샤딩은 ProxySQL의 또 다른 주요 사용 사례이며 기본적으로 샤딩에 대한 3x 주요 접근 방식이 있습니다.

• 사용자 기반 샤딩
• 스키마 기반 샤딩
• 데이터 기반 샤딩

다음 예제는 이러한 3x 특정 사용 사례를 다룹니다. 쿼리 규칙은 다른 많은 접근 방식을 지원할 수 있을 만큼 충분히 유연합니다.

사용자 기반 샤딩

이 가장 간단한 형태의 샤딩에서 ProxySQL은 연결에 정의된 "사용자"를 기반으로 적절한 샤드로 쿼리를 라우팅합니다. 우리가 해야 할 일은
"default_hostgroup"과 함께 MySQL 사용자를 정의하는 것뿐입니다. 이 접근 방식에는 쿼리 규칙이 필요하지 않습니다.

예를 들어:

INSERT INTO mysql_users
(username, password, active, default_hostgroup, comment)
VALUES
('accounts', 'shard0_pass', 1, 0, 'Routed to the accounts shard'),
('transactions', 'shard1_pass', 1, 1, 'Routed to the transactions shard'),
('logging', 'shard2_pass', 1, 2, 'Routed to the logging shard');

LOAD MYSQL USERS RULES TO RUNTIME;
SAVE MYSQL USERS RULES TO DISK;

ProxySQL 샤드 레이아웃에 대해 애플리케이션 디자인을 매핑하기 위해 애플리케이션에서 일종의 조회를 유지하는 것이 좋습니다. 예:

+--------------+--------------+-------------+
| app_module   | shard_user   | shard_pass  |
+--------------+--------------+-------------+
| CRM          | accounts     | shard0_pass |
| OLTP         | transactions | shard1_pass |
| Log Manager  | logging      | shard1_pass |
+--------------+--------------+-------------+

스키마 기반 샤딩

스키마 기반 샤딩도 간단합니다. 여기에서 스키마 이름이 "shard_xxx"라고 가정하고 "schemaname"을 적절한 "destination_hostgroup"에 매핑하는 쿼리 규칙을 정의해야 합니다.

INSERT INTO mysql_query_rules (rule_id, active, schemaname,
destination_hostgroup, apply)
VALUES
(1, 1, 'shard_0', 0, 1),
(2, 1, 'shard_1', 1, 1),
(3, 1, 'shard_2', 2, 1);

LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

데이터 기반 샤딩

데이터 기반 샤딩은 가장 복잡한 유형의 샤딩입니다.

• 쿼리가 쿼리 규칙에 맞춰지도록 하는 견고한 설계 원칙을 사용하여 처음부터 애플리케이션을 설계하는 것이 중요합니다.
• 일반적으로 "match_digest" 또는 "match_pattern"을 사용하여 여러 접근 방식을 구현할 수 있습니다.
• 데이터 기반 샤딩을 수행할 때 이는 전체 스키마가 아닌 특정 테이블을 샤딩한다는 의미입니다.

관련 매핑 테이블과 마찬가지로 MySQL 인스턴스에 users기반하여 저장하는 테이블의 간단한 예를 들어 보겠습니다 .locationloc_account_dataloc_mapping

# loc_account_data
+----------------------------------------+---------+---------+
| loc_id                                 | user    | acc_id  |
+----------------------------------------+---------+---------+
| 20086020554955909836090724037181646035 | joe32   | 1       |
| 21503957780049285539986052866765125704 | sam57   | 2       |
| 75863560943999160082133817802533222835 | pam18   | 3       |
+----------------------------------------+---------+---------+

# loc_mapping
+----------------------------------------+---------+
| loc_id                                 | region  |
+----------------------------------------+---------+
| 20086020554955909836090724037181646035 | AMERICA |
| 21503957780049285539986052866765125704 | EMEA    |
| 75863560943999160082133817802533222835 | OCEANIA |
+----------------------------------------+---------+

이제 이 테이블에 대해 실행할 모든 INSERT / UPDATE / DELETE / SELECT 문을 고려해야 합니다. 각 쿼리 다이제스트에 대해 쿼리 규칙을 구현해야 합니다. 예:

- INSERT INTO loc_account_data (loc_id, user, acc_id) VALUES (?, ?, ?);
- UPDATE loc_account_data SET user = ? WHERE loc_id = ? AND acc_id = ?;
- UPDATE loc_account_data SET acc_id = ? WHERE loc_id = ? AND user = ?;
- DELETE FROM loc_account_data WHERE loc_id = ? AND acc_id = ?;
- SELECT * FROM loc_account_data WHERE loc_id = ? AND user = ?;

다음 규칙은 INSERTS에 대한 요구 사항을 충족합니다(INSERTS에 대한 규칙은 UPDATES / DELETES / SELECTS보다 더 많은 INSERTS가 있을 것으로 예상되므로 먼저 구성됨).

INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup,
apply)
VALUES
(1, 1, 'loc_account_data \(loc_id, user, acc_id\) VALUES
\(20086020554955909836090724037181646035', 0, 1),
(2, 1, 'loc_account_data \(loc_id, user, acc_id\) VALUES
\(20086020554955909836090724037181646035’, 1, 1),
(3, 1, 'loc_account_data \(loc_id, user, acc_id\) VALUES
\(20086020554955909836090724037181646035’, 2, 1);

다음 규칙은 UPDATES / DELETES / SELECTS에 대한 요구 사항을 다룹니다.

INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup,
apply)
VALUES
(4, 1, 'loc_id = 20086020554955909836090724037181646035', 0, 1),
(5, 1, 'loc_id = 21503957780049285539986052866765125704', 1, 1),
(6, 1, 'loc_id = 75863560943999160082133817802533222835', 2, 1);

테이블 에 값을 추가할 loc_mapping때 그에 따라 ProxySQL 쿼리 규칙 구성을 동기화해야 합니다.

샤딩 고려 사항

애플리케이션을 "샤딩 친화적"으로 만들기 위해 여전히 일부 논리를 구현해야 합니다.
더 간단한 "사용자" 또는 "스키마" 기반 접근 방식은 구현 및 유지 관리가 더 쉽습니다.
"크로스 샤드" 조인이 필요한 경우 이 논리는 애플리케이션의 일부
– 데이터 기반 샤딩을 구현할 때 샤드당 추가 규칙(예: RW 분할)을 추가해야
합니다.