SingleStore Hands-On #6

Jongsoo Noh·2022년 9월 23일
Bottomless DatabaseObject StoragePITRPoint In Time RecoverySingleStoreUnlimited Storage Database
1

SingleStore

목록 보기
9/20
post-thumbnail

개요

SingleStore 는 데이터베이스를 생성할 때 Local Database 또는 Unlimited Storage Database(USD) 를 선택할 수 있습니다.

  • Local : SingleStore 클러스터가 설치된 장비
  • Unlimited Storage : SingleStore 클러스터 외부의 Object Storage

이번 테스트에서는 Unlimited Storage 의 개념 파악 및 기능 테스트를 수행해 보도록 하겠습니다.

Unlimited Storage

Unlimited Storage 를 선택하면 데이터베이스의 크기에 제한이 없어집니다. 그래서 Bottomless 데이터베이스라고 불리기도 합니다. Unlimited Storage Database 를 생성하면 실제 데이터는 지정된 Cloud Service Provider(AWS, GCP, Azure)의 Object Storage 에 저장되고 기존의 SingleStore 클러스터는 해당 데이터의 캐쉬(Cache) 및 처리(Processing) 역할로 변경됩니다.

이에 따라 Online Scale Out/In 작업 시 메타데이터(Metadata)만 이동하면 되므로 실제 데이터의 이동이 수반된 Local Storage 의 리밸런싱에 비해 리밸런싱 소요 시간이 매우 빨라집니다.

데이터가 Unlimited Storage 에 저장될 때는 lz4 방식으로 압축됩니다. 일반적으로 RowStore 는 20배, ColumnStore 는 이미 압축된 상태에서 한번 더 20% 에서 2배 정도 압축된다고 합니다.

또한 Unlimited Storage 를 사용할 경우 PITR(Point in Time Recovery)이 가능해져서 지정된 Retention 시간 이내라면 언제든지 원하는 시점으로 다른 RDBMS 의 Restore/Recovery 에 소요되는 복구 시간을 기다릴 필요없이 특정 마일스톤(Milestone) 이나 특정 시점으로 빠른 시간안에 데이터베이스의 복구가 가능해집니다.

License 고려 사항

Unlimited Storage 및 부가 기능을 사용하기 위해선 필요한 License 의 종류가 달라집니다. 동일한 Unlimited Storage 기능이라도 Oracle Cloud 와 같이 S3 호환 API 를 사용하여 Object Storage 를 사용하는 경우 Self Hosted 방식으로 간주되어 Standard Edition 에서는 사용할 수 없고 Premium Edition 에서만 사용할 수 있습니다.

https://docs.singlestore.com/db/v7.8/en/introduction/singlestoredb-editions.html

기능FreeStandardPremium
Unlimited Storage
(AWS S3, Azure Storage, Google Cloud Storage)		XOO
Unlimited Storage
(self hosted)		XXO
Point-in-Time Recovery (PITR)XXO

기존에 발급받은 Free License 로는 테스트를 할 수 없으므로 이번 테스트에서는 Premium edition 30-day free trial license 를 발급 받아 이용하도록 하겠습니다.

https://www.singlestore.com/on-premises-premium/

License 를 처음 발급받는 경우는 위의 링크를 이용하여 가입하고, 이미 가입이 되어 있는 경우는 portal.singlestore.com 에 로그인합니다.

왼쪽 메뉴에서 On-Prem Licenses 를 클릭한 후 browser 우측 상단에 Try an unlimited capacity 버튼을 클릭합니다.

Job Role 및 Company Name 을 입력하고 Submit 을 클릭합니다.

그러면 30일 기간 한정의 Premium Edition Trial License Key 를 확인할 수 있습니다.

터미널에서 License 를 Premium Edition 으로 교체 설정하고 변경된 License type 을 확인합니다.

sdb-admin set-license --license <Premium License Key>
sdb-admin show-license

Unlimited Storage Database 생성

enable_bottomless 설정

enable_bottomless 변수는 디폴트로 활성화되어 있습니다.

bottomless_gc_retention_period_minutes 설정

bottomless_gc_retention_period_minutes 파라미터는 Unlimited Storage Database 의 변경 사항을 가질 수 있는 최대 시간(단위:분)을 설정합니다.

디폴트로 1440, 즉 1일의 변경분을 가지고 있으며 이 retention 기간 동안은 어느 시점으로로 PITR(Point In Time Recovery)이 가능합니다.

운영 환경에서 이 값을 너무 크게 설정하면 Object Storage 사용량이 상당 부분 커질 수 있으므로 적절하게 조절할 필요가 있습니다.

현재 테스트에서는 변경없이 그대로 사용하겠습니다.

maximum_blob_cache_size_mb 설정

SingleStore 클러스터에서는 Local Database 와 Unlimited Storage Database 를 함께 생성하여 사용할 수 있습니다. Unlimited Storage Database 가 생성되면 기존 클러스터는 캐쉬(Cache) 역할로 변경되어 상당히 공격적으로 디스크를 캐쉬로 채우기 때문에 Local Database 와 함께 사용할 경우 디스크 부족 에러가 발생할 수 있습니다.

따라서 Local Database 를 위한 충분한 디스크 공간을 확보하는 것이 중요하며 이를 조절하는 엔진 변수가 maximum_blob_cache_size_mb 입니다. 해당 변수는 아래와 같이 설정됩니다. Leaf 노드마다 디스크 크기가 다를 수 있으므로 각각 설정해야 합니다. 이번 테스트에서는 10G 로 캐쉬 크기를 지정하겠습니다.

디스크 크기가 40GB 이하 : 40GB
(디스크 크기 * 0.75) 와 (디스크 크기 - 200GB) 중 작은 값

sdb-admin update-config --all --key maximum_blob_cache_size_mb --value 10240 --set-global -y

singlestore -p1234 -e "select * from information_schema.mv_global_variables where variable_name like '%blob_cache_size_mb'"

Bottomless Database 생성

다음 명령어로 Bottomless 데이터베이스를 생성합니다.
<"key"> 와 같이 "key" 부분은 테스트틀 진행하는 환경에 맞춰 변경하시면 됩니다.

  • AWS S3
CREATE DATABASE bottomless_db ON S3 "<bucket>/<folder>"
CONFIG '{"region": "<region>"}'
CREDENTIALS '{"aws_access_key_id":"<access_key>","aws_secret_access_key":"<secret key>"}';
  • Oracle Object Storage
CREATE DATABASE bottomless_db ON S3 "usd/bdb"
CONFIG '{"endpoint_url":"https://<bucket namespace>.compat.objectstorage.<region>.oraclecloud.com/"}'
CREDENTIALS '{"aws_access_key_id":"<access_key>","aws_secret_access_key":"<secret key>"}';

이번 테스트는 Oracle Object Storage 를 이용하여 usd bucket 아래 bdb 폴더에 데이터베이스를 생성합니다.

bottomless_db 가 생성되면 show databases 명령어로 생성된 database 를 확인하고 airportdb 의 booking 테이블을 복제 생성합니다.

$ singlestore -p

CREATE DATABASE bottomless_db ON S3 "usd/bdb"
CONFIG '{"endpoint_url":"https://<bucket namespace>.compat.objectstorage.<region>.oraclecloud.com/"}'
CREDENTIALS '{"aws_access_key_id":"<access_key>","aws_secret_access_key":"<secret key>"}';

show databases;
use bottomless_db;

create table booking as select * from airportdb.booking;

Object Storage Bucket 에는 다음과 같은 폴더가 생성되고 데이터 파일이 저장됩니다.

Offline PITR(Point In Time Recovery)

Offline PITR 은 현재 사용중인 Unlimited Storage Database 를 Detach 후 원하는 시점으로 다시 Attach 하는 개념입니다.
Offline PITR 테스트는 다음과 같은 스텝으로 진행됩니다.

  1. bottomless_db.booking 테이블 건수 확인
  2. PITR 을 위한 마일스톤(milestone) 생성
  3. bottomless_db.booking 테이블 삭제
  4. bottomless_db.booking 테이블 건수 확인
  5. detach database
  6. Attatch database (마일스톤 지정)
  7. bottomless_db.booking 테이블 건수 확인
select count(*) from bottomless_db.booking;
CREATE MILESTONE "Before Deletion" for bottomless_db;

delete from bottomless_db.booking;
select count(*) from bottomless_db.booking;

DETACH DATABASE bottomless_db;

ATTACH DATABASE bottomless_db ON S3 "usd/bdb"
CONFIG '{"endpoint_url":"https://cnp5pmiwobhe.compat.objectstorage.ap-seoul-1.oraclecloud.com/"}'
CREDENTIALS '{"aws_access_key_id":"<access key>","aws_secret_access_key":"<secret key>"}'
AT MILESTONE "Before Deletion";

select count(*) from bottomless_db.booking;


Online PITR(Point In Time Recovery)

Online PITR 은 현재 사용중인 Unlimited Storage Database 는 그대로 운영하는 상태에서 database 를 Object Storage 의 다른 위치로 복사(copy) 한후 다른 Database명으로 원하는 시점 또는 마일스톤으로 Attach 하는 개념입니다.

예를 들어 Oracle 의 경우, 실수로 특정 테이블을 Delete 했을 때 해당 테이블만 delete 이전 시점으로 복구해야 하는 경우가 있습니다. 이럴 땐 Backup File 및 archive log file 을 다른 장비에 Restore 하고 특정 시점으로 불완전 복구 즉 PITR을 수행해야 합니다. 복구한 데이터베이스가 정상적으로 Open 되면 해당 테이블을 export 후 원본 데이터베이스에 다른 테이블명으로 import 한 다음 해당 테이블을 이용하여 원본 데이터를 수정하는 절차를 거치게 됩니다.

SingleStore Unlimited Storage Database 는 Retention 기간동안 변경된 내용이 모두 Object Storage 에 남아 있으므로 Detach 후 다른 위치로 복사한 다음, 다른 데이터베이스 이름으로 Attach 하면 운영본, 복구본의 2개 데이터베이스를 동시에 액세스할 수 있습니다. Attach할 때 원하는 마일스톤이나 시간을 지정하는 방식으로 PITR 을 수행하여 Restore/Recovery 에 긴 시간을 소요하지 않고 거의 즉시 필요한 시점의 데이터를 사용할 수 있습니다. Object Storage Copy 에 드는 시간도 절약해야 한다면 Object Storage Bucket 을 Replicate 하는 기능을 사용하면 훨씬 빠른 시간안에 복구 작업을 완료할 수 있습니다.

Online PITR 테스트는 다음과 같은 스텝으로 진행됩니다.

  1. bottomless_db.booking 테이블 건수 확인
  2. 현재 시간 확인 후 bottomless_db.booking 테이블 삭제
  3. 원본 bottemless_db 에 마일스톤 생성 (Optional, Flush 용도)
  4. Object Storage 에서 bottomless_db 복사
  5. 복사된 bottomless_db 에서 Storage Lock File 삭제
  6. Attatch database to New DBNAME (복구 시점 지정)
  7. 새로 Attach 된 DB 에서 booking 테이블 건수 확인
select count(*) from bottomless_db.booking;

select now();
select sleep(10);
delete from bottomless_db.booking;
select count(*) from bottomless_db.booking;

CREATE MILESTONE "Before Copy" for bottomless_db;

Object Storage 에서 bottomless_db 를 복사합니다.

  • 예제 - bucket_name : usd, folder : bdb, bdb-pitr
  • S3 인 경우 : AWS Console 에서 usd/bdb 를 usd/bdb-pitr 로 복사
  • OCI 인 경우 : rclone 설치 및 S3 호환 object storage 을 등록하고 usd/bdb 를 usd/bdb-pitr 로 복사
$ curl https://rclone.org/install.sh | sudo bash
$ mkdir ~/.config/rclone
$ vi ~/.config/rclone/rclone.conf

# 다음 내용 추가
[oci]
type = s3
provider = Other
access_key_id = <access key>
secret_access_key = <secret key>
endpoint = https://<namespace>.compat.objectstorage.<region>.oraclecloud.com/
acl = private

$ rclone copy oci:/usd/bdb oci:/usd/bdb-pitr 
select distinct storage_id 
  from information_schema.mv_bottomless_status_extended;

복사된 usd/bdb-pitr/<storage_id>/storage_locks/<storage_id> 파일을 삭제합니다.

  • storageid 는 <숫자1><숫자2> 형식으로 구성, 위 SQL 참조
  • storage lock 을 삭제하지 않았을 경우 "attatch database" 명령어 수행시 다음과 같은 에러 메시지 발생

    ERROR 2562 (HY000): Attaching multiple compute sessions to the same remote storage at the same time is currently unsupported. If you wish to perform this attach, consider detaching the currently attached compute session first. If you beleive the currently attached compute session has been lost, consider manually removing the lock file.

Object Storage 에 복사된 usd/bdb-pitr 폴더를 새로운 DB명인 bottomless_pitr_db 로 Attach 합니다.

ATTACH DATABASE bottomless_pitr_db ON S3 "usd/bdb-pitr"
CONFIG '{"endpoint_url":"https://cnp5pmiwobhe.compat.objectstorage.ap-seoul-1.oraclecloud.com/"}'
CREDENTIALS '{"aws_access_key_id":"<access key>","aws_secret_access_key":"<secret key>"}'
AT TIME '2022-09-23 06:02:32'; 
## AT TIME 구문에는 위에서 delete booking 명령어 실행전 now()로 조회된 시간을 지정
 
show databases;
select count(*) from bottomless_pitr_db.booking;

booking 테이블이 삭제되기 전 시점으로 Attach 된 bottomless_pitr_db 에서 해당 테이블을 조회하면 정상적으로 테이블 건수가 확인됩니다.

이것으로 Online PITR(Point In Time Recovery) 테스트를 마무리합니다.
bottomless_pitr_db 는 detach 하고 Object Storage 에서 삭제합니다.

DETACH DATABASE bottomless_pitr_db;

Scale Out / Rebalancing 테스트

Unlimited Storage Database 를 사용할 경우 Scale Out 및 리밸런싱을 Local Database 에서 수행했을 때와 비교합니다.

먼저 bottomless_db.booking 테이블에 데이터를 추가하여 2억건 정도로 만듭니다.

$ singlestore -p

use bottomless_db;

insert into booking select * from airportdb.booking;
insert into booking select * from airportdb.booking;
insert into booking select * from airportdb.booking;

select count(*) from booking;

create node, leaf 노드 추가, rebalancing 을 순차적으로 수행합니다.

sdb-admin create-node --host 127.0.0.1 --port 3308 --password 1234 -y
sdb-admin add-leaf --memsql-id `sdb-admin list-nodes -q -r unknown` -y
singlestore -p1234 -e 'rebalance partitions on bottomless_db'
singlestore -p1234 -e 'select * from information_schema.mv_rebalance_status'

Local Database 와는 달리 Rebalancing 수행 시 copy partition 작업은 3초, promote partition with drop 작업은 6초, 총 10초 정도의 작은 시간만이 소요된 것을 확인할 수 있습니다. 반복적으로 테스트하면 총 4초~10초 정도의 리밸런싱 시간을 측정할 수 있습니다.

다시 Scale In 작업을 수행합니다.

sdb-admin list-nodes
sdb-admin delete-node --memsql-id 6E503584BF --stop -y
singlestore -p1234 -e 'select * from information_schema.mv_rebalance_status'

테스트를 마무리하기 위해 데이터베이스를 detach 하고 Object Storage bucket 을 삭제합니다.

$ singlestore -p

DETACH DATABASE bottomless_db;

마무리

Unlimited Storage Database 는 SingleStore Premium Edition 에서 유용하게 사용할 수 있는 기능입니다. 데이터베이스의 크기의 한계가 사라지고 컴퓨트 노드와 스토리지가 분리되는 Tiered 구조로 인해 Online Scale In/Out 도 유연하게 수행할 수 있으며 빠른 Point In Time Recovery 로 인해 데이터 베이스의 활용도 또한 높아질 수 있습니다.

profile
Jongsoo Noh
Database Guy
이전 포스트

SingleStore Hands-On #5

다음 포스트

SingleStore DB Directory Layout

0개의 댓글