MariaDB의 FederatedX를 소개합니다.

Posted on 2014-12-05 | by gywndi | 1 Comment

Overview

MySQL에는 Federated라는 스토리지 엔진이 있는데, 이는 원격의 테이블에 접근하여 제어하기 위한 용도로 사용됩니다. 얼마 전 이 엔진과 관련하여 재미있는 테스트를 하였는데, 이 내용을 소개하기에 앞서서 간단하게 정리해보도록 하겠습니다.

Features

FederatedX는 사실 MariaDB에서 Federated 엔진을 의미하는데, 이를 다른 이름으로 구분하는 것은 사실 더욱 확장된 기능을 가지기 때문입니다.

원격 서버 접근
원격에 있는 테이블을 로컬에 있는 것처럼 사용
트랜잭션
2-Phase Commit 형태로 데이터의 일관성을 유지
파티셔닝
각 파티셔닝 별로 다른 원격 테이블 참조 가능

Usage

FederatedX 스토리지 엔진은 MariaDB에서는 기본적으로는 활성화되어 있습니다. MySQL에서는 별도의 옵션을 줘야만 활성화되는 것과는 다른 측면이죠.

테이블 생성 방법은 URL/아이디/패스워드를 모두 지정하여 생성하는 방법과, SERVER를 추가해서 사용하는 방법 두 가지가 있습니다.

1) Server 정보를 통한 테이블

CREATE SERVER 구문으로 원격 테이블 접속에 대한 설정을 등록하는 방식입니다. FederatedX 테이블을 사용하기에 앞서서 서버 정보를 등록합니다.

CREATE SERVER 'remote' FOREIGN DATA WRAPPER 'mysql' OPTIONS
(HOST 'remote',
 DATABASE 'target_db',
 USER 'appuser',
 PASSWORD 'passwd123',
 PORT 3306,
 SOCKET '',
 OWNER 'appuser');

위에서 등록한 서버 정보를 활용하여 FederatedX 테이블을 생성합니다.

CREATE TABLE `tb_remote` (
`col01` bigint(20) NOT NULL,
`col02` bigint(20) NOT NULL,
`col03` varchar(20) NOT NULL DEFAULT '',
PRIMARY KEY (`col01`)
) ENGINE=FEDERATED
CONNECTION='remote';

2) URL을 통한 테이블 생성

반드시 위와 같이 서버를 등록하고 FederatedX 테이블을 생성할 필요는 없습니다. 별다른 메타 정보 없이 직접 원격의 서버에 Connection 정보를 명시적으로 선언을 하여 FederatedX 테이블을 생성할 수 있습니다.

CREATE TABLE `tb_local` (
`col01` bigint(20) NOT NULL,
`col02` bigint(20) NOT NULL,
`col03` varchar(20) NOT NULL DEFAULT '',
PRIMARY KEY (`col01`)
) ENGINE=FEDERATED
connection='mysql://target_db:passwd123@remote:3306/target_db/tb_remote';

Connection은 “mysql://사용자:패스워드@호스트:포트/데이터베이스/테이블” 형태로 주면 되겠죠? ^^

3) 파티셔닝 테이블 구성

생성하는 방법을 알았으니, 이제 실제로 테이브을 생성해보도록 해보아요.

각 파티션 별로 직접 커넥션 정보를 명시하여 접근할 수 있겠지만.. 여기서는 서버를 등록하는 방식으로 예를 들도록 할께요.

먼저 서버 정보를 등록합니다.

CREATE SERVER 'remote1' FOREIGN DATA WRAPPER 'mysql' OPTIONS
(HOST 'remote1', 
 DATABASE 'target_db',
 USER 'appuser',
 PASSWORD 'passwd123',
 PORT 3306,
 SOCKET '',
 OWNER 'appuser');

CREATE SERVER 'remote2' FOREIGN DATA WRAPPER 'mysql' OPTIONS
(HOST 'remote2',
 DATABASE 'target_db',
 USER 'appuser',
 PASSWORD 'passwd123',
 PORT 3306,
 SOCKET '',
 OWNER 'appuser');

CREATE SERVER 'remote3' FOREIGN DATA WRAPPER 'mysql' OPTIONS
(HOST 'remote3',
 DATABASE 'target_db',
 USER 'appuser',
 PASSWORD 'passwd123',
 PORT 3306,
 SOCKET '',
 OWNER 'appuser');

그리고, 타 스토리지 엔진의 파티셔닝 테이블을 생성하는 형태로 테이블을 생성합니다.

CREATE TABLE `tb_remote` (
`col01` bigint(20) NOT NULL,
`col02` bigint(20) NOT NULL,
`col03` varchar(20) NOT NULL DEFAULT '',
PRIMARY KEY (`col01`)
) ENGINE=FEDERATED
PARTITION BY RANGE (col01)
(PARTITION p1000 VALUES LESS THAN (1001) CONNECTION='remote1',
 PARTITION p2000 VALUES LESS THAN (2001) CONNECTION='remote2',
 PARTITION p3000 VALUES LESS THAN (3001) CONNECTION='remote3');

아, 여기서 추가로 각 파티셔닝 정의에 Connection 정보, 여기서는 서버 정보를 같이 명시하여 테이블을 생성하면.. FederatedX를 통한 파티셔닝 테이블 완성~! 참 쉽죠잉??

Caution?!!!!

얼뜻, 보면 굉장해 보이는 기능입니다. FederatedX를 사용하면, 원격의 다수의 테이블에 접근을 할 수 있는 형태가 되기 때문, 굉장한 트래픽을 분산 형태로 처리할 수 있다는 기대감을 강력하게 뿜어냅니다. 자, 그럼 서비스에서 사용할 수 있을까요?? 제 대답은 강력한 “NO”입니다. 왜그러나고요?

자 간단하게 아래와 같이 LIMIT구문으로 한 건만 가져오는 쿼리를 실행한다고 한다면.. 특히, 개발 툴에서 누구나 쉽게 아래와 같이 쿼리를 질의를 하겠죠.

select * from tb_remote limit 1;

문제는, 모든 인덱스에 대한 실질적인 정보는 원격에 테이블에 있다는 점에 있습니다. FederatedX는 단지 어떤 식으로 테이블이 구성되어 있다는 대략적인 스키마 정도만 알고 있을 뿐, 결코 원격의 테이블에 있는 데이터 분포도 혹은 핸들러와 같은 오브젝트에 접근할 수 없습니다.

Federated Explain

Federated 경우 데이터가 물리적으로 엄격히 다른 타 서버에 존재하기 때문에, 데이터 처리 시 필요한 모든 데이터를 네트워크로 받아와야 합니다. 즉, 잘못하면 네트워크 대역폭을 한방(?)에 가득 채울 수도 있고, 쿼리 처리 또한 굉장히 버벅댈 수 밖에 없습니다.

Conclusion

지금까지 MariaDB의 Federated 엔진에 대해서 간단하게 살펴보았습니다.

위에서는 주의사항만 말해놓았지만, 사실 분포도가 아주 좋은 인덱스(예를 들면 Primary Key)를 통한 데이터 접근 시에는 전혀 문제가 되지 않습니다. 그렇지만, 모든 상황에서 인덱스를 고집할 수 있는 상황이기 때문에, 서비스에서 조회 용도로 사용하기에는 대단히 위험합니다.

만약 피치못할 사정에 활용을 해야한다면, 이 테이블을 통한 데이터 접근은 반드시 엄격하게 제어를 하여 사용하시기 바랍니다.

TokuDB? Fractal Index에 대해 알아보아요~!

Posted on 2014-05-29 | by gywndi | 1 Comment

이 글은 제가 MySQL Power Group에 예전에 포스팅한 자료입니다.
참고 : http://cafe.naver.com/mysqlpg/189

과거와는 다르게 데이터 사이즈가 비약적으로 커지고 있습니다. 특히, 최근 들어 SNS 서비스가 성황을 이루면서, 개인화된 데이터는 날이 갈수록 기하 급수적으로 늘어나고 있습니다. 최근 Fratical Index 기반의 TokuDB가 오픈 소스로 풀리면서 재조명을 받고 있는데, 이에 대해서 간단하게 설명해보도록 하겠습니다.

B-Tree?

TokuDB에 논하기에 앞서, 전통적인 트리 구조인 B-Tree에 대해 알아보도록 하죠.

일반적으로 RDBMS에서 인덱스는 대부분 B-Tree기반으로 동작하는데, 크게는 “Internal Node”와 “Leaf Node”로 나뉩니다. Internal Node는 데이터를 어느 방향(작으면 왼쪽, 크거나 같으면 오른쪽)으로 보낼 지 결정하는 Pivot과 다음 Pivot의 위치를 알려주는 포인터로 구성됩니다. Internal Node의 가장 마지막 포인터는 Leaf Node를 향하는데, Leaf Node에는 보통은 데이터가 저장이 되죠.

B-Tree

Leaf Node는 트리 특성대로 왼쪽에서 오른쪽으로 순서대로 데이터가 저장되어 있습니다. 이러한 특성으로 트리로 구성된 구조에서는 데이터를 특정 범위를 가져올 수 있는 Range 처리가 가능하죠.

B-Tree는 데이터가 증가를 해도 Pivot을 거치는 횟수가 일정 수치 이상으로는 늘어지는 않습니다. 물론 Pivot 수와 Leaf Node 수는 데이터 증가 수와 비례하여 선형적으로 늘어날 수도 있겠지만, 원하는 Leaf Node에 접근하기 위해 거치는 Pivot 수는 크게 늘지는 않습니다. (비용으로 따진다면.. 1회 데이터 접근이 O(logN)라는 수치가.. 신경은 안쓰셔도 됩니다. ^^)

위 트리에서 Leaf Node에 접근하기 위해 거치는 Pivot 수는 3입니다. 만약 Leaf Node가 8개로 늘어나게 되면 거쳐야 하는 수는 4번이고, 16개이면 5번이 됩니다. 즉, Leaf Node 수(데이터 사이즈)가 현재 수보다 2배 사이즈가 되어야 1회 더 거치게 되는 것이죠.

Leaf Node는 키 순으로 저장이 되어 있다는 것과 Pivot을 통한 데이터 접근이 가능한 B-Tree의 특성으로 단 건 데이터 접근과 특정 범위 처리에 좋은 성능을 보여줍니다.

그러나, 데이터 사이즈가 커지게 되면 B-Tree에도 큰 문제점에 봉착하게 되는데, 메모리 자원은 한계가 있다는 점입니다. 데이터가 커지면 모든 데이터를 메모리에 위치할 수가 없겠죠. 메모리 자원은 한정적이기 때문에, Leaf Node의 대부분은 디스크에 존재할 가능성이 크다. Leaf Node가 디스크에 존재하는 비율이 높아질 수록 해당 데이터를 Read/Write 시 잦은 Disk I/O가 발생할 수 밖에 없습니다.

B-Tree 한계

컴퓨터 시스템 내부에서 가장 느린 성능을 보여주는 것은 바로 디스크로부터 Read/Write을 수행하는 것인데요.. 아무리 좋은 알고리즘을 가지고 데이터를 처리한다 하여도, 잦은 디스크 접근을 통해 동작하게 되면, 게다가 그 동작이 순서가 보장되지 않는 랜덤한 디스크 블록을 읽어야하는 이슈라면 결코 성능이 보장되지 않습니다.

B-Tree 특성 상 트리에 데이터 유입 시 바로 반영을 해주어야 하기 때문에, 메모리가 부족하게 되면 Disk Read/Write에서 즉시 성능 병목 현상이 발생할 수밖에 없는 것이죠.

B-Tree 특성

아무리 CPU 자원이 남아돌아도, Disk I/O Wait으로 인해 처리할 데이터를 메모리에 로딩하지를 못하면, 의미없는 상태입니다. 디스크로부터 데이터를 읽어와야 요청을 처리할 수 밖에 없기 때문이죠. 잦은 Disk I/O Wait.. 이것은 성능 저하를 유발하는 가장 큰 요소입니다.

tokutek에서는 이러한 잦은 디스크 I/O로 인한 문제를 해결하고자 새로운 해결법은 제시하였는데, 그것은 바로 “Fractal Tree”입니다.

Fractal Tree?

그렇다면 Fractal Tree란 무엇일까요?

Fractal Tree는 “Big I/O”에 촛점을 맞춘 자료 구조로, 잦은 Disk I/O를 줄이고, 한번에 다량의 데이터를 하단 노드로 전달함에 따라 데이터가 많은 상황에서도 효과적으로 처리할 수 있는 방안을 제시합니다.

Fractal Tree의 생김새는 B-Tree와 크게 다르지는 않습니다. Fractal Tree는 B-Tree와 같이 Internal Node와 Leaf Node로 구성되어 있고, Leaf Node에는 일반적으로 데이터가 저장되어 있습니다. Internal Node는 데이터를 어느 방향(작으면 왼쪽, 크거나 같으면 오른쪽)으로 보낼 지 결정하는 Pivot과 다음 Pivot의 위치를 알려주는 포인터로 B-Tree와 마찬가지로 구성되나 한가지 특이한 점이 더 추가됩니다. 바로 각 Pivot에는 “Buffer 공간”이 있다는 점이죠.. 바로 아래 그림처럼 말이죠. ^^

Fractal Index

데이터가 유입되면, B-Tree처럼 바로 데이터를 Child Node(Pointer가 가리키는 Node)로 전달하지 않고, Buffer 공간에 저장을 합니다. 그리고 Buffer에 데이터가 가득 차는 순간 Buffer에 쌓인 데이터를 Child Node로 전달하게 됩니다. 버퍼를 어떻게 Child Node에 넘기는 지에 대한 내용은 스킵.. (쵸큼 많이 복잡해서.. 그림 그리기가 힘들어요. ㅠㅠ)

하단 이미지의 왼쪽 트리를 보면, 각 노드마다 버퍼 공간(회색 사각형)이 있습니다. 이 버퍼는 메모리 상에 존재하는 별도의 공간이며, 데이터가 유입 시 바로 자식 노드로 데이터를 내려보지 않고, 일시적으로 버퍼 공간에 보관을 합니다. 만약 하단 트리에서 2, 22 데이터가 유입되면(오른쪽 이미지 참고), 22 노드의 자식 노드로 바로 데이터를 내리지 않고 일시적으로 보관하고 있음을 보여줍니다. (버퍼는 최대 2개의 데이터를 저장할 수 있다고 가정!!)

Fractal Index Insert

이 상태에서 추가로 99 데이터가 들어오게 되면, 하단 그림 1)번과 같이 오른쪽 버퍼 공간에 채워지게 됩니다. 이후 23 데이터가 들어오면, 오른쪽 버퍼에 더 이상 공간이 없게 되므로, 이 순간 데이터를 자식 노드로 내리게 되죠. 이 단계에서 Disk I/O가 발생할 수는 단계이다. 버퍼 공간이 확보되면, 23을 다시 빈 버퍼 공간에 넣게 되며, 최종적으로 23이 Fractal Tree에 저장되게 됩니다.

즉, B-Tree에서 데이터 유입시 매번 자식 노드로 데이터를 보내며 발생하던 잦은 Disk I/O 수가 Fractal Tree에서는 각 노드에 존재하는 버퍼 공간으로 인해 극적으로 감소합니다. 실제로 TokuDB를 사용하고 테스트 데이터를 생성하는 동안, TokuDB의 데이터 사이즈 변화가 크지 않음에 처음에는 의아하기도 하였어요. ^^

한번에 Disk I/O가 발생하기에 얻을 수 있는 점은 I/O 횟수 외에 추가로 더 있습니다. B-Tree에서는 잦은 Random Insert시 Leaf Node의 블록이 단편화되는 현상이 잦아들 수 있겠지만, Fractal Tree에서는 뭉쳐서 Disk I/O를 수행하므로 압축률이 좋을 뿐만 아니라 블록 단편화가 훨씬 줄어들게 되는 것이죠. 물론 InnoDB에서 Barracuda로 압축 포멧으로 테이블을 구성할 수는 있겠지만, 블록 단편화가 많아지는 경우 압축률이 저하될 수밖에 없기에, 얻는 것보다는 오히려 잃는 것이 더 많아질 수 있습니다.ㅜㅜ

Fractal Index 특징

TokuDB에서 Fractal Tree Index는 Message 기반으로 동작을 합니다. 데이터 변화가 발생하더라도, 즉시 Leaf Node로의 전달이 일어나는 것이 아닌, 발생했던 이벤트를 각 노드가 가지는 Buffer에 순차적으로 붙이고, 버퍼가 가득 차게 되면, 자식 노드로 버퍼에 저장된 메시지를 전달합니다.

Fractal Index in TokuDB

위 그림에서 가장 마지막에 수행된 연산은 99번 데이터를 지우라는 것이나, 실제로 Leaf Node에서 즉시 지워지지 않습니다. 이에 대한 이벤트는 메시지 형태로 버퍼에 저장이 되고, 관련 내용은 언젠가는 Leaf Node로 전달되어 적용될 것입니다.

자~! 야심한 이 밤!! 여기까지 정리하도록 하겠습니다. ^^
사실 B-Tree와는 컨셉이 조금 다른지라, 많이 헤매기도 했었지만.. 그림을 그리다보니 여기까지 오게되었네요. -_-;;

저와는 조금 다르게 생각하시는 분은 언제든지 제게 지적질을 해주세요!! 원래 지적 받으며 성장하기 마련..쿨럭~!

예전 포스팅을 새삼 여기에 붙인 이유는 무엇일까요? TokuDB에 대한 내용 2탄을 작성하기 위해서죠. ^^ 어쩌다 보니, TokuDB 를 조금 더 깊에 테스트하게 되었는데, 조만간 정리하여 블로그에 포스팅하도록 하겠습니다.

MySQL의 User Level Lock를 활용한다면?

Posted on 2013-12-02 | by gywndi

Overview

DB에는 크게는 두 가지 타입의 Lock이 있습니다. Table Level Lock, Row Level Lock.. 두 가지 타입의 Lock은 RDBMS에서 대표적인 Lock이라고 지칭할 수 있습니다.

Table Level Lock은 데이터 변경 시 테이블 자체를 Lock을 걸어 안전하게 데이터를 변경하는 방식이고, Row Level Lock은 변경되는 칼럼의 Row에만 Lock을 걸어서 데이터를 조작하는 방식입니다. 일반적인 상황에서는 두 가지의 Lock만으로도 충분히 다양한 사용자의 요구사항을 충족할 수가 있습니다.

그러나, 테이블 파티셔닝을 하는 경우나, 혹은 다양한 서버에 데이터가 분산 저장되는 경우 DB 내적인 제약사항 혹은 데이터 공간 자체의 한계로 인해 상황에 따라 더욱 확장된 Lock이 필요한 경우가 있습니다.

MySQL에서는 User Level Lock 기능을 제공하는데, 오늘은 이것에 관련된 내용을 정리해보도록 합니다.

Why User Level Lock?

User Level Lock에 대해 언급하기에 앞서서 조금 전 언급했던 파티셔닝 시 제약 사항에 대해서 간단하게 짚고 넘어가도록 하죠. ^^

MySQL에서 테이블을 파티셔닝 하게 되면, 단일 테이블로 보여지지만 내부적으로는 수 개의 테이블로 쪼개져서 별도의 테이블로 관리가 됩니다. 즉, 특정 테이블을 10개로 파티셔닝을 하였다면, DB내적으로는 10 개의 테이블을 Merge한 형태로 관리하는 모습을 보여줍니다.

그런데 물리적인 저장소를 분산 저장하기 위해서는 가장 중요한 제약 사항이 있는데, 파티셔닝 키 안에 Primary Key 안에 포함이 되어야 한다는 것입니다. Primary Key가 일반적으로 물리적인 저장소의 주소 역할을 일반적으로 수행하기 때문에 당연한 현상일 수 있겠죠.

여기서, 가장 큰 제약 사항 하나!! 바로 Primary Key 외에 추가로 Unique 속성과 같은 제약 사항을 추가할 수 없다는 것입니다. Foreign Key 도 당연히 추가할 수 없습니다. 어찌 보면, 거대 테이블을 처리하기 위한 일부 기능적인 부분 포기(?)라고 볼 수도 있겠네요. ^^;;

그런 상황 속에서 User Level Lock을 잘~ 활용한다면 단순히 파티셔닝 제약 조건을 뛰어넘어 다수의 서버 환경에서도 적용할 수 있습니다.

User Level Lock?

서론이 너무 길었네요. 이제 User Level Lock에 대해서 정리해보도록 하겠습니다.

User Level Lock이란 사용자가 특정 “문자열”에 Lock을 걸 수 있는 Lock을 의미합니다. 그리고 User Levl Lock 관련 메쏘드는 아래와 같습니다.

GET_LOCK(str,timeout)
문자열 str에 해당하는 Lock을 획득하는 메쏘드. Lock 획득 성공 시 1리턴, timeout 동안 Lock획득 못한 경우 0 리턴, 에러 발생 시 NULL 리턴
IS_FREE_LOCK(str)
문자열 str을 사용할 수 있는 상태인지 체크
IS_USED_LOCK(str)
문자열 str이 사용되고 있는 지 체크
RELEASE_LOCK(str)
str에 걸려있는 Lock을 해제

단, 주의할 점은 User Level Lock은 Client Base가 아닌 Server Base로 동작한다는 점입니다. 당연한 이야기이겠지만, 다수의 클라이언트에서 User Level Lock을 사용하게 되면, 클라이언트가 아닌 서버 측에서 경합이 발생한다는 점입니다. ^^

문자열에 Lock을 걸 수 있는 이 기능을 활용한다면, 앞서 말씀드린 파티셔닝 제약 혹은 물리적인 제약 사항을 극복(?)할 수 있는 솔루션이 될 수 있습니다.

Partitioning Limitation?

테이블 파티셔닝이 반드시 필요한 상황에서 일정 기준으로 유니크 보장도 하고 싶은 경우가 있습니다. 예를 들어 1개월 간 세션 키를 발급하는 경우, 그 기간 동안에는 절대 세션 키가 중복되어서는 안됩니다. 그렇다고 모든 유저에서 발급되는 세션키를 데이터 정리 없이 매번 서버에 적재할 수도 없는 노릇이죠.

이러한 요구 사항 속에서 User Level Lock을 활용하여 제약을 극복해 봅시다.

세션 키를 발급하는 순서는 다음과 같습니다.

테이블 스키마는 아래와 같이 간단하게 정의한다고 가정했을 때,

create table t_sessions(
  user_id int not null,
  s_key varchar(32) not null,
  create_at datetime not null,
  primary key(user_id, create_at),
  key ix_skey(s_key)
) engine=innodb 
partition by range columns(create_at)(
  partition p_201310 values less than ('2013-11-01'),
  partition p_201311 values less than ('2013-12-01'),
  partition p_201312 values less than ('2014-01-01')
)

각 단계 별로 SQL을 간단하게 작성해본다면 다음과 같습니다. 위에서 주목할 사항은 s_key에는 유니크 속성이 없음에도 s_key를 중복 체크를 할 수 있다는 점입니다.

##  1단계
select get_lock('session key', 1);

## 2단계
select 1 from t_sessions
where s_key = 'session key';

## 3단계 (30일 동안 중복 세션 키가 없는 경우)
insert into t_sessions values ('myid','session key',now());

## 4단계
select release_lock('session key');

꽤 많은 코드(?)들을 생략하기는 했지만.. 흐름만 알려드리기 위한 예시라.. 넓은 마음으로 이해해 주세요. ^^;

위 예시를 활용한다면, 파티셔닝 테이블에 Foreign Key 효과도 넣을 수 구현할 수 있겠네요. (이것은 멋진 상상력을 발휘해서 구현해보세요. ㅎ)

Conclusion

User Level Lock은 앞에서의 간단한 파티셔닝 테이블 뿐만 아니라, 전~혀 연관이 없는 테이블 사이의 데이터를 처리하는 데에도 활용할 수 있습니다. 게다가, 동일 서버가 아닌, 다수 서버에서 분산된 데이터를 같이 처리해야하는 경우에도 유용하게 사용할 수 있습니다.

User Level Lock은 사용자가 메쏘드를 통해 특정 문자열에 대하여 Lock을 획득하는 것으로, MySQL 테이블 간 제약 사항을 간단하게 극복할 수 있는 초석이 될 수 있습니다. 적절한 시점에 활용하여, 데이터 신뢰성 향상은 물론 개발 시 스트레스도 줄여보도록 해요. ^^