Korea Digital Contents Society
[ Article ]
Journal of Digital Contents Society - Vol. 23, No. 11, pp.2299-2306
ISSN: 1598-2009 (Print) 2287-738X (Online)
Print publication date 30 Nov 2022
Received 13 Oct 2022 Revised 08 Nov 2022 Accepted 14 Nov 2022
DOI: https://doi.org/10.9728/dcs.2022.23.11.2299

DBMS의 이관을 위한 TiDB의 확장성 및 호환성 검증

김병주1
1네이버시스템(주) I&G 사업본부 이사
Verification of scalability and compatibility of TiDB for DBMS migration
Byung-Ju Kim1
1Director Department of I&G NeighborSystem co., Ltd, Seoul 05717, Korea

Correspondence to: *Byung-Ju Kim E-mail: asella80@neighbor21.co.kr

Copyright ⓒ 2022 The Digital Contents Society
This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-CommercialLicense(http://creativecommons.org/licenses/by-nc/3.0/) which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited.

초록

데이터의 양이 많아짐에 따라 데이터 관리를 위한 DBMS(Data Base Management System)의 중요성이 높아지고 있으며, 데이테베이스 확장의 필요성이 높아진다. 고가의 상용 DBMS를 사용하면 DBMS 확장 문제를 해소될 수 있으나, 오픈소스 DBMS를 사용하면 어려움이 있다. 이에 본 연구에서는 MySQL 계열의 DBMS의 이관 및 호환성이 용이한 TiDB를 소개하고 이를 활용한 실험을 실시하였다. 본 연구에서 적용한 TiDB는 많은 DBMS 중 클라우드를 지원하여 확장성이 우수하고, 대용량 데이터베이스 이관 도구를 제공하는 장점이 있다. 이에 본 연구에서 기존 MariaDB로 구축된 데이터베이스를 TiDB로 이관하고, TiDB의 확장성 및 호환성을 검증하였다. 데이터베이스 이관은 TiDB에서 제공하는 DM Cluster를 사용하여 이관이 용이하였다, TiDB의 확장성을 검증하기 위해 데시보드 및 프로시저 등을 구축하여 실험을 실시하였다. 확장성 검증 결과, 시스템 무중단 상태에서 스토리지 확장이 가능하였다. 또한 호환성 검증은 기존 MariaDB에서 작성한 주요 쿼리문을 TiDB에서 적용하여 호환이 됨을 확인하였다. 본 논문의 실험 결과, Maria DB의 확장이 필요할 경우 TiDB를 활용하며 오픈소스 DBMS의 확장성 한계를 극복함고 동시에 데이터베이스 이관에 대한 위험요소 절감 및 신규 SQL문 작성에 필요한 비용을 절감할 수 있을 것으로 판단된다.

Abstract

As the amount of data increases, the importance of DBMS (Data Base Management System) for data management increases, and the need for database expansion increases. The DBMS extension problem can be solved by using an expensive commercial DBMS, but there are difficulties when using an open source DBMS. Therefore, in this study, TiDB, which is easy to transfer and compatibility with MySQL-type DBMS, was introduced and an experiment was conducted using it. The TiDB applied in this study has the advantage of supporting the cloud among many DBMSs, providing excellent scalability and providing a large-scale database migration tool. Therefore, in this study, the existing database built with MariaDB was transferred to TiDB, and the scalability and compatibility of TiDB were verified. The database migration was easy by using the DM Cluster provided by TiDB. To verify the scalability of TiDB, an experiment was conducted by building a dashboard and procedures. As a result of the scalability verification, it was possible to expand the storage in the non-disruptive state of the system. In addition, compatibility verification confirmed that the main query statements written in MariaDB were applied in TiDB to ensure compatibility. As a result of the experiment in this paper, it is judged that using TiDB when Maria DB extension is required can overcome the scalability limitations of open source DBMS, reduce risk factors for database migration, and reduce the cost of writing new SQL.

Keywords:

Data, Open Source, DBMS, Scaled Horizontally, Compatibility, QL(Query Language)

키워드:

데이터, 오픈소스, 데이터베이스관리시스템, 수평적 확장성, 호환성, 쿼리문

Ⅰ. 서 론

최근 IT 기술들의 급격한 발전으로 인하여 데이터의 양이 기하급수적으로 증가하게 되었다. 스마트폰 보급률이 높아지고 웨어러블 디바이스 및 IoT(Internet of Things) 기술이 높아지면서 데이터들은 하루에도 셀 수 없을 정도로 많은 양 발생하고 있고, 사람들의 모든 행동 또한 데이터화 되어 활용되고 있다. 이로 인해, 처리해야하는 데이터의 양 또한 과거에 비해 급격히 증가하게 되었고, 이를 저장하고 처리하는 능력에 대한 중요성 역시 증가하게 되었다[1].

이와 같은 시대적 환경에 따라 데이터의 효과적인 관리를 위해 DBMS의 필요성이 높아지고 있으며, 최근에는 고가의 상용 DBMS 보다는 오픈소스 소프트웨어 기반의 다양한 DBMS 서비스 개발이 요구되고 있다. 과거의 대표적인 오픈소스 DBMS는 MySQL DBMS 였으나, Sun사(社)가 MySQL DBMS를 인수하였고, 또다시 Oracle사(社)가 인수하였다. 이후 MySQL DBMS를 사용하던 여러 기업들은 MySQL DBMS의 오픈 소스 소프트웨어로서의 많은 장점들이 Oracle사(社)에 의해 경감될 것을 우려하였으며, 실제로 Oracle사(社)는 상용버전의 MySQL DBMS의 소스코드를 공개하지 않음으로써 이러한 우려를 현실화시켰다. 그래서 Google, 카카오 등과 같이 기존 MySQL DBMS를 사용하던 많은 대형 기업들이 또 다른 DBMS인 MariaDB로의 전면 전환을 선언하였다[2].

MariaDB는 MySQL과 같은 오픈소스 관계형 데이터베이스이며, 현재 사용되는 데이터베이스의 대부분은 관계형 데이터베이스를 기반으로 한다. 관계형 데이터베이스는 테이블과 스키마를 가지고 있으며, 트랜잭션을 지원하여 데이터의 무결성을 보장한다[3]. MariaDB에는 새로운 저장 엔진인 아리아(Aria)뿐만 아니라, InnoDB를 교체할 수 있는 XtraDB 저장 엔진을 포함하고 있으며, MariaDB는 MySQL과의 호환성이 뛰어난 편이다[4].

이와 같은 장점으로 인해 MariDB를 많이 사용하고 있으나 점차 DB가 대용량화 되고 있음에 따라 MariaDB의 확장성 한계 문제가 제약 사항으로 나타나고 있다. 관계형 DBMS로 구축된 시스템 중 데이터 가중 시 확장이 불가피 할 경우 크게 2가지의 문제가 발생할 수 있다. 첫 번째 문제는 스케일업이 용이한 분산 DBMS를 택하는 경우 대부분이 NoSQL 형태로 기존 시스템의 SQL 문법을 각 NoSQL 문법으로 변경 된 문법을 검증하기 위해서는 많은 시간이 소요된다. 또한 기존 대용량 데이터베이스를 이관하기 위한 시나리오 수립과 실행에도 많이 시간과 비용이 소요된다. 이와 같은 2가지 부분을 고려했을 때, 기존 시스템의 기능 변경을 최소화하고 이관에 대한 부담을 줄이려면 RDBMS를 지원하며 데이터 이관이 용이해야 한다. 본 연구에서 적용한 TiDB는 이와 같은 어려움을 해소하기 위한 다양한 DBMS 중 클라우드를 지원하여 확장성이 우수하고, 기존 MySQL 문법과 호환성이 높고, 대용량 데이터베이스에 대한 이관 도구를 제공한다. TiDB는 기존 DBMS가 가지고 있는 확장을 할 때 전체 시스템을 중지하고 재 시작해야 하는 불편함이 있으나, TiDB의 경우 운영 중인 상태로 확장이 가능하다는 장점을 가지고 있다. 이 같은 장점은 지금과 같이 클라우드 환경에서 많은 DBMS를 구축하여 사용하는 경우 필요한 용량만큼만 저장 공간을 확장하고 이후 추가 확장하는 경우에는 시스템 중지와 재시작이 불편할 수 있어, 이와 같은 TiDB의 확장 편의성은 효율적인 시스템 운영에 많은 도움이 될 것으로 판단한다. 이에 본 연구에서는 위에 소개한 다양한 장점과 함께 무중단 확장이 가능한 TiDB에 대해 소개하고 TiDB의 확장성 및 호환성을 검증하였다.


Ⅱ. 본 론

2-1 TiDB 소개

TiDB는 HTAP(Hybrid Transactional/Analytical Processing, 하이브리드 트랜잭션 및 분석 처리) 워크로드를 지원하는 오픈소스 분산 확장형 하이브리드 처리 및 분석 처리 데이터베이스이다. TIDB는 MySQL과 호환되며 수평 확장성 및 지속성, 높은 가용성을 지원하고 있다. TiDB의 목표는 OLTP(Online Transaction Processing, 온라인 트랜잭션 처리) 및 OLAP(Online Analytical Processing, 온라인 분석 처리) 및 HTAP 서비스를 포괄하는 원스톱 데이터베이스 솔루션을 사용자에게 제공하는 것이다[5].

HTAP 데이터베이스는 트랜잭션 및 분석 쿼리를 분리하여 처리하여 이들 간의 간섭을 제거해야 한다. 이를 위해서는 두 가지 쿼리 유형에 대해 지정된 데이터의 서로 다른 복제본을 유지 관리하는 것이 필수적이나, 분석 요청이 대규모 및 고가용성으로 트랜잭션 워크로드에서 일관되고 최신 데이터를 효율적으로 읽을 수 있는 스토리지 시스템 내의 분산 복제본에 대한 일관된 보기를 제공하는 것은 어렵다. 이 문제를 해결하기 위해 복제된 상태 머신 기반 합의 알고리즘을 확장하여 HTAP 워크로드에 일관된 복제본을 제공할 것이 Raft 기반 HTAP 데이터베이스인 TiDB의 주요 특징이다[6].

1) 수평확장성(Horizontally scaling)

컴퓨팅을 스토리지에서 분리하는 TiDB 아키텍쳐 설계를 통해 필요에 따라 컴퓨팅 또는 스토리지 용량을 온라인에서 별도로 확장할 수 있다. 확장 프로세스는 애플리케이션 운영 및 유지 관리가 용이하다.

2) 고 가용성(high availability)

데이터는 여러 복제본에 저장된다. 데이터 복제본은 Multi-Raft 프로토콜을 사용하여 트랜잭션 로그를 얻을 수 있다. 데이터가 대부분의 복제본에 성공적으로 기록된 경우에만 트랜잭션을 커밋할 수 있다. 이렇게 하면 소수의 복제본이 다운될 때 강력한 일관성과 가용성을 보장할 수 있다. 다양한 재해 허용 수준의 요구 사항을 충족하기 위해 필요에 따라 지리적 위치와 복제본 수를 구성할 수 있다.

3) Real-time HTAP

TiDB는 행 기반 스토리지 엔진인 TiKV와 열 기반 스토리지 엔진인 TiFlash의 두 가지 스토리지 엔진을 제공한다. TiFlash는 Multi-Raft Leaner 프로토콜을 사용하여 TiKV의 데이터를 실시간을 복제하여 TiKV 행 기반 스토리지 엔진과 TiFlash 열 기반 스토리지 엔진 간의 데이터 일관성을 보장한다. TiKV 및 TiFlash는 HTAP리소스 격리 문제를 해결하기 위해 필요에 따라 다른 시스템에 배포할 수 있다.

4) 클라우드 네이티브 분산 데이터베이스(Cloud-native distributed database)

TiDB는 클라우드용으로 설계된 분산 데이터베이스로 클라우드 플랫폼에서 유연한 확장성, 안전성 및 보안을 제공한다. 사용자는 변화하는 워크로드의 요구 사항에 맞게 TiDB를 탄력적으로 확장할 수 있다. TiDB에서 각 데이터 조각에는 최소 3개의 복제본이 있으며, 전체 데이터 센터의 중단을 허용하기 위해 서로 다른 클라우드 가용성 영역에서 예약할 수 있다. TiDB 오퍼레이터는 Kubernetes에서 TiDB를 관리하고 TiDB 클러스터 운영과 관련된 작업을 자동화하여 관리되는 Kubernetes를 제공하는 모든 클라우드에 TiDB를 더 쉽게 배포할 수 있다. 완전 관리형 TiDB 서비스인 TiDB Cloud는 클라우드에서 TiDB의 모든 기능을 활용할 수 있는 가장 쉽고, 가장 경제적이며, 가장 탄력적인 방법이다. 몇 번의 클릭으로 TiDB 클러스터를 배포하고 실행할 수 있다.

5) 호환성(Compatible with the MySQL 5.7 protocol and MySQL ecosystem)

TiDB는 MySQL 5.7 프로토콜, MySQL의 공통 기능 및 MySQL에코시스템과 호환된다. 애플리케이션을 TiDB로 마이그레이션하기 위해 많은 경우에 한 줄의 코드를 변경할 필요가 없거나 소량의 코드만 수정하면 된다. 또한 TiDB는 애플리케이션 데이터를 TiDB로 쉽게 마이그레이션하는데 도움이 되는 일련의 데이터 마이그레이션 도구를 제공한다.

Fig. 1.

TiDB Architecture(출처 : https://docs.pingcap.com/)

2-2 TiDB 구축

본 연구에서는 TiDB의 확장성과 호환성 검증을 위해 MariaDB에서 구축한 DB를 이관하였다. DB 구축 DBeaver를 사용하였다.

본 연구를 위해서는 MariaDB에 구축되어 있는 데이터베이스를 TiDB로 이관해야 해야 함에 따라 아래 그림 2와 같이 이관의 기본절차인 기존 데이터 받기, 입력 준비, 입력, 확인 절차로 진행하였다.

Fig. 2.

DB migration procedure using DM cluster

데이터 이관은 TiDB에서 제공하는 DM 클러스터를 이용하여 마이그레이션을 하였으며, DB 클러스터는 사전 적합성 검사 기능이 있어 이관 시 발생할 수 있는 오류를 사전에 해결할 수 있는 장점이 있다.

Fig. 3.

DB migration using DM cluster

위의 그림 2,3의 절차와 같이 DB를 이관하여 아래 그림 4와 같이 기존 MariaDB의 데이터가 TiDB에 구축되어 있는 것을 확인할 수 있다.

Fig. 4.

The result of DBMS migration


Ⅲ. TiDB 확장성 및 호환성 검증

본 장에서는 앞 장에서 구축한 TiDB의 확장성과 호환성을 검증하였다. 일차적으로 확장성 검증을 위해 자체 테스트 환경을 구축하여 실제 확장이 효율적으로 되는지를 테스트를 하였으며, 데이터베이스 이관 이후의 활용성을 위해 필요한 호환성 검증을 위해서는 동일한 쿼리문을 MariaDB와 TiDB에 각각 적용하여 검증하였다.

3-1 확장성 검증

본 연구에서 수행한 TiDB의 확장성 평가는 실무에서 TiDB를 선택하는 가장 중요한 요소인 TiDB 스토리지 확장 시 시스템 무중단 확장 환경을 실험하기 위함이다. 이를 실험하기 위해 본 연구에서는 시스템 스토리지 사용상태를 확인할 수 있는 데시보드와 프로시저링을 구축하였다.

시험절차는 데이터베이스에 임의로 데이터의 용량을 증가시킨 후, 스토리지의 가용 할 수 있는 저장 공간이 부족한 경우 무중단 상태에서 데이터베이스의 가용 공간이 확보되는 것을 확인하는 순으로 진행하였다.

Fig. 5.

Dashboard for confirm of Storage Usage

데이터베이스 확장성 검증을 위해 우선, 현재 구축된 데이터의 양을 늘렸을 때 스토리지 용량의 변화를 보여주고, 잔여 용량이 기존에 설정한 용량 하한 임계치 이하로 남았을 경우, 이를 표시해 주는 형태로 진행하였다.

용량을 늘리는 테스트를 위해 임의로 저장된 데이터의 양을 늘리는 방식으로 진행하였다. 초기 용량은 아래 그림 6과 같이 물리 스토리지의 약 14%를 사용 중인 것으로 확인할 수 있으며, 그림 7과 같이 DB 스토리지는 약 17% 사용 중인 것으로 확인할 수 있다. 물리 스토리지에는 메타데이터가 저장되어 있어 실제 DB 용량에 비해 많은 스토리지를 차지한다.

Fig. 6.

Currently storage usage rate(Rate 14%)

Fig. 7.

Currently storage usage rate(Rate 17%)

위와 같은 상황에서 실험을 위해 아래 그림 8과 같이 물리 스토리지 12GB 중 9.5GB의 데이터를 저장할 경우 물리 스토리지가 약 86% 사용 중인 걸로 표시됨을 확인할 수 있다.

Fig. 8.

The storage usage rate after input the data(Rate 86%)

위의 그림 8과 같이 사용용량이 80%를 초과하여 가용 공간이 떨어질 경우 일정 시간이 경과하면 그림 9와 같이 이를 임계치의 초과 주의는 주황색 점선, 임계치 초과 경고는 적색 점선, 시간은 주황색 새로줄 등으로 구분하여 알려주는 기능을 개발하여 DBMS 관리자가 상태를 확인하고 대응할 수 있도록 하였다.

Fig. 9.

Currently storage usage rate(threshold Red Range : Excess 80%)

본 연구에서는 가용 공간의 부족을 해결하기 위해 신규 물리 스토리지를 추가하였다. 아래 그림 10과 같이 기존의 86% 남은 스토리지에 3.2G의 새 물리스토리지(tidb_new)가 추가되었으며, 신규 물리스토리지의 사용률은 11%임을 확인할 수 있다.

Fig. 10.

Add the new Storage

위의 그림 10과 같이 신규 물리스토리지를 추가하면, 전체 DB 스토리지 사용량이 72%로 줄어들어 아래 그림 11과 같이 임계치 이하로 떨어짐을 확인할 수 있다.

Fig. 11.

Free up by adding new physical storage

위의 모든 과정은 데이터베이스가 중지되지 않고 정상 작동 중에 진행됨을 아래 그림 12의 DB Uptime(붉은 색 박스) 스토리지를 통해 확인할 수 있다.

Fig. 12.

TiDB status after extention

3-2 호환성 검증

TiDB는 앞서 설명한 바와 같이 MySQL5.7의 공통 기능과 구문이 매우 높은 호환성을 가지고 있으나, 일부 지원하지 않는 기능이 있다. 다만, 해당 구문의 경우 수요가 부족해 추가적인 개선이 이루어지지 않다는 것은 제조사의 설명이다.

제조사의 홈페이지를 통해 확인할 수 있는 지원되지 않는 기능은 저장 프로시저 및 함수, 트리거, 이벤트, 사용자 정의함수, 옵티마이저 추적 등의 구문이다.

이에 본 연구에서는 기존에 MariaDB에서 구축한 주요 구문이 실제 TiDB에서 사용 가능한지 여부를 검증하였다. 실제많은 SQL문을 작성하였으나, 본 연구에서는 주요 구문 9개를 대상으로 테스트를 수행하였다. 이를 검증하기 위해 동일한 구문을 MariaDB에서 사용했을 때의 결과와 TiDB에서 사용한 결과의 동일성을 검증하였다.

아래 표 1과 같이 MariaDB에서 작성한 주요 SQL 문을 TiDB에서의 호환성을 검증한 결과, 문제없이 사용됨을 확인할 수 있었다.

The Result of Compatibility Verification of TiDB

3-2 호환성 검증

TiDB는 앞서 설명한 바와 같이 MySQL5.7의 공통 기능과 구문이 매우 높은 호환성을 가지고 있으나, 일부 지원하지 않는 기능이 있다. 다만, 해당 구문의 경우 수요가 부족해 추가적인 개선이 이루어지지 않다는 것은 제조사의 설명이다.

제조사의 홈페이지를 통해 확인할 수 있는 지원되지 않는 기능은 저장 프로시저 및 함수, 트리거, 이벤트, 사용자 정의함수, 옵티마이저 추적 등의 구문이다.

이에 본 연구에서는 기존에 MariaDB에서 구축한 주요 구문이 실제 TiDB에서 사용 가능한지 여부를 검증하였다. 실제많은 SQL문을 작성하였으나, 본 연구에서는 주요 구문 9개를 대상으로 테스트를 수행하였다. 이를 검증하기 위해 동일한 구문을 MariaDB에서 사용했을 때의 결과와 TiDB에서 사용한 결과의 동일성을 검증하였다.

아래 표 1과 같이 MariaDB에서 작성한 주요 SQL 문을 TiDB에서의 호환성을 검증한 결과, 문제없이 사용됨을 확인할 수 있었다.


Ⅳ. 결 론

데이터는 현상을 파악하고 이를 기반으로 미래를 예측하기 위한 매우 중요한 요소이다. 이를 위해 정부는 물론 민간에서도 데이터를 모으고 이를 활용하기 위한 다양한 시스템을 개발하고 있다. 특히 기술의 발전 및 시간의 경과로 인해 구축하는 데이터의 양이 매우 많아짐에 따라 DBMS를 탄력적으로 확장하고, 타 DBMS와의 연동할 수 있는 기술이 매우 중요한 시기라고 판단한다.

이에 본 연구에서는 이와 같은 환경을 뒷받침 할 수 있는 DBMS인 TiDB를 소개하고 실제 데이터베이스를 구축하여 제조사에서 강조하는 확장성과 호환성을 검증하였다.

확장성 검증 결과, 기존 MariaDB의 단점이 확장시 시스템을 중지하고 재시작해야 함에 따라 발생하는 불편함이 없이, 즉시 확장된 것을 확인할 수 있고, 제공하는 대시보드 툴을 활용하여 과정에서 발생하는 모든 상황을 모니터링할 수 있었다.

호환성 검증 결과, 제조사에서 밝힌 일부 지원하지 않는 기능이 있음에도 불구하고 MariaDB에서 작성한 주요 쿼리문이 통용됨을 확인할 수 있었다.

본 논문의 시험 결과를 토대로 향후 기존 오픈소스 RDBMS의 확장성 한계를 극복하고, 데이터 이관 이후의 호환성 측면에서 충분한 호환성을 확보하고 있음에 따라, 데이터베이스 이관 및 신규 구축 시 충분히 활용 할 수 있을 것으로 사료된다.

다만, 본 논문은 TiDB에서 제공하는 기본적인 기능을 검증한 한계가 있으며, 향후 추가적인 연구에서 SQL 실행에 대한 속도 등의 성능 향상 방안 및 호환성을 높이는 부분에 대한 추가 연구가 필요할 것으로 사료된다.

Acknowledgments

본 연구는 2022년도 한국연구재단 공공기반 재활운동 빅데이터 플랫폼 기술 개발 사업(NRF2021M3I2A107743012)의 지원에 의하여 이루어진 연구로서, 관계부처에 감사드립니다.

References

  • S.H. Jung, J.C. Kim and C.B. Sim, “A NovelData Prediction Model using Data Weights and Neural Network based on R for Meaning Analysis between Data,” Journal of Korea Multimedia Society, Vol. 18, No. 4, pp. 524-532, April 2015. [https://doi.org/10.9717/kmms.2015.18.4.524]
  • G. J. Yeon, A Study on MariaDB DBMS Performance Improvement, Master's thesis, Soongsil University, Seoul , 2017 6.
  • J. H. Moon, , S.Y. Park, S.J. Woo, and Y.T. Shin, “A Study on the Database Conformance for the Analysis of ICT-Based Environmental Sensors”, in Proceeding of the 52th Fall Conference of Korea Information Processing Society. Jeju, pp. 0185-0187, 2019 11. [https://doi.org/10.3745/PKIPS.y2019m10a.185]
  • R. Y. Jang, J. M Bae, S.J Jung, W. Y. Soh and K. Sung, “Performance Comparison and Analysis between Open-Source DBMS” in Proceeding of the 36th Fall Conference of Korea Institute of information and Communication Engineering. Chunan,, pp.805-808, 2014 10.
  • PingCAP. TiDB Introductione [Internet]. Available: https://docs.pingcap.com/tidb/stable/overview, .
  • Dongxu Huang, Qi Liu, Qiu Cui, Zhuhe Fang, Xiaoyu Ma, Fei Xu, Li Shen, Liu Tang, Yuxing Zhou, Menglong Huang, Wan Wei, Cong Liu, Jian Zhang, Jianjun Li, Xuelian Wu, Lingyu Song, Ruoxi Sun, Shuaipeng Yu, Lei Zhao, Nicholas Cameron, Liquan Pei, Xin Tang, “TiDB: A Raft-based HTAP Database”, Proceedings of the VLDB Endowment, Vol. 13-12, pp 3072–3084, August 2020. [https://doi.org/10.14778/3415478.3415535]

저자소개

김병주(Byung-Ju Kim)

2007년 : 목포대학교 대학원(지적학석사-지적학과)

2014년 : 서울시립대학교 대학원(공학박사수료-공간정보공학)

2018년~2020년: 제이시스 연구소장

2021년~현 재: 네이버시스템 I&G사업본부 이사

※관심분야 : 공간정보(Ged-information), 빅데이터(Big Data) 등

Fig. 1.

Fig. 1.
TiDB Architecture(출처 : https://docs.pingcap.com/)

Fig. 2.

Fig. 2.
DB migration procedure using DM cluster

Fig. 3.

Fig. 3.
DB migration using DM cluster

Fig. 4.

Fig. 4.
The result of DBMS migration

Fig. 5.

Fig. 5.
Dashboard for confirm of Storage Usage

Fig. 6.

Fig. 6.
Currently storage usage rate(Rate 14%)

Fig. 7.

Fig. 7.
Currently storage usage rate(Rate 17%)

Fig. 8.

Fig. 8.
The storage usage rate after input the data(Rate 86%)

Fig. 9.

Fig. 9.
Currently storage usage rate(threshold Red Range : Excess 80%)

Fig. 10.

Fig. 10.
Add the new Storage

Fig. 11.

Fig. 11.
Free up by adding new physical storage

Fig. 12.

Fig. 12.
TiDB status after extention

Tab. 1.

The Result of Compatibility Verification of TiDB

NO Result of Compatibility Verification
1 Kind Create Table
SQL CREATE TABLE test_database.test_table (
    `sequence` BIGINT auto_increment NOT NULL,
    name varchar(100) NOT NULL,
    CONSTRAINT test_table_PK PRIMARY KEY (`sequence`)
)
ENGINE=InnoDB
DEFAULT CHARSET=utf8mb4
COLLATE=utf8mb4_bin;
Result
2 Kind Alter Table
SQL ALTER TABLE test_database.test_table
ADD description varchar(4000) NULL;
Result
3 Kind Create Table Index
SQL CREATE INDEX test_table_name_IDX
USING BTREE ON test_database.test_table (name);
Result
4 Kind Insert Table Data
SQL INSERT INTO test_database.test_table (name, description)
VALUES ('test', 'test query');
Result
5 Kind Update Table Data
SQL UPDATE test_database.test_table
SET description = NULL
WHERE name = 'test';
Result
6 Kind Select Table Data
SQL SELECT *
FROM test_database.test_table
WHERE name like 't%';
Result
7 Kind Query Grouping and Count
SQL_Code SELECT COUNT(*), NOW()
FROM test_database.test_table
WHERE name like 't%' 
GROUP BY name;
Result
8 Kind Delete Table Data
SQL_Code DELETE FROM test_database.test_table
WHERE 1=1;
Result
9 Kind Drop Table Index
SQL DROP TABLE test_database.test_table;
Result