2019.06.28

마이SQL·마리아DB의 '매력 만점' 신기능 7가지

Serdar Yegulalp | InfoWorld
지난 수년간 오픈소스 관계형 데이터베이스 관리 시스템인 마이SQL과 마리아DB는 새롭게 기능을 개선했다. 오랫동안 지속된 문제를 해결했고 전반적으로 성능을 향상하는 등 많은 변화가 있었다.
 
ⓒ Getty Images Bank

변화된 것이 너무 많아 마이 SQL과 마리아DB의 멋진 기능을 잊어버린 사용자가 많을 것이다. 여기서는 마이SQL, 마리아DB 또는 둘 모두에 추가된 신기능 7가지와 이를 사용해야 하는 이유를 살펴보자.

JSON 지원
개발자 편의성과 탄력적인 확장성을 약속하면서 NoSQL 데이터베이스가 등장했을 때 많은 사람이 관계형 데이터베이스 기능을 개발 중인지 궁금해했다. 답은 간단하다. 전혀 그렇지 않았다. NoSQL 시스템은 편리하고 유연하지만 스키마(Scheme)와 테이블(Table)이 항상 자리를 지키고 있다.

게다가 많은 구식 관계형 데이터베이스, 마이SQL, 마리아DB는 NoSQL을 모방하고 JSON 지원을 표준 기능으로 추가했다. 그 덕분에 필요할 때 NoSQL과 함께 같은 데이터베이스 안에 일반적인 SQL도 사용할 수 있다. 예를 들어 마이SQL과 마리아DB의 JSON 지원을 통해 JSON 문서를 특수 설계된 테이블 칼럼에 삽입할 수 있다. 삽입된 JSON 데이터는 다른 데이터 칼럼에 사용한 것과 같은 종류의 설정을 이용해 자동으로 검증할 수 있다. 데이터를 JSON 문서나 단순한 스칼라(Scalar)로 검색할 수 있으며 생성하거나 가상의 칼럼을 이용해 JSON 색인과 비슷한 효과를 낼 수 있다.

그러나 여기에서 기억해야 할 것이 2가지 있다. 우선, 마이SQL마리아DB의 JSON 처리 기능 세트는 유사하지만 서로 간단히 대체할 수는 없다. 둘째, 네이티브 JSON 칼럼 데이터 유형의 마이SQL 및 마리아DB 이행도 다를 수 있다. 이 때문에 약간의 호환성 문제가 발생하며 두 데이터베이스 사이에서 데이터를 마이그레이션하거나 동기화할 때 이 부분을 찾아야 한다.

리소스 그룹(마이SQL만 해당)
모든 데이터베이스 작업은 중요하지만 더 긴급한 것이 있다. 예를 들어, 백그라운드 상태에서 보관이나 예약된 배치 작업 등의 작업을 실행하면서 업무에 필수적인 작업을 가능한 한 신속하게 실행해야 할 때가 있다. 이런 작업은 마이SQL의 리소스 그룹을 이용하면 된다.

예를 들어 리소스 그룹을 통해 유형(“system” 또는 “user”), CPU 관련성, 해당 그룹에 할당된 모든 데이터베이스 작업의 스레드 우선순위 등을 정할 수 있다. 한 세션을 위해 리소스 그룹을 선택하거나 옵티마이저 힌트를 이용해 단일 스테이트먼트용으로 선택할 수 있다. 리소스 그룹은 마이SQL 플랫폼마다 다르게 실행되며 리소스 그룹과 함께 엔터프라이즈 스레드 풀 플러그인을 사용할 수 없다. 또한 마리아DB에서 유사한 기능을 넣어달라는 사용자 요청이 있지만 아직은 계획이 없다.

OQGRAPH 스토리지 엔진(마리아DB만 해당)
그래프(Graph) 데이터베이스를 이용해 관계형 데이터베이스보다 데이터를 잘 저장하고 검색할 수 있다. Neo4j나 아마존 넵튠(Amazon Neptune) 같은 전용 그래프 데이터베이스는 그래프 처리에만 집중하지만 마리아DB는 OQGRAPH 스토리지 엔진을 이용해 그래프 처리와 함께 일반적인 SQL 쿼리도 함께 처리한다. 대부분의 그래프 데이터베이스는 자체적인 맞춤형 쿼리 언어를 사용한다. OQGRAPH의 경우 일반적인 SQL을 이용해 데이터를 불러오고 그래프 쿼리를 구성한다. 결과는 마리아DB의 일반적인 쿼리 형식으로 반환되므로 일반적인 SQL 테이블 쿼리의 결과와 결합하거나 조합할 수 있다.

오라클 호환성 기능(마리아DB만 해당)
오라클의 데이터베이스 제품은 아직도 업계에서 가장 널리 사용되지만 라이선스 비용과 계약상 제한 때문에 많은 사용자가 대체 제품으로 눈을 돌리고 있다. 이 과정에서 오라클을 기반으로 개발한 많은 애플리케이션이 오라클 PL/SQL 전용 기능과 구문을 많이 사용하는 것이 문제가 되기도 한다.

이에 따라 마리아DB는 지난 몇 개의 버전을 거치면서 오라클의 PL/SQL 언어 등 오라클 데이터베이스의 작동 방식을 모방하는 여러 새로운 기능을 도입했다. 이론적으로는 이를 통해 마리아DB에서 기존의 많은 PL/SQL 코드를 그대로 또는 약간의 수정을 거쳐 실행할 수 있다. 마리아DB 개발팀은 호환성 기능을 사용해 레거시 오라클 PL/SQL의 약 80%를 그대로 실행할 수 있다고 설명한다. 오라클 PL/SQL 모드를 사용하기 위한 마리아DB 명령은 클라이언트별로 적용되므로, 이 기능을 사용하기 위해 마리아DB의 작동방식 전체를 바꿀 필요가 없다.
 
시스템 버전 테이블(마리아DB)
SQL 표준의 2011 버전에서 데이터베이스가 테이블 행의 버전을 추적할 수 있는 버전 테이블 기능이 추가됐다. 마리아DB는 버전 10.3.4에서 네이티브 기능으로 이 시스템 버전 테이블을 받아들였다. 마리아DB의 시스템 버전 테이블을 이용하면 주어진 임시 범위를 이용해 쿼리를 실행할 수 있고 제공된 결과는 해당  기간에 대해 표시된다. 또한 데이터 범위에 속하는 행을 수정 또는 삭제, 추적할 기간을 추가, 제거할 수 있고 애플리케이션 수준, 시스템 수준, 두 수준 모두에서 지정된 기간을 이용할 수 있다.

이론적으로 시간 값을 지원하는 모든 데이터베이스에서 이 기능을 사용할 수 있지만 스스로 적용하기는 어려운데 마리아DB가 이를 지원한다. 마리아DB에서는 어느 데이터베이스 엔진에 대해서나 시스템 버전 테이블을 지원한다. 단, 주어진 트랜잭션 중간에 레코드를 보여주는 트랜잭션 정밀 이력 등 기능은 이노DB 엔진에서만 사용할 수 있다.

칼럼스토어(ColumnStore) 스토리지 엔진 / 인피니DB (MariaDB)
마리아DB와 마이SQL의 접속형 스토리지 엔진 기술을 이용하면 두 데이터베이스 모두 네이티브 기능을 크게 확장할 수 있다. 스토리지 엔진 중 하나인 칼럼스토어는 마리아DB를 칼럼식 스토리지 데이터베이스로 바꿔 놓는다(마이SQL에서는 칼럼스토어를 사용할 수 없지만 프로젝트 칼럼스토어는 마이SQL을 이용해 쿼리를 실행하는 인피니DB에서 파생됐다).

칼럼 스토리지는 대용량 데이터의 고속 쿼리 처리에 이상적이다. OLAP 시스템은 칼럼 스토리지를 사용하므로 칼럼스토어는 테라데이터나 그림플럼(Greenplum) 등 외부(그리고 일반적인 상용) 제품에 의존하지 않고 마리아DB 안에서 OLAP 스타일의 기능을 제공한다. 칼럼스토어는 이런 제품에 수반하는 완전한 기성 분석 또는 데이터 보안을 제공하지 않지만 자체 분석 솔루션을 위한 데이터 계층 기능을 지원한다.

스파이더(Spider) 스토리지 엔진
기능이 강력할수록 생산에 배치가 어렵기 마련인데, 그런 기능 중 하나가 데이터베이스 샤딩(Sharding)이다. 여러 서버에서 성능을 개선하기 위해 데이터베이스를 분할하는 것이 또 다른 예인데, 일반적으로 많은 수정과 조정이 필요하다. 그래서 마리아DB 10.3.4(이상)는 샤딩 및 데이터 파티션 기능이 내장된 스토리지 엔진인 스파이더를 통해 이를 쉽게 한다. 스파이더는 단순 연합, 높은 가용성, 샤딩, 샤딩 + 높은 가용성 등 다양한 모드를 지원한다.

스파이더는 일부 기능이 부하 균형, 프록시, 시스템 대체 작동, 높은 가용성을 위한 마리아DB의 시스템인 맥스스케일과 중복된다. 맥스스케일은 스파이더보다 더 광범위하고 야심 찬 사용례를 다루지만 더 일반적인 배치 시 샤딩을 활용하고 싶은 경우 스파이더가 유용하다. 스파이더는 본래 마이SQL 플러그인으로 개발됐으며 여전히 같은 형태로 마이SQL 사용자에게 제공된다. 대부분 기능은 두 버전에서 같고 예외가 몇 가지 있을 뿐이다. ciokr@idg.co.kr



2019.06.28

마이SQL·마리아DB의 '매력 만점' 신기능 7가지

Serdar Yegulalp | InfoWorld
지난 수년간 오픈소스 관계형 데이터베이스 관리 시스템인 마이SQL과 마리아DB는 새롭게 기능을 개선했다. 오랫동안 지속된 문제를 해결했고 전반적으로 성능을 향상하는 등 많은 변화가 있었다.
 
ⓒ Getty Images Bank

변화된 것이 너무 많아 마이 SQL과 마리아DB의 멋진 기능을 잊어버린 사용자가 많을 것이다. 여기서는 마이SQL, 마리아DB 또는 둘 모두에 추가된 신기능 7가지와 이를 사용해야 하는 이유를 살펴보자.

JSON 지원
개발자 편의성과 탄력적인 확장성을 약속하면서 NoSQL 데이터베이스가 등장했을 때 많은 사람이 관계형 데이터베이스 기능을 개발 중인지 궁금해했다. 답은 간단하다. 전혀 그렇지 않았다. NoSQL 시스템은 편리하고 유연하지만 스키마(Scheme)와 테이블(Table)이 항상 자리를 지키고 있다.

게다가 많은 구식 관계형 데이터베이스, 마이SQL, 마리아DB는 NoSQL을 모방하고 JSON 지원을 표준 기능으로 추가했다. 그 덕분에 필요할 때 NoSQL과 함께 같은 데이터베이스 안에 일반적인 SQL도 사용할 수 있다. 예를 들어 마이SQL과 마리아DB의 JSON 지원을 통해 JSON 문서를 특수 설계된 테이블 칼럼에 삽입할 수 있다. 삽입된 JSON 데이터는 다른 데이터 칼럼에 사용한 것과 같은 종류의 설정을 이용해 자동으로 검증할 수 있다. 데이터를 JSON 문서나 단순한 스칼라(Scalar)로 검색할 수 있으며 생성하거나 가상의 칼럼을 이용해 JSON 색인과 비슷한 효과를 낼 수 있다.

그러나 여기에서 기억해야 할 것이 2가지 있다. 우선, 마이SQL마리아DB의 JSON 처리 기능 세트는 유사하지만 서로 간단히 대체할 수는 없다. 둘째, 네이티브 JSON 칼럼 데이터 유형의 마이SQL 및 마리아DB 이행도 다를 수 있다. 이 때문에 약간의 호환성 문제가 발생하며 두 데이터베이스 사이에서 데이터를 마이그레이션하거나 동기화할 때 이 부분을 찾아야 한다.

리소스 그룹(마이SQL만 해당)
모든 데이터베이스 작업은 중요하지만 더 긴급한 것이 있다. 예를 들어, 백그라운드 상태에서 보관이나 예약된 배치 작업 등의 작업을 실행하면서 업무에 필수적인 작업을 가능한 한 신속하게 실행해야 할 때가 있다. 이런 작업은 마이SQL의 리소스 그룹을 이용하면 된다.

예를 들어 리소스 그룹을 통해 유형(“system” 또는 “user”), CPU 관련성, 해당 그룹에 할당된 모든 데이터베이스 작업의 스레드 우선순위 등을 정할 수 있다. 한 세션을 위해 리소스 그룹을 선택하거나 옵티마이저 힌트를 이용해 단일 스테이트먼트용으로 선택할 수 있다. 리소스 그룹은 마이SQL 플랫폼마다 다르게 실행되며 리소스 그룹과 함께 엔터프라이즈 스레드 풀 플러그인을 사용할 수 없다. 또한 마리아DB에서 유사한 기능을 넣어달라는 사용자 요청이 있지만 아직은 계획이 없다.

OQGRAPH 스토리지 엔진(마리아DB만 해당)
그래프(Graph) 데이터베이스를 이용해 관계형 데이터베이스보다 데이터를 잘 저장하고 검색할 수 있다. Neo4j나 아마존 넵튠(Amazon Neptune) 같은 전용 그래프 데이터베이스는 그래프 처리에만 집중하지만 마리아DB는 OQGRAPH 스토리지 엔진을 이용해 그래프 처리와 함께 일반적인 SQL 쿼리도 함께 처리한다. 대부분의 그래프 데이터베이스는 자체적인 맞춤형 쿼리 언어를 사용한다. OQGRAPH의 경우 일반적인 SQL을 이용해 데이터를 불러오고 그래프 쿼리를 구성한다. 결과는 마리아DB의 일반적인 쿼리 형식으로 반환되므로 일반적인 SQL 테이블 쿼리의 결과와 결합하거나 조합할 수 있다.

오라클 호환성 기능(마리아DB만 해당)
오라클의 데이터베이스 제품은 아직도 업계에서 가장 널리 사용되지만 라이선스 비용과 계약상 제한 때문에 많은 사용자가 대체 제품으로 눈을 돌리고 있다. 이 과정에서 오라클을 기반으로 개발한 많은 애플리케이션이 오라클 PL/SQL 전용 기능과 구문을 많이 사용하는 것이 문제가 되기도 한다.

이에 따라 마리아DB는 지난 몇 개의 버전을 거치면서 오라클의 PL/SQL 언어 등 오라클 데이터베이스의 작동 방식을 모방하는 여러 새로운 기능을 도입했다. 이론적으로는 이를 통해 마리아DB에서 기존의 많은 PL/SQL 코드를 그대로 또는 약간의 수정을 거쳐 실행할 수 있다. 마리아DB 개발팀은 호환성 기능을 사용해 레거시 오라클 PL/SQL의 약 80%를 그대로 실행할 수 있다고 설명한다. 오라클 PL/SQL 모드를 사용하기 위한 마리아DB 명령은 클라이언트별로 적용되므로, 이 기능을 사용하기 위해 마리아DB의 작동방식 전체를 바꿀 필요가 없다.
 
시스템 버전 테이블(마리아DB)
SQL 표준의 2011 버전에서 데이터베이스가 테이블 행의 버전을 추적할 수 있는 버전 테이블 기능이 추가됐다. 마리아DB는 버전 10.3.4에서 네이티브 기능으로 이 시스템 버전 테이블을 받아들였다. 마리아DB의 시스템 버전 테이블을 이용하면 주어진 임시 범위를 이용해 쿼리를 실행할 수 있고 제공된 결과는 해당  기간에 대해 표시된다. 또한 데이터 범위에 속하는 행을 수정 또는 삭제, 추적할 기간을 추가, 제거할 수 있고 애플리케이션 수준, 시스템 수준, 두 수준 모두에서 지정된 기간을 이용할 수 있다.

이론적으로 시간 값을 지원하는 모든 데이터베이스에서 이 기능을 사용할 수 있지만 스스로 적용하기는 어려운데 마리아DB가 이를 지원한다. 마리아DB에서는 어느 데이터베이스 엔진에 대해서나 시스템 버전 테이블을 지원한다. 단, 주어진 트랜잭션 중간에 레코드를 보여주는 트랜잭션 정밀 이력 등 기능은 이노DB 엔진에서만 사용할 수 있다.

칼럼스토어(ColumnStore) 스토리지 엔진 / 인피니DB (MariaDB)
마리아DB와 마이SQL의 접속형 스토리지 엔진 기술을 이용하면 두 데이터베이스 모두 네이티브 기능을 크게 확장할 수 있다. 스토리지 엔진 중 하나인 칼럼스토어는 마리아DB를 칼럼식 스토리지 데이터베이스로 바꿔 놓는다(마이SQL에서는 칼럼스토어를 사용할 수 없지만 프로젝트 칼럼스토어는 마이SQL을 이용해 쿼리를 실행하는 인피니DB에서 파생됐다).

칼럼 스토리지는 대용량 데이터의 고속 쿼리 처리에 이상적이다. OLAP 시스템은 칼럼 스토리지를 사용하므로 칼럼스토어는 테라데이터나 그림플럼(Greenplum) 등 외부(그리고 일반적인 상용) 제품에 의존하지 않고 마리아DB 안에서 OLAP 스타일의 기능을 제공한다. 칼럼스토어는 이런 제품에 수반하는 완전한 기성 분석 또는 데이터 보안을 제공하지 않지만 자체 분석 솔루션을 위한 데이터 계층 기능을 지원한다.

스파이더(Spider) 스토리지 엔진
기능이 강력할수록 생산에 배치가 어렵기 마련인데, 그런 기능 중 하나가 데이터베이스 샤딩(Sharding)이다. 여러 서버에서 성능을 개선하기 위해 데이터베이스를 분할하는 것이 또 다른 예인데, 일반적으로 많은 수정과 조정이 필요하다. 그래서 마리아DB 10.3.4(이상)는 샤딩 및 데이터 파티션 기능이 내장된 스토리지 엔진인 스파이더를 통해 이를 쉽게 한다. 스파이더는 단순 연합, 높은 가용성, 샤딩, 샤딩 + 높은 가용성 등 다양한 모드를 지원한다.

스파이더는 일부 기능이 부하 균형, 프록시, 시스템 대체 작동, 높은 가용성을 위한 마리아DB의 시스템인 맥스스케일과 중복된다. 맥스스케일은 스파이더보다 더 광범위하고 야심 찬 사용례를 다루지만 더 일반적인 배치 시 샤딩을 활용하고 싶은 경우 스파이더가 유용하다. 스파이더는 본래 마이SQL 플러그인으로 개발됐으며 여전히 같은 형태로 마이SQL 사용자에게 제공된다. 대부분 기능은 두 버전에서 같고 예외가 몇 가지 있을 뿐이다. ciokr@idg.co.kr

X