들어가기
흔히 스마트-X로 불리는 다양한 분야에서는 센서 데이터 혹은 시계열 데이터로 불리는 산업 빅데이터는 점점 더 많이 발생하고 있으며 , 고객은 이를 다양한 형태의 기술과 소프트웨어를 통해 저장 및 관리하고 있다. 더불어 최근 들어 AI 학습을 위해 데이터를 예전처럼 즉시 폐기 처분하거나, 일정 기간후에 삭제할 수 없는 제약 조건이 있기 때문에 어떻게 이러한 데이터를 잘 관리해야 하는 지가 중요한 이슈가 되었다.
데이터베이스 혹은 일반 Plain Text로 저장된 데이터를 관리하는 뽀족한 방법이 있을까 싶지만, 마크베이스에서 제안하는 신박한 방법이 있기에, 이 방법이 얼마나 효과적일지 한번 알아보도록 하자.
방대하게 쌓인 IIoT 빅데이터 관리의 어려움
전통 데이터베이스 백업 개념의 한계
(데이터가 저장된 곳은 MySQL, MaridDB, MongoDB, influxDB 등와 같은 "데이터베이스"로 한정하도록 하겠다)
보편적으로 데이터베이스가 설치된 장비의 저장소 크기는 한계가 있고, 더이상 접근하지 않을 것이라고 생각하는 오래된 데이터 즉, 콜드 데이터는 백업 후 일반적으로 온라인 데이터베이스에서 백업된 데이터는 삭제하게 된다.
그러나, 백업이라는 데이터베이스 고유의 기능을 활용하여 대용량의 데이터를 관리하고자 하는 경우에는 아래와 같은 몇가지 현실적인 어려움이 있다.
첫째는 백업 대상의 범위를 관리할 수 없다.
전통적인 데이터베이스에서의 백업은 전체 데이터에 대해 백업을 하는 방식(full backup)과 변경된 부분만 백업을 하는 방식 (incremental backup)으로 크게 나뉜다. 이렇게 방식이 나뉘는 이유는 데이터베이스 전체를 매번 백업하는 것이 비효율적일 뿐만 아니라, 이에 소요되는 시간과 리소스도 크게 낭비되기 때문이다. 그러나, 백업에 대한 하지만, IIoT 와 같은 성격의 데이터는 그 특성상 "특정 시간 범위"에 대한 백업도 필요하고, "특정 테이블"에 대한 백업도 필요하다.
두번째는 백업된 데이터의 추출을 위한 복원(Restore)시간이 과도하다. (복원하지 않고는 백업 데이터에 접근할 수 없다)
데이터베이스의 복원의 기본 개념은 데이터베이스 인스턴스를 해당 백업본으로 되돌리는 것이다. 이를 위해 기존에 백업본의 내용을 다시 데이터베이스로 재반영(Redo)하는 과정이 필요하며, 이는 여러가지 환경에 따라 수시간에서도 수일도 걸리는 어마어마한 사건이다. 여하튼 이러한 긴 시간의 복구 과정이 완료되면, 비로소 과거의 데이터를 접근하고, 분석 및 데이터 탐색이 가능해진다.
한편, 이렇게 고유의 백업 기능이 아닌, 특정 테이블이나 데이터베이스 전체에 대해 EXPORT/IMPORT 하는 방법도 있지만, 이 경우 텍스트 형태의 데이터로서 저장 공간이 상상이상으로 많이 차지할 뿐만 아니라, 해당 데이터를 로딩한 후에 인덱싱이 완료되어야 데이터 접근이 가능하기에 이 또한 데이터를 복원한다는 관점에서는 여전히 과도한 시간과 리소스 비용을 필요하는 매우 매우 비현실적인 방법이다.
세번째는 백업을 통한 데이터베이스 복원시 원본 데이터베이스의 변경이 발생한다.
백업의 개념은 해당 시점으로 인스턴스를 되돌리는 것이기 때문에 어쩔 수 없이 현재 데이터베이스의 형상이 변경되며, 최신 데이터의 유지가 불가능하다. 그래서, 백업 데이터에 대한 복원은 대부분의 경우 장애로 인해 원래의 데이터베이스가 문제가 생겼을 경우에만 수행한다.
백업 방식과 데이터 서비스 문제
앞에서 언급한 바와 같이 "데이터베이스 복원"은 원본 데이터베이스의 장애가 발생하며 더이상 활용할 수 없는 장애(?)가 발생한 경우를 위한 기법이다.
그렇지만, 백업된 과거의 데이터를 서비스(혹은 추출)해야 하는 요구 사항이 빈번할 때는 어떻게 해야할까?
저장공간 정책 혹은 백업 정책을 따라 매월 말에 full backup을 하고, 모든 데이터를 삭제하는 정책을 가진 조직이있다고 가정해 보자.
만일, 3개월전 특정일에 생산된 제품의 불량을 감지하고, 그 당시에 어떤 일이 있었는지 데이터를 제출해야 한다면 위의 복원 및 데이터 추출 과정을 위매 매번 몇시간에 걸친 복원 프로세스를 진행해야 한다. 매우 비효율적이고, 느린 방법이나, 이 외에 뽀족한 수가 없다는 것이 문제다.
혹은 AI 분석 조직에서 다양한 조건으로 시간, 센서, 데이터 범위를 주기적으로 요청한다면, 월간으로 백업된 수십개의 백업 화일을 매번 오랜시간동안 복원해서 데이터를 신속하게 제공하기 매우 힘들 것이 분명하다.
즉, 대용량의 데이터에 대해 한번이라도 백업을 한 상태라면, 그 저장된 데이터에 대한 신속한 데이터 서비스(추출)은 기존 기술로는 매우 힘들다고 할 수 있겠다.
새로운 데이터 관리 방식을 상상해보자
저장공간이 무한대가 아니기에 데이터는 어쩔 수 없이 여러번 백업 받을 수 밖에 없지만, 상상의 나래를 펼쳐서 다른 관점으로 이 문제를 바라보도록 하자.
백업시 데이터베이스 전체 혹은 테이블 별로 범위를 지정할 수 있다면 얼마나 좋을까?
이는 백업 범위를 선택할 수 있기에 백업 시간 절약 및 데이터 관리의 편리함을 극대화할 수 있을 것이다.
또한, 불필요한 대상의 데이터는 굳이 백업 범위에 넣지 않을 자유도 생긴다.
백업시 대상에 대해 시간 범위를 줄 수 있으면 얼마나 좋을까?
이는 시계열 특징을 가지는 IoT 혹은 IIoT에서 유래한 센서 데이터의 특성을 가장 잘 반영하는 것이다.
이것이 가능하다면, 백업 대상을 전체가 아닌 시간 축으로 데이터의 일부를 지정할 수 있는 능력이 생기는 것이다.
백업된 데이터를 즉시 복원할 수 있으면 얼마나 좋을까?
이것이야 말로 엄청나게 혁신적인 기술적 진보이다.
6개월치 데이터를 백업하여 2TB의 공간에 저장하였는데, 이를 복원하기 위해 얼마나 긴 시간을 투자해야 하는지 예측하기 어렵다.
또한, 중간에 에러라도 생기면..상상하기 싫은 시나리오일 것이다.
차라리, 백업된 데이터를 복원하는 것이 아니라 화일 시스템처럼 마운트해서 볼 수 있다면?
게임으로 따지면, 이 기능이야말로 "끝판왕" 기능이라고 보이지 않는가?
위에서 잠깐 언금했던 2TB 크기의 백업 화일을 복원하는 것이 아니라 데이터베이스 내부의 다른 데이터베이스로 마운트(mount)하여 데이터를 확인, 검색, 활용, 서비스하고, 필요하지 않다면, 언마운트(umount)를 통해 그 존재를 잊는 것이 가능하다면 그야말로 새로운 차원의 데이터 관리 방법이 될 것이다.
마크베이스 네오의 신박한 IIoT 데이터 관리 방법
아래 그림은 윗절에서 언급했던 새로운 데이터 관리 방법을 마크베이스 네오에서 어떻게 지원하는 지에 대한 간략한 그림이다. (정말?)
위의 그림에서 테이블 A와 B가 온라인상태에 있으며, TIME-0 시점부터 지금까지 실시간으로 데이터를 저장하고 있다고 가정하자. 온라인 상태의 데이터 입력 및 접근은 위의 SQL 처럼 SELECT * from A 혹은 B를 통해 모든 범위의 데이터를 접근할 수 있다.
백업 단계
1. 사용자는 전체 데이터베이스에 대해서 시간 범위 TIME-0부터 TIME-1까지의 모든 데이터를 백업하기로 결정하였다.
2. 그리고, 저장공간을 효율화하기 위해 테이블 B의 시간범위 TIME-0부터 TIME-1까지의 데이터(B1)를 모두 삭제한다.
이 경우 아래와 같은 질의를 통해 백업을 수행하면, 지정된 해당 디렉토리 하부에 백업된 화일의 집합이 생성된다.
BACKUP DATABASE FROM time-0 TO time-1 INTO DISK = '/tmp/MYBKUP'; DELETE FROM B BEFORE time-1;
위 과정이 완료되면, 백업본이 생성되고, 테이블 B의 데이터가 모두 삭제되어, 원래의 목적에 맞게 모든 과정이 수행된 것이다. (위의 백업본은 이후 저렴한 공간인 /backup-store로 옮겨졌다고 하자)
마운트 단계
그리고, 여러가지 이유로 삭제된 테이블 B의 B1에 포함된 데이터에 대한 접근과 데이터 추출이 필요하게 되었다.
바로 이때 백업본을 활용해서 데이터를 즉시 확인하도록 아래와 같이 조치한다.
MOUNT DATABASE '/backup-store/MYBKUP' to newdb;
이 과정에서 백업된 공간의 데이터를 newdb라는 새로운 데이터베이스로 마운트시켰고, 인덱스가 모두 완성된 상태로 모든 접근이 준비된 상태가 된다. (이 과정은 몇초내로 완성된다!!)
활용 단계
앞에서 잠깐 언급한 바와 같이 이 마운트된 데이터베이스는 내부에 데이터 뿐만 아니라 인덱스도 모두 온전한 상태로 복원되었기 때문에 어떤한 시계열 질의가 들어와도 매우 빠르게 수행할 수 있는 놀라운 성능을 보여준다.
한가지 주의할 점은 마운트된 테이블을 지정할 때에는 데이터베이스명.사용자명.테이블명 형태로 모두 기술해 주어야 한다는 것이다.
SELECT * from newdb.sys.B WHERE 여러조건들
위와 같이 newdb라는 테이블에 sys라는 관리자 사용자명과 테이블명 B를 지정해서 데이터를 접근할 수 있다. (당연하지만, 이렇게 마운트된 데이터 영역은 언제나 읽기 전용이라는 것을 참고하자)
이 얼마나 혁명적인 데이터 관리 인터페이스인가?!!
데이터베이스의 특정 공간을 백업하고, 이를 복원과정 없이 "마운트"를 통해 데이터를 즉시 접근할 수 있다는 이 개념은 데이터베이스 역사상 가장 혁신적인 접근 중의 하나라고 감히 생각해본다!
언마운트 단계
이제 모든 데이터 활용을 마쳤다면 아래와 같이 언마운트 명령을 통해 그 존재를 싹 잊도록 할 수 있다.
UNMOUNT DATABASE newdb;
마운트된 데이터베이스의 장점과 고려사항
마운트된 데이터베이스는 데이터 추출 관점에서 온라인의 테이블과 거의 동일하지만, 몇가지 참고해야 할 사항들이 있다.
초고속 데이터 복원 시간
그야말로 눈깜짝할새다. 몇테라의 데이터를 백업을 했더라도 마운트는 순식간에 (길어야 몇초) 추가적인 데이터베이스로 접근 가능한 상태가 된다. 이것이 얼마나 혁명적인 사건이냐 하면, 기존 mysql이나 oracle에 백업된 데이터베이스 화일을 복원하고, 특정 데이터를 추출한다고 생각해보면 금방 깨닫게 된다.
초고속 데이터 접근을 위한 인덱스 유지
마운드된 데이터베이스는 그 자체로 고속의 데이터 접근을 위한 시계열 인덱스가 완벽하게 준비된 상태가 된다. 이는 데이터 복원이라는 원래의 목적에 맞게 데이터의 내부 형태가 백업된 순간의 데이터와 완벽하게 동일한 상태라는 것이다.
완벽하게 동일한 Rollup 구조 유지
마크베이스가 자랑하는 가장 큰 특징 중의 하나는 임의의 시간 범위에 대한 통계 결과를 실시간으로 제공할 수 있다는 것이다. Rollup 테이블을 생성하였다면, 백업시 동일한 모든 데이터 구조가 유지되어 마운트 된 상태에서도 장기간의 통계 자료를 얻을 수 있는 완벽하게 동일한 데이터 접근 환경을 제공한다.
읽기 전용
마운트된 테이블은 제목과 같이 읽기 전용이다. 혹여 유닉스 시스템에서의 화일시스템을 쓰기 모드로도 마운트 할 수 있는 것을 기억하여 착각할 수도 있겠다.
따라서, SELECT 질의만 가능하다고 생각하면 된다. 백업본의 데이터 관리/서비스 입장에서는 당연한 것인데, 만일 백업본을 읽기/쓰기 용으로 활용하고자 한다면, 데이터베이스 전체를 덮어쓰는 복원 과정(Resotre)을 수행해야 한다.
마크베이스 네오의 경우 아래와 같이 복원할 수 있다. (클래식 버젼의 경우 해당 매뉴얼을 참고하자. )
machbase-neo restore --data 마크베이스-홈디렉토리 백업화일-디렉토리명
ex) machbase-neo restore --data /data/machbase_home /tmp/backup
V$마운트테이블 _STAT 제공 불가
실시간으로 갱신되는 태그별 통계 테이블인 V$XX_STAT은 지원되지 않는다. 이는 향후 개선과제이기도 한데 대부분의 경우 태그에서 주로 데이터를 추출하는 목적으로 놓고보면, 큰 문제는 아닐 수 있다.
만일 백업되는 데이터의 크기가 매우 큰 경우에는 백업 이전에 V$모든테이블_STAT을 별도로 다운로드 받아 놓고, 참조하는 것도 좋은 방식일 듯 하다.
백업 활용해 보기
눈으로 보기보다는 이 혁명적인 마운트 기능을 한번씩 따라해 볼 시간이 왔다!
1. 네오 설치 및 neo-apps 소스코드 받기
이 설치관련 내용은 이전의 블로그 내용과 완전히 동일하다. 실제 설치 방법은 이전 블로그의 링크에서 1번(네오 설치)과 2번(neo-apps 다운로드)만을 참조하고, 설치될 마크베이스 네오 버전은 가능하면 8.0.18-rc3a이후의 최신으로 받도록 하자. 그리고, 여기로 다시 돌아오면 된다. (2번부터는 아래의 내용을 다시 따라하면 된다)
마크베이스 네오 설치는 가능하면 8.0.18-rc4 이후의 버전을 사용하도록 하자.
2. backup-mount 디렉토리 확인
neo-apps를 받으면, backup-mount 디렉토리를 발견할 수 있다. 번호가 매겨진 순서대로 테스트를 진행할 것이다.
3. 스키마 생성 및 데이터 입력 확인
backup-mount 데모에서는 두개의 테이블을 각각 생성하고, 각 테이블에 대해 1개씩의 태그가 존재하며, 2023년 1월 1일부터 2023년 3월 31일까지 분당 1개씩의 데이터를 입력하게 된다.
따라서, 아래의 0-Schema Data.wrk을 오픈한 이후 순서대로 스키마를 생성하고, 데이터를 입력해 보자. 데이터 입력은 TQL을 통해 미리 넣을 수 있도록 준비되었다.
위의 붉은색 버튼을 순서대로 누르면, 스키마 생성 및 데이터 입력이 각 테이블마다 129600건씩 입력이 완료된다. (1번의 경우 두개의 테이블이 생성되므로, 커서를 각각의 라인에 올려서 두번 클릭하면 된다)
아래와 같이 입력된 데이터 건수를 확인할 수 있다. (8.0.18-rc4 이후 버젼에서만 확인 가능)
그리고, 1-Chart online.dsh를 오픈하면, 아래와 같이 3개월치의 데이터가 입력된 대시보드를 확인할 수 있다. (Rollup 없는 전체 데이터 평균 차트이니, 시간이 조금 오래 걸릴 수 있다)
4. 전체 백업 및 마운트 맛보기
이제 데이터가 모두 준비되었으니, 전체 데이터베이스를 백업 하고, 이것을 실제로 마운트해 보자.
2-Full Backup and Mount.wrk를 열고, 순서대로 수행하면 위의 과정을 그대로 수행해 볼 수 있다.
전체 데이터베이스 백업
BACKUP DATABASE INTO DISK='/tmp/mybkup2';위의 명령을 수행하면, 현재의 모든 데이터베이스를 주어진 디렉토리에 백업한다. 이 백업은 온라인 백업이므로 다른 연산에 아무런 영향을 미치지 않는다는 것을 참조하자.
실제 해당 디렉토리를 보면, 아래와 같이 다수의 화일로 구성된다는 것을 확인할 수 있다.
jkim@gamestar:~$ ls /tmp/mybkup2 -l
total 348
drwxrwxr-x 8 sjkim sjkim 4096 May 25 11:16 TAG_TABLESPACE
-rw-rw-r-- 1 sjkim sjkim 1148 May 25 11:16 backup.dat
-rw-rw-rw- 1 sjkim sjkim 2722 May 25 11:16 backup.trc
drwxrwxr-x 103 sjkim sjkim 4096 May 25 11:16 machbase_backup_19700101090000_20240525111644_27
-rw-r--r-- 1 sjkim sjkim 139264 May 25 11:16 meta.dbs-0
-rw-r--r-- 1 sjkim sjkim 143360 May 25 11:16 meta.dbs-1
-rw-r--r-- 1 sjkim sjkim 8192 May 25 11:16 meta.dbs-2
-rw-r--r-- 1 sjkim sjkim 36864 May 25 11:16 meta.dbs-3
-rw-r--r-- 1 sjkim sjkim 0 May 25 11:16 meta.dbs-4
-rw-r--r-- 1 sjkim sjkim 12288 May 25 11:16 meta.dbs-5마운트 및 데이터 확인해 보기
정말로 마크베이스 네오가 백업된 데이터베이스 화일을 내부에 새로운 데이터베이스 인스턴스로 마운트 할 수 있는지 테스트해 보도록 하자. 명령어는 아래와 같으며, 새로운 데이터베이스명은 mountdb로 하자.
MOUNT DATABASE '/tmp/mybkup2' to mountdb;불과 1초도 안된 시간에 이 명령어는 성공했다고 나온다.
네오의 메뉴에서 확인을 해보면 다음과 같이 MOUNTDB가 존재한다고 리스트에 출력된다. 마운트가 된 것이다!
이제 데이터가 제대로 들어가 있는지 SHELL에서 다양한 질의를 날려보면 다음과 같이 성공적으로 데이터를 확인할 수 있다.
아래의 테이블명이 mytab_A가 아니라 마운트된 데이터베이스인 mountdb.sys.mytab_A인 것을 유심히 살펴보도록 하자.
언마운트
데이터 확인 작업이 끝나 이 데이터베이스가 불필요하게 되면, 아래와 같이 간편하게 언마은트 명령을 통해 흔적을 없앨 수 있다.
UMOUNT DATABASE mountdb;
실행화면
위에서 이미 언마운트된 테이블을 접근하면, 에러가 발생하는 것을 확인할 수 있다.
아아!! 이제 우리는 백업/마운트/언마운트 기능을 이용해서 정말 신박하고, 편리한 IIoT 데이터 관리 방법을 이해하게 되었다!
5. 시간 범위 데이터베이스 백업 및 마운트
4번에서는 전체 데이터베이스를 백업했던 것이라면, 이제는 특정 시간 범위에 존재하는 모든 테이블에 대해 백업을 해 보도록 하자. 이 시간 범위를 지정하는 것은 데이터의 관리자가 자신만의 데이터 관리 정책에 맞게 데이터를 분류, 배치 하는 관점에서 매우 유용한 기능임을 한눈에 이해할 수 있다. 데모는 준비된 워크시트인 3-Time Range DB Backup and Mount.wrk 를 이용한다.
시간 범위 데이터베이스 백업
이 백업의 syntax는 다음과 같다.
BACKUP DATABASE FROM 시작시간 TO 끝시간 into DISK=대상폴더;매우 심플하다. 주어진 백업 샘플은 1월달의 모든 데이터를 mybkup3 폴더에 모두 백업하는 예제이며, 아래와 같다.
BACKUP DATABASE FROM TO_DATE('2023-01-01 00:00:00','YYYY-MM-DD HH24:MI:SS')
TO TO_DATE('2023-01-31 23:59:59','YYYY-MM-DD HH24:MI:SS')
INTO DISK='/tmp/mybkup3';
DELETE FROM mytab_B before TO_DATE('2023-01-31 23:59:59','YYYY-MM-DD HH24:MI:SS');백업 후에 테스트를 위해 Table B의 1월치 데이터를 모두 지운다. 결과적으로 온라인 데이터베이스에는 Table A는 1,2,3월 데이터를 가지고, Table B는 2월 3월 데이터만 보유하며, 백업된 데이터베이스에는 모든 데이터를 다 가지고 있다.
마운트 및 데이터 확인
아래와 같이 온라인 데이터베이스의 mytab_B는 1월의 데이터가 사라진 것을 확인할 수 있고, 마운트된 mytab_B 테이블에는 1월치 데이터만 고스란히 저장된 것을 확인할 수 있다.
언마운트
앞에서와 동일하게 아래와 같이 간편하게 언마은트 명령을 통해 흔적을 없앨 수 있다.
UMOUNT DATABASE mountdb;감동의 물결이 밀려온다. 특정 시간 범위로 백업한 데이터베이스를 원하는 시점에 원하는 형태로 마운트해서 데이터를 확인할 수 있고, 필요시 즉시 사라지게 할 수 있다니 말이다!
6. 특정 테이블 백업 및 마운트
이제 전체 데이터베이스가 아니라 특정 태그 테이블에 대해서 특정 시간 범위를 준 형태로 백업을 하고, 이를 마운트해서 데이터를 확인해 보도록 하자. 이 예제는 4-Time Range Table Backup and Mount.wrk에 준비되어 있으니 참고하자.
시간 범위 테이블 백업
이 백업의 syntax는 다음과 같다. (물론 시간 범위 없이도 가능하다)
BACKUP TABLE 테이블명 FROM 시작시간 TO 끝시간 into DISK=대상폴더;매우 심플하다. 주어진 백업 샘플은 테이블 mytab_A의 3월달 데이터를 mybkup4 폴더에 모두 백업하는 예제이며, 아래와 같다.
BACKUP TABLE mytab_A FROM TO_DATE('2023-03-01 00:00:00','YYYY-MM-DD HH24:MI:SS')
TO TO_DATE('2023-03-31 23:59:59','YYYY-MM-DD HH24:MI:SS')
INTO DISK = '/tmp/mybkup4';마운트 및 테이블 데이터 확인
마운트 방식은 아래와 같이 예전과 동일하며, 아래의 결과와 같이 백업된 공간의 mytab_A는 3월치 데이터만 입력되어 있고, 온라인 공간의 mytab-A는 3개월 데이터가 모두 입력되어 있는 것을 확인할 수 있다.
언마운트
앞에서와 동일하게 아래와 같이 간편하게 언마은트 명령을 통해 흔적을 없앨 수 있다.
UMOUNT DATABASE mountdb;즉, 데이터베이스 전체 혹은 시간 범위의 데이터베이스 뿐만 아니라 특정 테이블의 특정 시간 범위에 대해서도 백업을 하고, 이를 원하는 시점에 원하는 이름의 데이터베이스 이름으로 마운트해서 언제라도 데이터를 확인할 수 있다는 것을 눈으로 확인해 보았다.
7. 동시에 여러개 마운트하기
마지막으로 하나가 아니라 여러개의 백업을 동시에 마운트하고, 이를 시각화해 보도록하자. 이를 위해 준비된 화일 5-Mount All.wrk, 6-Chart All.dsh, 7-Umount All.wrk를 순서대로 수행하면 된다.
여러개 마운트하기
아래의 SQL 처럼 지금까지 백업했던 3개의 화일을 한꺼번에 백업해 보기로 하자.
위와 같이 성공적으로 동시에 여러개를 마운트할 수 있는 것을 확인했다. 또한, 아래와 같이 테이블의 Layout을 확인할 수 있다. (8.0.18-rc4 이상에서 가능)
데이터 분포 시각화
이제 전체 데이터의 분포를 보기 위해 6번의 차트를 오픈하면, 다음과 같다. (출력에 시간이 좀 걸린다. 전체 데이터를 출력하는 차트이다)
위 그림과 같이 첫번째 백업(MOUNT-2 Tables)의 경우 두 테이블의 1, 2 ,3월 모든 데이터를 담고 있고, 두번째 백업(MOUNT-3 Tables)은 1월달의 데이터만 담고 있다. 세번째 백업(MOUNT-4 Tables)의 경우 A 테이블에 대해서 3월의 데이터만 담고 있는 것을 확인할 수 있다.
결론적으로 마크베이스 네오의 백업/마운트 기능을 활용하면, 다양한 조건으로 데이터를 백업 받을 수 있을 뿐만 아니라, 이렇게 준비된 백업화일에 대해 원하는 시간에 초고속으로 마운트하여, 즉시 데이터를 검색, 추출, 변환할 수 있는 강력한 기능을 제공받을 수 있다.
언마운트
앞에서와 동일하게 아래와 같이 수행한다.
umount database mountdb2;
umount database mountdb3;
umount database mountdb4;
기업의 데이터 관리 정책 수립을 위한 고려사항들
의사결정 포인트
기업 레벨에서의 데이터 관리 정책을 수립하기 위해서는 여러가지 해당 기업 환경에 따른 다양한 옵션을 고려해야 하며, 개략적으로 아래와 같은 의사결정 포인트가 있을 것이다.
백업 대상은 무엇으로 할 것인가?
데이터베이스 전체 대상
특정 테이블 대상
백업 주기는 어떻게 할 것인가?
매월 1회씩
분기별 1회씩
반기별 1회씩
백업 데이터의 접근 방법은 어떻게 할 것인가?
온라인 데이터베이스에 대해 마운트 및 접근 (서비스 부하 집중)
마운트용 데이터베이스 구축 및 접근 (서비스 부하 분산)
백업 데이터 저장소는 어떻게 구성할 것인가?
온라인 서버의 저장소 활용
저렴한 저장소 (HDD, S3)에 대한 이동
마운트 정책은 어떻게 할 것인가?
누가 원하는 백업 화일에 대해 마운트 동작을 할 것인가?
자동으로 마운트하는 기능을 구현하고, 제공할 것인가?
마운트된 것들은 언제 언마운트하고, 관리 주체는 누가될 것인가?
위의 의사결정 고민을 한다는 의미는 "백업된 데이터를 언제 누구나 쉽게 접근할 수 있는 마운트 기능"이 핵심 기반이 된다는 사실을 잊지 말자. 이 기능이 없다면, 데이터 수요자에 대한 서비스 자체가 완전히 다른 형태로 이루어져야 할 것이다.
데이터 서비스 가상 시나리오
아래는 특정 기업의 서비스 형태를 가상으로 꾸민 것이기는 하나 참고해도 좋은 내용이라 공유하도록 하겠다.
"현재 해당 기업은 실시간으로 XX 제조 공정에서 나오는 데이터를 대량으로 저장하고 있다. 데이터는 제조 품질 개선을 위한 "데이터 분석가 조직"으로부터 여러 조건의 다양한 데이터 서비스에 활용되고, 이를 위해 편하고, 빠른 혁신적인 내부 데이터 서비스 모델을 아래와 같이 구축하였다."
태그 갯수
총 10만개
데이터 수집 속도
5만건~9만건 / 초당
데이터 관리 OS
윈도우 10 서버
마크베이스 네오 최신 버젼
백업 대상
전체 데이터베이스 (Rollup 포함)
백업 주기
매월 1회
백업 데이터 저장소
1차 SDD 백업 (백업 성능 보장)
2차 저장장치 (HDD)로 이동 및 삭제
마운트 데이터 접근 방법
온라인 데이터 처리 서버에 영향을 주지 않기 위한 방법 고려
별도의 윈도우 서버 구축 및 2차 저장장치 연결
필요시 해당 백업 폴더를 마운트 하고, 서비스 준비 완료 통지
접근 URL 및 마운트 데이터베이스명 분석 조직에 통지
마운트 정책
데이터 분석 조직의 데이터 요청
현업 담당자의 마운트/언마운트 수행
마운트 데이터 접근 주체
사내 데이터 분석가 조직
Rest API 및 SQL을 통해 원하는 시점의 원하는 데이터를 수집
자체 분석 SW에서 품질 분석 수행
분석 작업 완료시 현업 담당자에게 통지 및 언마운트
마치면서
지금까지 소개한 마크베이스 네오의 "마운트" 기능은 빅데이터 관리와 서비스 관점에서 볼 때 정말 혁신적인 기능이다. 특히, 온라인으로 서비스하는 데이터를 무한히 한곳에 저장할 수 없고, 어떤 형태로든 데이터를 백업 받아야 하는 동시에 백업 데이터에 대한 비정기적 접근이 필요한 경우에는 이 "마운트" 기능 이상의 편리한 방법을 찾기도 어려울 것이라고 확신한다.
기업마다 조건이 다르겠지만, 마크베이스 네오의 마운트 기능을 통해 내부 데이터 혁신과 서비스 품질 개선에 조금이나마 도움이 되기를 빌면서 이만 줄이도록 하겠다.