요즘 스터디에도 소홀해지고 ㅠ 하루종일 influxDB만 보고 있음
근데 공부해도 해도 볼 게 너무 많고 답도 없고
누군가 물어봤을 때 막힘없이 대답하고 싶은데 그것도 잘 안됨(,,,)
여튼 그간 알게 된 InfluxDB 관련 지식들을 정리해둬야 나중에 또 써먹을 것 같아서 주말이라 시간이 좀 생겼길래 글을 써봄
(그런데도 스터디 과제 아직 못한거 실화냐 나는 다음주에 죽은 목숨이다)
처음에 어려웠던 점은, NoSQL을 AWS에서 사용해봤음에도 불구하고 현업에서 필드가 많아지니까 쿼리나 구조를 이해하는 게 미친듯이 헷갈렸다는 거임
DB 구조가 우리가 알던 RDB와는 딴판이고, 자유롭다 못해 미친것같은 InfluxDB를 소개해보도록 하겠음
앞서 말한 내용에서 짐작이 가겠지만 NoSQL 기반임
강력한 Time-series DataBase라고 docs나 github에서 설명하고 있음
시작에 앞서 본 글은 ver.2.2 기준 InfluxDB Docs로 작성되었음을 알립니다.
인터넷에서 서칭할 때 가장 헷갈렸던 부분은, 2.0 버전으로 넘어오면서 진짜 '많은 게' 바뀌었는데, 대부분의 글들이 1.x 버전 기준이라서 docs와 맞지 않았다는 점임.
그래서 어느 순간부터는 그냥 docs만 보게 됐음.
그런데도 알지 못하는 부분은 물론 서칭했지만(,,) 일단 기본 설명을 한 후에 v1.x -> 2.2의 차이도 한번 정리를 해야겠다는 생각이 들었음
각설하고, 앞서 design principal에 대해 알아보겠음.
Design Principles
ref: https://docs.influxdata.com/influxdb/v2.2/reference/key-concepts/design-principles/
크게 이정도의 디자인 정책(? 정도로 해석할 수 있을듯) 이 있음
- 시간 순의 배열로 되어 있으며, (index가 timestamp임)
- Update와 Delete를 굉장히 제한함.
- Read와 Write에 초점이 맞추어져 있는 데이터베이스
- CRUD가 아닌 CRud 데이터베이스인데, 왜냐면 시계열 데이터베이스는 point 하나하나를 업데이트하거나 삭제하기보다는 많은 데이터들을 일단 집어넣고 querying하는 것에 초점이 맞추어질 수 밖에 없음 (그러려고 쓰는 거니까)
- schema가 없는 디자인을 따르고 있으며,
- 각각의 point보다 dataset을 우선시한다
- 마지막으로, 중복 데이터 핸들링이 특이하다.
- 간단하게 말하자면, 중복 데이터가 들어왔을 때 recent 값으로 업데이트 하는 것을 기준으로 두고 있는데, 그런 이유로 overwrite되는 경우가 있다. 라고 설명하고 있음.
Storage Engine
ref: https://docs.influxdata.com/influxdb/v2.2/reference/internals/storage-engine/
DB의 전체적인 흐름이 개인적으로 좀 이해하기 힘들어서 v1.x 데이터를 서칭했습니다. v2.2 부분 docs도 1.x 버전과 크게 다른 양상을 보이고 있지는 않아서 이해용으로 참고하기 좋을 것 같습니다.
Storage Engine의 경우 어떻게 DB가 works하고 있는가를 우리가 이해할 수 있게 묶어둔 인터페이스라고 볼 수 있음
독스에서는 이 스토리지 엔진이 어떻게 일하고 있는지를 내부적으로 보여주고 있다고 설명하고 있다.
스토리지 엔진은 API write 리퀘스트를 통해 물리적인 disk에 데이터를 write 함.
데이터는 line protocol이라는 특정한 형식(아래 설명할 것임)을 이용해서 HTTP POST 리퀘스트로 write endpoint에 보내지고, 이를 통해 influxDB에 데이터를 쓰는 것임
이 point들의 batch는 (influxDB는 데이터를 batch writing 함) WAL 형태로 쓰여짐.
또한 이 point는 in-memory cache에도 쓰여지게 되며, 바로 querying될 수 있게 되어진다.
in-memory cache는 주기적으로 TSM file의 형태로 disk에 쓰여지게 되고, TSM 파일들이 축적되면, 스토리지 엔진이 이들을 융합하고 줄여서 더 높은 레벨의 TSM 파일로 저장하는 형식을 가지고 있다.
뭔 개소리야라고 처음에 생각했는데, 정리하자면 이렇다.
Storage Engine의 개요
line protocol이라고 하는 방식을 통해 influxDB에 write를 한다. 그러면 스토리지 엔진은 이 데이터를 WAL 형태로 저장하고, in-memory cache에도 똑같이 쓰는데, 이 in-memory cache의 경우 바로 쿼리할 수 있게 만들어주는 역할을 한다고 보면 됨. 이 in-memory cache는 주기적으로 TSM파일의 형태로 만들어지고, 이 TSM 파일들이 많이 모이면 (또 디스크를 많이 차지하니까) 더 상위의 TSM 파일로 만들어서 더욱 더 compact하게 만든다는 게 Storage Engine에 관한 설명임.
그렇다면 이 각각의 것이 무엇이냐에 관한 학습이 필요할 것임.
독스가 너무 잘되어있어 잘 나와 있으니 같이 읽어보도록 합시다
WAL (Write Ahead Log)
WALWAL 왈왈 아님 개드립 죄송합니다 ㅋㅋㅋㅋㅋㅋㅋ
WAL은 storage engine이 재시작될 때 influxDB의 데이터를 유지시켜주는 역할을 수행합니다. 백업본 정도라고 생각할 수 있겠네요
여기가 중요, 스토리지 엔진은 데이터 write 리퀘스트를 받았을 때 이렇게 작동됨
1. write request가 WAL file의 끝에 append
2. 데이터가 fsync() 함수를 통해 디스크에 쓰여짐
3. in-memory cache가 업데이트됨
4. 디스크에 데이터가 잘 쓰여지면 성공
스토리지 엔진이 재시작 됐을 때, WAL 파일이 in-memory DB로 들어가게 되고, read request를 해줄 수 있음.
Cache
캐시란 WAL에 들어가 있는 데이터의 in-memory 카피본
WAL과 캐시는 분리된 entity이고 상호작용하지 않는다.
- 포인트-키 로 이루어져 있으며, 각각의 필드들은 각각의 시간 배열로 구성됨
- 압축되지 않는 데이터
- 스토리지 엔진이 재시작될때마다 WAL에게서 데이터를 받아온다. 캐시는 쿼링되어지고 TSM 파일과 머지되는 역할을 함
- 메모리의 maxSize 바이트 최대치를 사용함
(솔직히 이건 모르겠다)
- 캐시 스냅샷은 TSM 파일로 쓰여져 있는 캐시 오브젝트들을 말함.
- 캐시 스냅샷은 버퍼에 있는 데이터들이 처리될 동안 memory에 보존되어, 그동안 쿼리될 수 있는 것임
Time-Structed Merge Tree (TSM)
ref: https://docs.influxdata.com/resources/videos/tsm-engine/
개인적으로 이 부분이 InfluxDB의 꽃이라고 생각하고, 독스도 그랬는지 친절하게 영상까지 있다.
대충 정리해 보자면 이렇다.
윗 부분의 형태와 같은 데이터는 아래와 같은 형태의 series들로 저장됨.
아래의 형태들이 TSM 파일이고, 이 형태로 저장된 파일들은 앞서 말했듯 더 압축될 수도 있음. (higher level이라고 했으니까)
그리고 독스에 따르면, 더 베스트한 방법은 TSM 파일도 중복되는 것은 저장하지 않는 게 더 좋은 방법이라고 말하고 있음. (그것은 엔진의 몫 유저의 몫은 아님 아마도.)
아무튼 이 TSM 파일들이 저장되고 나면 WAL과 캐시가 지워짐.
그럼 이 압축 프로세스는 "읽기에 최적화 된" TSM 파일만을 남기게 됨. 그리고 더 higher level의 TSM으로 저장하는 건 쉽다고 하는데 거기까진 굳이?
Time-Series Index (TSI)
마지막으로 이 TSI가 있음.
데이터의 cardinality (중복성?) 가 증가할수록, 쿼리가 느려지는 건 당연함
TSI는 seriest의 key들을 그룹화해서 저장하는데, 그러면 series에 접근하기가 빨라지겠군요?
TSI는 DB가 "어떤 measurement, tag, field가 있는지"와 "주어진 measurement, tag, field를 통해 어떤 seriest keys가 존재하는가"에 대답하기 쉽게 만들어 주는 역할을 한다.
