180726-InfluxDB 기본 개념 요약

InfluxDB 기본 개념 요약
InfluxDB는 시퀀스 데이터베이스로서 전통적인 관계형 데이터베이스에 비해 다소 차이가 있다. 다음은 가능한 한 간단명료한 방식으로 관련 용어 개념을 소개한다.
I. 기본 개념
mysql
influxdb
설명
database
database
데이터베이스
table
measurement
mysql 테이블과 유사한 개념
record
tag + field + timestamp
전통 표의 한 줄 데이터는 influxdb에 비치면 세 개로 나눌 수 있다
1. database
데이터베이스
2. measurement
비교되는 것은 mysql의table이다. 실제 체험을 보면 두 가지 가장 뚜렷한 차이점은 단독으로measurement를 만드는 방법이 없고 직접 데이터를 추가할 때measurement가 존재하지 않으면 직접 데이터를 만들고 삽입하는 것이다.
3. Point
이것은 mysql의 Record와 비교됩니다. influx DB에서 모든 테이블에서 특정한 조건을 충족시키는 filed 데이터 (간단하게 말하면 timestamp+tag+filed) 의 구성은point입니다.

timestamp: 시간 스탬프, ns 단위, 모든 기록에 반드시 이 속성이 있습니다. 추가가 표시되지 않을 때 기본적으로 하나

에 줍니다.

tag: 라벨,kv 구조,database에서 tag+measurement와 함께 색인 구축

색인 생성에 참여하기 때문에 검색의 필터 조건으로 적합

tag의 데이터량이 너무 많지 않고 전형적인 변별성(mysql의 색인 구축 원칙과 차이가 많지 않다)

value는 String 유형

tag는 선택할 수 있고measurement에서 tag를 설정하지 않아도 ok

field: 저장 데이터,kv구조

데이터 유형은 롱, 스트링, boolean,float

4. Series
Series: tag key와 tag value의 고유한 조합
II. 실례 분석
위의 몇 가지는 기본적인 개념으로 단독으로 보면 인상이 깊지 않다. 다음은 실례를 결합하여 설명한다.
measurement를 구축하여 어떤 응용 프로그램의 성능 상황을 저장하고 다음 지표를 포함하여 1초에 한 번씩 influxDB에 데이터를 씁니다

서비스 기기:host=127.0.0.1

서비스 인터페이스: 서비스=app.service.index

qps: qps=1340

rt: 1313

cpu: 45.23

mem: 4154m

load: 1.21

1. measurement 만들기
위에 7개의 지표 매개 변수가 있는데 첫 번째 단계는 tag와field를 구분하는 것이다. 앞에서 말했듯이 tag는 색인을 만들 것이다. 유형을 구분할 수 있고 값을 예상할 수 있는 필드를 추천하기 때문에 위에서 다음과 같이 구분한다.
tag

host

servie

field

qps

rt

cpu

mem

load

실제 삽입 데이터

> insert myapp,host=127.0.0.1,service=app.service.index qps=1340,rt=1313,cpu=45.23,mem="4145m",load=1.21
> select * from myapp
name: myapp
time                cpu   host      load mem   qps  rt   service
----                ---   ----      ---- ---   ---  --   -------
1532597158613778583 45.23 127.0.0.1 1.21 4145m 1340 1313 app.service.index

a. 요약 설명

insert 실행 문장에서 tag와 tag,field와field 사이를 모두 잘 분할하고 tag와field 사이를 빈칸으로 분할

tag의value는 모두, String 유형이고 더블 인덱스를 붙일 필요가 없다

field의 String 형식 데이터는 더블 인덱스에 넣어야 합니다. 그렇지 않으면 오류가 발생

시간 스탬프 추가를 표시하려면 filed 뒤에 빈칸을 추가하고 시간 스탬프 추가

b. 필드가 없을 수 있는지 여부
실측이 안 되면 출력은 다음과 같다.

> insert myabb,host=123,service=index
ERR: {"error":"unable to parse 'myabb,host=123,service=index ': invalid field format"}

태그 없음 가능 여부
앞의 설명에 의하면 이미 실측하여

> insert myabb qps=123,rt=1231
> select * from myabb
name: myabb
time                qps rt
----                --- --
1532597385053030634 123 1231

2. 데이터 분석
새로 삽입된 데이터는 다음과 같습니다.

> select * from myapp
name: myapp
time                cpu   host      load mem   qps  rt   service
----                ---   ----      ---- ---   ---  --   -------
1532597158613778583 45.23 127.0.0.1 1.21 4145m 1340 1313 app.service.index
1532597501578551929 45.23 127.0.0.1 1.21 4145m 1341 1312 app.service.index
1532597510225918132 45.23 127.0.0.1 1.21 4145m 1341 1312 app.service.about
1532597552421996033 45.23 127.0.0.2 1.21 4145m 1341 1312 app.service.about

a. series
위의 네 가지 데이터는 몇 개의 시리즈에 대응합니까?
앞에서 말한 바와 같이tagKey+tagValue는 하나의 시리즈(실제로는measurement+retention policy+tags로 확정됨)에 확정되었다. 따라서 상기 표에는 모두 세 개의 시리즈가 있다.

127.0.0.1 | app.service.index

127.0.0.1 | app.service.about

127.0.0.2 | app.service.about

그럼 이 시리즈는 도대체 뭘까요?
만약 위의 데이터를 도표화하는 방식을 나타낸다면 우리는 어떻게 할 수 있습니까?

우선 응용 프로그램과 서비스 이름을 확정한 다음에 이 서비스가 이 기계에서 타임라인에서의 서비스 성능

을 확인한다.

번역하면 cpu/s서비스를 검색 조건으로 하고time를 시간축으로 하여value(cpu,load,mem,qps,rt)를 2차원 좌표에 비추어 점(point)으로 한 다음에 모든point를 선으로 연결하여 최종적으로 연속적인 도표

를 얻는다.
그래서 시리즈는 위의 검색 조건이고point의 개념도 쉽게 이해할 수 있다
III. 보존 정책
앞에는 표 데이터와 관련된 기초 개념이 있는데 여기에 데이터 저장 전략인 Retention policy가 하나 더 있는데 데이터 저장 기간을 결정하는 데 사용된다. (데이터를 삭제할 수 있다는 뜻), 몇 개의 백업, 집단 처리 등을 저장한다.
1. 기본 설명
fluxdb는 빅데이터의 시퀀스 데이터베이스를 대상으로 하기 때문에 데이터의 양이 매우 크다. 만약에 모두 저장한다면 하드디스크의 비용이 적지 않을 것이다. 그리고 일부 데이터는 영구적으로 저장할 필요가 없을 수도 있기 때문에 이rentention policy가 생겼다.
InfluxDB 자체는 데이터 삭제 작업을 제공하지 않기 때문에 데이터 양을 제어하는 방법은 데이터 보존 정책을 정의하는 것입니다.
따라서 데이터 보존 정책을 정의하는 목적은 InfluxDB가 어떤 데이터를 버릴 수 있는지 알고 데이터를 더욱 효율적으로 처리할 수 있도록 하는 것이다.
2. 기본 작업
a. 쿼리 정책

> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        true

name: 명칭

duration: 보존시간, 0은 영구보존

을 나타낸다

shardGroupDuration:shardGroup의 저장 시간,shardGroup은InfluxDB의 기본적인 저장 구조로 이 시간보다 큰 데이터는 조회 효율이 낮아져야 한다.

replicaN: 전칭REPLICATION, 던전 개수

default: 기본 정책인지 여부

b. 새 정책

> create retention policy "2_hour" on hh_test duration 2h replication 1 default
> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
2_hour  2h0m0s   1h0m0s             1        true

c. 정책 수정

> alter retention policy "2_hour" on hh_test duration 4h default
> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
2_hour  4h0m0s   1h0m0s             1        true

d. 정책 삭제

> drop retention policy "2_hour" on hh_test
> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false

기본 정책을 삭제하면 기본 정책이 없습니다. 문제가 있습니까?
3. RP 이해
이 정책을 설정하면 만료된 데이터가 자동으로 삭제됩니다. 그러면 데이터는 어떻게 저장됩니까?
예를 들어 기본 영구 저장 정책에 shardGroupDuration 파라미터가 있는데 7일이다. 즉, 7일의 데이터를 하나의shard에 놓고 지나간 다음에shard를 추가한다.
shard는 실제 인코딩 및 압축 데이터를 포함하며 디스크의 TSM 파일로 표시됩니다.모든 shard는 유일한 shard 그룹에 속합니다.여러 개의 shard가 하나의 shard group에 존재할 수 있습니다.각shard는 특정한 시리즈를 포함합니다.주어진 shard group의 주어진 시리즈의 모든 점은 디스크의 같은 shard (TSM 파일) 에 저장됩니다.
IV. 기타
1.회색Blog:https://liuyueyi.github.io/he...
잿빛 개인 블로그, 모든 학습과 업무 중의 박문을 기록하여, 여러분의 방문을 환영합니다.
2. 성명
책만 믿으면 안 된다. 이미 올린 내용은 모두 한 집안의 말이다. 개인의 능력에 한계가 있기 때문에 누락과 잘못된 점이 있기 마련이다. 예를 들어 버그를 발견하거나 더 좋은 건의가 있으면 비판과 시정을 환영하고 감격을 아끼지 않는다.

웨이보 주소: 작은 회색 Blog

QQ: 회색/3302797840

3. 주목 스캔
작은 회색 Blog & 공중번호
지식의 별