http://www.infiniflux.com/download - InfiniFlux : 시계열 데이터를 저장, 처리하는 초고속 데이터베이스 - 이를 지원하기 위해서는 오라클 혹은 DB2와 같은 전통적인 데이터베이스(Conventional DBMS)와 매우 다른 성격을 가짐 - 로그성 시계열 지원 제품 아키텍처 및 특성을 이해하는 것이 중요 - 초당 수십만 건의 레코드를 저장하면서 동시에 SQL을 통해 해당 데이터를 분석하는 핵심 기능을 제공하기 위한 기술적 특성 기술 전통 기술과의 차이점에 대해 기술하고, 각 항목에 대한 세부적인 내용을 설명

1. InfiniFlux vs RDBMS
www.infiniflux.com

2. 개요
2
• InfiniFlux : 시계열 데이터를 저장, 처리하는 초고속 데이터베이스
• 이를 지원하기 위해서는 오라클 혹은 DB2와 같은 전통적인 데이터베이스(Conventional DBMS)와
매우 다른 성격을 가짐
• 로그성 시계열 지원 제품 아키텍처 및 특성을 이해하는 것이 중요
• 초당 수십만 건의 레코드를 저장하면서 동시에 SQL을 통해 해당 데이터를 분석하는 핵심 기능을
제공하기 위한 기술적 특성 기술
• 전통 기술과의 차이점에 대해 기술하고, 각 항목에 대한 세부적인 내용을 설명
문서 개요

3. 비교 차트
3
특성 InfiniFlux DB RDBMS
트랜잭션 Snapshot 기반 암묵적 제공 Log File 기반 명시적 제공
INSERT 성능 초당 30만~300만건 초당 1만건 이하
SELECT 성능 검색 및 통계 분석 질의에 최적화 OLTP 처리에 최적화
처리 데이터 속성 로그성 시계열 데이터 비 로그성 트랜잭션 데이터
데이터 변경 모델
Append Only
(Write Once, Read Many)
Updatable
DELETE 연산 가장 오래된 것부터 삭제 임의의 데이터 삭제
실시간 인덱스 실시간 비트맵 지원 비 실시간성 B+Tree
데이터 압축 고성능 실시간 압축 압축 지원 미비
실시간 텍스트 검색
지원
(실시간 역인덱스 지원)
미지원
(지원하더라도 실시간 속성 미비)
시계열 데이터 지원 Sharding을 통한 데이터 파티션 지원 일반 timestamp 칼럼 기반 지원
데이터와 인덱스 Gap 순간적으로 Gap 발생 Gap 발생하지 않음

4. 트랜잭션 지원 여부
4
RDBMS
• 명시적으로 모든 데이터 연산에 대해 트랜잭션 제공
• 트랜잭션 : ACID 프로퍼티를 만족하는 연산의 집합
• Atomicity
• Consistency
• Isolation
• Durability
• Savepoint, Commit, Rollback
InfiniFlux
• 명시적인 트랜잭션을 제공하지 않음
• 데이터의 연산(입력)에 대한 트랜잭션 없음
• 내부적으로 메타 정보에 대한 암묵적인 트랜잭션을 제공
• 테이블 구조, 인덱스 구조, 데이터 파일 구조
제공하지 않는 이유
• 시계열 데이터는 트랜잭션 기반으로 데이터를 보존할 필요가 없음
• 오히려 매우 빠르게 저장하고, 처리하는 것이 더 가치가 있음.
• 트랜잭션 제공을 하기 위한 매우 복잡한 연산과 비용을 굳이 지불할 필요가 없음

5. 입력 성능
5
RDBMS
• 초당 5000건 이상 입력하기 매우 어려움
• 트랜잭션 제공을 하기 위한 로깅 비용이 매우 큼  I/O 비용 증가
• 인덱스 갱신 비용이 매우 큼  B+Tree는 데이터 검색에 최적화된 구조
• 일관성 보장을 위해 하나의 레코드에 대해 모든 인덱스 갱신 연산을 순차적으로
수행해야 함
• 데이터 보다 인덱스 양이 더 커짐에 따라 시스템 성능 저하
InfiniFlux
• 초당 수십만 건까지 입력 가능
• 실시간 비트맵 인덱스를 통해 인덱스 구축이 매우 효율적임
• 로깅에 들어가는 비용이 필요 없음
• 다수 쓰레드에 의한 병렬 인덱스 구축
• 실시간 압축을 통한 I/O 량을 현격하게 감소  시스템 전체 성능 향상
• 멀티 디스크 기반의 테이블 스페이스 생성을 통해 획기적 성능 향상 가능

6. 질의 성능
6
RDBMS
• 로우형(Row oriented) 데이터베이스는 실시간 질의(OLTP)에 강점을 가짐
• 데이터의 분포도가 높은 경우(Cardinality) 질의 성능이 좋음
• 이유 : B+Tree와 같이 검색 범위가 작아야 효율적이기 때문
• 주로 B+Tree를 기반으로 동작하며 가장 효율이 좋은 하나의 인덱스를 결정하고 사용
• 데이터 건수가 매우 크더라도 실제 검색이 좁은 경우 효율적
• 통계 분석을 위한 질의는 매우 느림
InfiniFlux
• 컬럼형(Column oriented) 데이터베이스로서 통계 질의(OLAP 성)가 매우 빠름
• 데이터의 분포도가 낮은(Cardinality가 낮음) 경우 특별히 빠름
• 대부분의 로그성 시계열 데이터는 중복도가 높아 Cardinality가 낮음
• 대부분 비트맵 인덱스를 구성하며, 동시에 두개 이상의 인덱스를 활용할 수 있어
효율적
• 수억건 이상의 대량 데이터에 대한 통계 질의가 매우 빠름
• OLTP 성의 특정 레코드를 전체에서 빨리 찾는 것은 상대적으로 느림
• 이 경우 Global Index를 생성해야 함

7. 처리 대상 데이터 속성
7
RDBMS
• 트랜잭션을 통해 보관되어야 하는 데이터에 최적
• 은행 거래를 위한 금전 정보 및 주요 개인 식별 정보 등
• 오라클 등과 같은 전통적 데이터베이스에 중요하게 보관되어야 하는 정보
• 시간의 흐름과 무관하며, 변경되거나 삭제될 수 있음
InfiniFlux
• 로그성 시계열 데이터가 대상임
• 초당 수십만 건이 발생되는 상황의 데이터
• Update 연산이 필요 없고, 데이터의 중복도가 매우 높음
• 기존에 텍스트 파일로 저장하던 로그 파일 및 유사 데이터가 대상
• 시간 흐름에 따라 특정 대상에 대한 상태를 지속적으로 기술

8. 데이터 변경 모델
8
RDBMS
• Updatable 모델
• 데이터는 언제라도 수정되고, 변경될 수 있음
• 임의의 순간에 임의의 레코드가 삭제될 수 있음
• 모든 데이터에 대한 접근 및 변경이 매우 자유롭게 설계
InfiniFlux
• Write Once, Read Many 모델
• 로그성 시계열 데이터이므로 한번 저장되면 절대로 변경이 발생하지 않음
• 읽기 중심이며 변경 연산은 엔진에서 아예 지원하지 않음
• 데이터의 삭제는?
• 임의의 레코드를 임의의 순간에 삭제할 수 없음!
• 가장 오래된 레코드로부터 순차적으로 삭제할 수 있음
• 이는 Embedded 장비의 디스크 사용량을 일정 수준으로 유지하도록 하는
기능으로서 제공

9. 인덱스 기술
9
RDBMS
• B+Tree를 기본으로 활용
• Global 인덱스이며, 해당 인덱스에 전체 레코드 정보가 저장
• 트랜잭션 지원을 위한 로깅 및 Recovery 연산 비용 과다
• 이러한 이유로 처리 성능이 수천건/sec 에 불과
• 원시 데이터의 값이 인덱스에 저장되어, 디스크 사용량이 인덱스 개수와 비례하여
급격하게 증가
• 성능성의 이유로 압축을 지원하지 않음
InfiniFlux
• 실시간 Bitmap 인덱스 지원
• 파티션 단위의 로컬 인덱스 구조
• 전체 레코드에 대해 다수의 인덱스로 구성됨
• 트랜잭션 지원 및 로깅이 필요없어 매우 빠르게 인덱스 구성 가능
• 초당 수백만 건의 인덱스 구축 가능
• 데이터의 량이 늘어나도 인덱스 구축 비용이 조금씩 증가
• 압축 알고리즘 지원으로 디스크 사용량 최소화
• 데이터의 량이 무한히 커질 경우 OLTP 성 질의는 상대적으로 느림
• Semi global 인덱스 지원 (2015/Q4)
• OLTP 질의에도 고성능 지원 가능
• 압축 및 통계 질의에도 뛰어난 성능 지원

10. 압축 기술
10
RDBMS
• 데이터 압축에 대한 이슈가 크게 발생하지 않음
• 그 이유는 대상 레코드의 개수가 일반적으로 특정 개수로 유지되기 때문이며,
이런 환경에서는 디스크 사용량이 크게 이슈가 되지 않음
• 디스크 용량을 희생하여, 검색 성능을 올리는 것이 기본 철학!
• 압축 자체가 고객의 관심사가 아닌 경우가 많음
• 설사 압축을 한다고 해도 아래의 한계에 봉착
• B+Tree 의 데이터 중복 구조로 인한 사용량 증가
• Row 기반의 데이터 중복 속성을 활용하기 어려움
InfiniFlux
• 대량의 데이터가 발생하는 환경을 가정하기 때문에 디스크 사용량이 매우 중요
• 두번의 실시간 압축을 수행하여, 매우 효율적인 디스크 사용량을 달성
• 논리적 압축 기법
• 컬럼 기반의 중복 데이터를 딕셔너리 구조로 압축
• 비트맵 인덱스에 대한 중복 비트열을 논리적으로 고압축
• 물리적 압축 기법
• 디스크로 저장시 파티션 페이지를 물리적으로 실시간 압축
• 인덱스 개수 증가에 따라 디스크 사용량이 선형적으로 증가하지 않고, 완만하게
증가하는 패턴을 보임

11. 풀 텍스트 검색 (full text search)
11
RDBMS
• 전통적으로 데이타베이스에서 텍스트 검색은 지원하지 않음
• 대신 LIKE 구문을 활용하여 대체할 수 있는 방법을 제공
• 해당 컬럼의 부분 검색은 LIKE ‘%패턴%’을 통해 이루어지나,
이 경우 모든 레코드에 대한 Full Scan이 발생하여, 매우 느림
• 사실상 풀 텍스트 검색 용도로는 사용이 불가능
InfiniFlux
• Keyword Index를 제공하여, 특정 VARCHAR 컬럼에 대한 풀 텍스트 검색이 가능함
• LIKE 대신 SEARCH를 활용하여 검색 가능
• Select id from table where address SEARCH ‘강남’;
• UTF8 으로 저장된 텍스트에 대해 검색 가능
• 영문과 2byte 문자(CJK)에 대한 처리 방법이 상이함
• 영문
• 특수 문자를 기준으로 단어를 구분 (boy와 boys 가 다름)
• CJK (Chinese, Japanese, Korean)
• 2 gram 기법을 활용하여, 검색
• ‘강남구’ 문자는 ‘강남’ & ‘남구’ 의 연산으로 변환되어 수행

12. 동시성 레벨
12
RDBMS
• 기본적으로 Record Level Locking을 제공
• Update중인 레코드의 읽기 여부에 따라 다시 분류됨
• Consistency Read
• Update 중인 레코드에 대해 이전 버전의 값을 읽도록 허용
• Lock의 충돌이 없음  대기 시간이 없음
• Non Consistency Read (Record Lock confliction 발생)
• Update 중인 레코드에 대해 해당 버전의 Commit/Rollback 여부를
대기해서 판단하도록 함
• Lock의 충돌 존재  앞 트랜잭션의 상황에 따라 무한 대기할 수도
있음
InfiniFlux
• Lockless 구조를 제공
• Update가 없으므로, Lock 충돌이 없음
• 레코드에 대한 Lock 메커니즘이 존재하지 않으므로, 데이터에 대한 검색 및
분석 성능이 극대화 됨
• CJK (Chinese, Japanese, Korean)
• 2 gram 기법을 활용하여, 검색
• ‘강남구’ 문자는 ‘강남’ & ‘남구’ 의 연산으로 변환되어 수행

13. 시계열 데이터 분석
13
Sliding
Memory
Window
Memory
Window
Memory
Window
File -1 File -2 File -3 File -4 File -5 File -6 File -7
Data
Insert
Current time Old time
RDBMS
• 시계열은 시간 데이터 타입으로 존재 (date, time, timestamp, interval)
• 해당 데이터를 시계열 이라는 개념으로 인식하지 않고, 다른 일반적인 데이터와
동일하게 취급(number, varchar, ….)
• 그런 이유로 시간축을 기준으로 분석하기 위한 별도의 장치를 마련해 놓고 있지 않음
• 시간 인덱스를 이용하여 분석할 경우 성능이 느림
InfiniFlux
• 데이터가 입력될 때 시간 순서대로 물리적 파티션을 생성
• 이런 이유로 특정 시간대의 레코드에 대한 직접 억세스 가능
• 데이터가 입력될 경우 해당 레코드에 대한 nano 단위의 timestamp가 자동적으로
입력 (숨은 _arrival_time 컬럼)
• 이 컬럼을 기준으로 시간축의 데이터를 자유자재로 조작 가능
• Select data from table where DURATION 10 minute (10내 데이터 출력)

14. 백업과 복구
14
Backup Restore
RDBMS
특정 테이블 혹은 데이터베이스 영역의 데이터를 외부에
보존
• 온라인 백업을 통한 데이터 보존이 기본 정책
• 백업 시간과 비용을 줄이기 위해 향상된
incremental backup(차분 백업)을 별도로
지원
백업된 데이터를 원래 데이터베이스로 옮겨오는 과정
• 백업된 파일을 그대로 사용할 수 없으며
반드시 복구(Restore) 과정을 거쳐야 함
• 큰 백업 파일의 경우 매우 오랜 시간이 걸림
• 특정 시점으로 백업이 가능하고, 시작 시점의
변경이 복잡
InfiniFlux
• 시간을 기준으로 전체 데이터베이스 백업
• 특정 테이블 혹은 레코드 기준으로는 안됨
• 외부 하나의 파일 형태 혹은 다수의 파일이
포함된 디렉토리 형태
• 해당 백업 파일을 이용하여 그대로 옮겨옴
• 기존의 데이터베이스를 overwrite

15. 백업 및 마운트 (Mount)
15
Mount란
• 백업된 데이터베이스 파일을 Restore 하지 않고, 메타 정보만 로딩한 후에 백업된
데이터베이스의 내용을 로드 및 검색할 수 있는 기능
• 마치 UNIX의 디스크 마운트와 같은 개념
• 매우 빠르게 특정 시점의 백업된 데이터를 즉시 접근 가능
RDBMS • 지원 못함
InfiniFlux
• MOUNT
• 2014년 12월 31일 백업된 내용을 마운트
• 예) MOUNT DATABASE ‘/home/data/2014-12-31’
• UNMOUNT
• 해당 마운트된 내용을 언마운트
• 예) UNMOUNT DATABASE ‘/home/data/2014-12-31’

16. The World's Fastest
Time Series DBMS
for IoT and BigData
www.infiniflux.com
info@infiniflux.com
InfiniFlux