TiDB HTAP 퀵 스타트 가이드

이 가이드에서는 하이브리드 트랜잭션 및 분석 처리(HTAP, Hybrid Transactional and Analytical Processing) TiDB의 원스톱 솔루션을 시작하는 가장 쉬운 방법에 대해 설명한다.

기본 개념

TiDB HTAP를 사용하기 전에 TiDB OLTP(온라인 트랜잭션 처리, Online Transactional Processing)를 위한 행 기반(row-based) 스토리지 엔진인 TiKV와 TiDB OLAP(온라인 분석 처리, Online Analytical Processing)를 위한 열 기반(Columnar storage) 스토리지 엔진인 TiFlash에 대한 몇 가지 기본 지식이 필요하다.

• HTAP 스토리지 엔진: HTAP는 행 기반 스토리지 엔진과 열 기반 스토리지 엔진을 공존한다. 두 스토리지 엔진 모두 데이터를 자동으로 복제하여 강력한 무결성을 유지할 수 있다. 행 기반 스토리지 엔진은 OLTP 성능을 최적화하고, 열 기반 스토리지 엔진은 OLAP 성능을 최적화한다.
• HTAP 데이터 무결성: 분산 트랜잭션 키 값 데이터베이스로서 TiKV는 ACID 호환 트랜잭션 인터페이스를 제공하여 여러 복제본 간의 데이터 무결성과 Raft 컨센서스 알고리즘 구현을 통한 고가용성을 보장한다. TiKV의 열 기반 스토리지 확장으로서 TiFlash는 Raft Learner 컨센서스 알고리즘에 따라 실시간으로 TiKV에서 데이터를 복제한다.
• HTAP 데이터 격리: HTAP 리소스 분리 문제를 해결하기 위해 필요에 따라 TiKV와 TiFlash를 다른 시스템에 배포할 수 있다.
• MPP 컴퓨팅 엔진: MPP는 TiDB 5.0 이상 TiFlash 엔진에서 제공하는 분산 컴퓨팅 프레임워크로, 노드 간의 데이터 교환을 가능하게 하며 고성능, 고 처리량 SQL 알고리즘을 제공한다. MPP 모드를 사용하면 분석 쿼리 실행 시간을 크게 줄일 수 있다.

절차

이 문서에서는 TPC-H 데이터 세트에서 샘플 테이블을 쿼리하여 TiDB HTAP의 편의성과 고성능을 경험할 수 있다. TPC-H는 대량의 데이터와 매우 복잡한 일련의 비즈니스 지향 임시 쿼리로 구성된 일반적인 의사 결정 지원 벤치마크이다. TPC-H를 사용하여 22개의 완전한 SQL 쿼리를 경험하려면 tidb-bench 리포지토리 또는 TPC-H 에 액세스하여 쿼리 문과 데이터를 생성하는 방법을 알아보아라.

1단계. 로컬 테스트 환경 배포

TiDB HTAP를 사용하기 전에 TiDB 데이터베이스 플랫폼의 퀵 스타드 가이드에 설명된 대로 로컬 테스트 환경을 준비하고 다음 명령을 실행하여 TiDB 클러스터를 배포한다.

tiup playground

2단계. 테스트 데이터 준비

다음 절차에서는 TiDB HTAP를 사용하기 위한 테스트 데이터로 TPC-H 데이터 세트를 만들 수 있다. TPC-H에 관심이 있다면 일반적인 구현 가이드을 참조하여라.

1. 다음 명령을 실행하여 테스트 데이터 생성 도구를 설치한다.

   tiup install bench
   

2. 다음 명령을 실행하여 테스트 데이터를 생성한다.

   tiup bench tpch --sf=1 prepare
   

   이 명령의 출력에 Finished가 표시되면 데이터가 생성되었음을 나타낸다.

3. 다음 SQL 문을 실행하여 생성된 데이터를 표시한다.

   SELECT
     CONCAT(table_schema,'.',table_name) AS 'Table Name',
     table_rows AS 'Number of Rows',
     FORMAT_BYTES(data_length) AS 'Data Size',
     FORMAT_BYTES(index_length) AS 'Index Size',
     FORMAT_BYTES(data_length+index_length) AS'Total'
   FROM
     information_schema.TABLES
   WHERE
     table_schema='test';
   

   출력에서 알 수 있듯이 총 8개의 테이블이 만들어지고 최대 테이블에는 650만 행이 있다(데이터가 무작위로 생성되므로 도구에서 만든 행 수는 실제 SQL 쿼리 결과 다르다).

   +---------------+----------------+-----------+------------+-----------+
   |  Table Name   | Number of Rows | Data Size | Index Size |   Total   |
   +---------------+----------------+-----------+------------+-----------+
   | test.nation   |             25 | 2.44 KiB  | 0 bytes    | 2.44 KiB  |
   | test.region   |              5 | 416 bytes | 0 bytes    | 416 bytes |
   | test.part     |         200000 | 25.07 MiB | 0 bytes    | 25.07 MiB |
   | test.supplier |          10000 | 1.45 MiB  | 0 bytes    | 1.45 MiB  |
   | test.partsupp |         800000 | 120.17 MiB| 12.21 MiB  | 132.38 MiB|
   | test.customer |         150000 | 24.77 MiB | 0 bytes    | 24.77 MiB |
   | test.orders   |        1527648 | 174.40 MiB| 0 bytes    | 174.40 MiB|
   | test.lineitem |        6491711 | 849.07 MiB| 99.06 MiB  | 948.13 MiB|
   +---------------+----------------+-----------+------------+-----------+
   8 rows in set (0.06 sec)
   

   이는 상업 주문 시스템의 데이터베이스이다. test.nation 테이블는 국가에 대한 정보를, test.region 테이블는 지역에 대한 정보를, test.part 테이블는 부품에 대한 정보를, test.supplier 테이블는 공급자에 대한 정보를, test.partsupp 테이블는 공급자의 부품에 대한 정보를, test.customer 테이블는 고객에 대한 정보, test.customer 테이블는 주문 정보, test.lineitem 테이블는 온라인 항목에 대한 정보를 나타낸다.

3단계. 행 기반 스토리지 엔진을 사용하여 데이터 쿼리

행 기반 스토리지 엔진만 사용하는 TiDB의 성능을 확인하려면 다음 SQL 문을 실행한다.

SELECT
    l_orderkey,
    SUM(
        l_extendedprice * (1 - l_discount)
    ) AS revenue,
    o_orderdate,
    o_shippriority
FROM
    customer,
    orders,
    lineitem
WHERE
    c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1996-01-01'
AND l_shipdate > DATE '1996-02-01'
GROUP BY
    l_orderkey,
    o_orderdate,
    o_shippriority
ORDER BY
    revenue DESC,
    o_orderdate
limit 10;

이는 배송 우선순위 쿼리이며 지정된 날짜까지 배송되지 않은 최고 수익 주문의 우선순위와 잠재 수익을 제공한다. 잠재적 수익은 l_extendedprice * (1-l_discount) 합계로 정의된다. 주문은 수익 내림차순으로 나열된다. 이 예에서 이 쿼리는 선적되지 않은 주문을 상위 10위까지 나열한다.

4단계. 테스트 데이터를 열 지향 스토리지 엔진에 복제

TiFlash가 배포된 후 TiKV는 데이터를 즉시 TiFlash로 복제하지 않는다. 복제해야 하는 테이블을 지정하려면 TiDB MySQL 클라이언트에서 다음 DDL 문을 실행해야 한다. 그런 다음 TiDB는 그에 따라 지정된 복제본을 TiFlash에 만든다.

ALTER TABLE test.customer SET TIFLASH REPLICA 1;
ALTER TABLE test.orders SET TIFLASH REPLICA 1;
ALTER TABLE test.lineitem SET TIFLASH REPLICA 1;

특정 테이블의 복제 상태를 확인하려면 다음 문을 실행한다.

SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and TABLE_NAME = 'customer';
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and TABLE_NAME = 'orders';
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and TABLE_NAME = 'lineitem';

위의 명령문 결과 :

• AVAILABLE는 특정 테이블의 TiFlash 복제본을 사용할 수 있는지 여부를 나타낸다. 1는 사용할 수 있음을 의미하며 0은 사용할 수 없음을 의미한다. 복제본을 사용할 수 있게 되면 이 상태는 더 이상 변경되지 않는다. DDL 문을 사용하여 복제본 수를 변경하면 복제 상태가 다시 계산된다.
• PROGRESS는 복제 진행 상황을 의미한다. 값은 0.0 ~ 1.0이다. 1은 적어도 하나의 복제본이 복제됨을 의미한다.

5단계. HTAP를 사용하여 데이터를 보다 신속하게 분석

3단계 의 SQL문을 다시 실행하여 TiDB HTAP의 성능을 확인할 수 있다.

TiFlash 복제본이 포함된 테이블의 경우 TiDB 옵티마이저는 비용 견적에 따라 TiFlash 복제본을 사용할지 여부를 자동으로 결정한다. TiFlash 복제본이 선택되어 있는지 여부를 확인 desc 하거나 explain analyze문을 사용할 수 있다. 예를 들면:

explain analyze SELECT
    l_orderkey,
    SUM(
        l_extendedprice * (1 - l_discount)
    ) AS revenue,
    o_orderdate,
    o_shippriority
FROM
    customer,
    orders,
    lineitem
WHERE
    c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1996-01-01'
AND l_shipdate > DATE '1996-02-01'
GROUP BY
    l_orderkey,
    o_orderdate,
    o_shippriority
ORDER BY
    revenue DESC,
    o_orderdate
limit 10;

EXPLAIN명령문의 결과가 ExchangeSender하나 ExchangeReceiver의 연산자를 나타내는 경우 MPP 모드가 사용 가능함을 나타낸다.

또한 전체 쿼리의 각 부분이 TiFlash 엔진만 사용하여 계산되도록 지정할 수 있다. 자세한 내용은 TiDB를 사용하여 TiFlash 복제본 읽기를 참조하여라.

이 두 가지 방법의 쿼리 결과와 쿼리 성능을 비교할 수 있다.

다음은 무엇인가

• TiDB HTAP 아키텍처
• HTAP 조사
• TiFlash 사용