InfluxDB

시계열 데이터란

- 시간 별로 구성된 값들의 집합 ( 연도별, 분기별, 월별, 시간별 등 )

- 하나의 특정시간 단위에 대해 각 데이터 포인트에 대해 하나의 값만 측정 

- 시간과 하나 이상의 속성으로 구성됨 

 

 

시계열 데이터 베이스란 ? 

• 시간 처리에 최적화 된 데이터베이스
• SQL 기반의 시계열 질의를 지원함
• 빠른 데이터 입력과 트랜잭션 지원 및 데이터 변경 불가 
• 롤업(Roll-up) 기능을 지원함 

 

 

Influx DB의 특징 

• 빠른 쓰기 및 읽기가 가능한 오픈소스로 , 시간 경과에 따른 일련의 시계열 데이터를 저장하는 NoSQL 형태의 DB
• Go, Java, Python, Node.js 등과 같은 클라리언트 지원 
• 간편하고 쉬운 설치 
• SQL과 같은 질의어들을 제공함
• Schemaless Design 
• 데이터 보관 주기 설정 가능
• 플러그인 아키텍쳐 설계로 타사 제품과 통합이 용이함 

 

기존 DB와의 용어 비교 

자료 참고 : 유튜브 엑셈TV

 

 

InfluxDB의 시간 측정 

1. InfluxDB는 기본적으로 Unix Time을 사용함

Unix Time이란 1970년 1월 1일 이후 부터의 경과 시간을 초로 환산하여 정수로 나타낸 단위 

( EX : 1561681930 ==> 2019-06-28T 00:32:10Z ) 

 

2. InfluxDB의 timestamp

InfluxDB는 기본적으로 nanosecond 단위의 unix time 값, 옵션으로 단위를 바꾸는 것이 가능함 

( EX : 15612820000000ns ==> 1562182000s = 2019-07-04T04:26:40Z ) 

 

 

 

 

 

influxDB 설치

https://github.com/influxdata/influxdb/releases

Releases · influxdata/influxdb

현재 사용 중인 버전 : 1.8.10

 

 

 

influxe.exe	클라이언트
influxed.exe	서버
influxdb.conf	설정파일

 

 

 

용어

Measurements	일반 데이터베이스의 테이블에 해당
Tag	SQL DB의 인덱싱 된 열과 유사함  - 검색 조건 등 활용
Field	SQL DB에 인덱싱 되지 않은 열과 유사함  - 실 측정 DATA가 주로 해당
Line Protocol	influxDB에 point를 쓰기 위한 텍스트 기반 형식
Point	단일 행의 레코드를 가진 SQL DB와 유사함 단일 필드 모음으로 구성되고 각 point는 그 자체로 고유하게 식별
Timestamp	point와 관련된 날짜와 시간, influxDB의 TS는 항상 NS의 unix time 값을 저장됨
Retention Policy (RP)	데이터를 사용할 수 있는 기간 혹은 시간을 지정함

 

 

 

 

[1]  기본 명령어

---

 

1. 데이터 베이스를 조회함 

show databaes

 

2. 데이터 베이스를 선택함 

use _internal

 

3. 선택한 데이터베이스 내 measurement를 조회함 

show measurements

 

4. 종료

quit

 

5. 시간 값  설정 ( UnixTimestatmp --> UTC ) 

> precision rfc3339

 

 

 

 

 

[2] 데이터 베이스 관련  

# 데이터 베이스 생성
> create database exemDB

# 데이터 베이스 확인
> show databases

# 데이터 베이스 사용
> use exemDB

# 데이터 베이스 내 measurement 확인
> show measurements

 

 

 

 

 

InfluxQL

 

[1] DATA Format 

  -   Line protocol을 사용함 

  -  하나의 행을 point라 하고 각 point는 line protocol 형식으로 구성됨 ( point는 개행으로 구분함 ) 

  -  Tag set과 Field set은 key = value 형태로 구성되며 여러 개 일 때 쉼표로 구분해서 나열함 

Measurement , Tag set , Field Set Timestamp

EX

Soccer , name = son, team=tot city="london",age=28 1503050103502 Soccer , name = ki, team=new city ="newcastle", age=31 1503040234000 Soccer , name = park, team=man city="manchester", age=40 150324100000

- Measurements : Soccer라는 테이블  - tag : name, team ( String Type만 가능함 )  - field : city, age ( 모든 타입 가능 , string인 경우 " "로 구분 )\ - ,로 이어지면 Tag 그 뒤로 공백으로 이어지면 field 다시 field에서 ,로 구분 [ 공백으로 tag와 field구분 ]

 

 

[2] Insert 

• schemaless : 대부분 DB와 달리 Table을 따로 생성하지 않고 바로 insert
• TS는 생략이 가능함, 생략 시 데이터가 저장되는 시점의 시간으로 저장됨
• Data Load시 measurement가 존재하지 않으면 생성 뒤 데이터가 저장됨 

- Insert measurements, tag set field set timestamp

 

 

[3] Load

# DB 구조 확인 - show tag keys on "database명" from "measurements명" - show field keys on "database명" from "measurements명" > on database명 생략가능  > from measurements명 생략 시 모든 measurement의 태그나 필드 타입 조회

 

# 데이터 조회  - select * from soccer

 

 

 

[4] DELETE 

• 시계열 DB에서는 데이터 삭제나 갱신을 권장하지 않음
• InfluxDB 문서에는 완전한 CRUD DB가 아닌 CR(ud)라 언급함

> delete from measurements명 wher tag키 = 'tagr값'     // 작은 따옴표를 사용함

 

 

 

[5] LOAD DATA BACKUP 

.\influxed backup -portable -database [데이터베이스명]  [백업파일 할 위치]

 

 

 

[6] Mesaurement 삭제 

drop measurement soccer  # measurements 삭제 drop database exemDB  # DB삭제 # 삭제 시 아무 경고 없이 바로 삭제되므로 백업을 하거나 주의가 필요함

 

 

[7] 데이터 베이스 복구 

[powershell] influxd restore -portable -db exemDB /tmp/backup/

 

 

 

[8] Retention Policy [RP]  보존 정책 

• 데이터를 사용할 수 있는 기간 혹은 시간을 지정함 
  • Duration : 데이터 보관 기간
  • Replication Factor : 클러스터에 저장된 데이터의 복사본 수
  • Shard Groups : 샤드와 샤드의 논리적 컨테이너로 실제 데이터가 들어있음
  • Shard Group Duration : 샤드 그룹에 의해 보호되는 시간 범위
• RP가 정의되지 않은 경우 기본 RP(Autogen)가 적용됨 ( 복제 수 1, 샤드 그룹 기간 7, 무한대의 지속 기간 ) 
• (ex) show retetion policies on markey ==> market db의 RP를 조회함 

 

INFLUXDB 단점 - insert, select 쿼리 성능을 위하다 보니, Delete, Update는 고려하지 않는다. Timeseries 데이터들은 한 번 Write 되면 수정될 일은 없다고 봐야하기 때문에 Update는 발생하지 않으며, 데이터 또한 삭제될 일이 없다 보니 Retention Policy가 아닌 이상 데이터를 삭제하는 일은 거의 없다고 봐도 무방하다. InfluxDB Docs는 InfluxDB가 CRUD 가 아닌 CR-ud 를 지원한다고 말하고 있다.  - Timestamp가 오름차순으로 정렬되어 저장되다보니, 랜덤 읽기에서는 성능이 떨어진다. 애초에 데이터를 Write할 때 오름차순으로 Time을 정렬하기 때문에 랜덤 R/W 에서는 성능이 떨어진다고 한다. 근데 Time Series에서 랜덤 W/R를 할 일이 있을지는 모르겠다. - RDBMS와 다르게, 데이터의 일관성(트랜젝션)은 보장하지 않는다.  일관된(consistent) 데이터를 갖는 것은 그다지 중요하지 않으며, 많은 클라이언트들이 연결해 읽기, 쓰기 작업을 하는 것에 초점을 맞추고 있다. 따라서 많은 부하가 걸릴 때에는 일관된 반환값을 갖지 않을 수 있다. (Time Series 데이터베이스를 은행시스템과 같이 트랜젝션이 중요한 곳에 쓰는 미친사람이 있지 않은 한 큰 문제는 되지 않을 것 같다.) - 일반적인 SQL 기능을 제공하지 않는다.  테이블 조인? RDBMS 쓰자.