Influxdb를 TSDB의 예로 생각해 봅시다. Influxdb는 시간 추가 전용 파일별로 데이터를 저장하는 것처럼 보입니다. 또한 추가하는 것뿐만 아니라 임의의 타임 스탬프를 사용하여 데이터를 삽입 할 수 있다고 주장합니다. IoT 세계에서는 과거의 일부 데이터 (예 : 일부 기기가 잠시 동안 오프라인 상태 였고 다시 온라인 상태로 전환되는 경우)를 가끔 발견하고이 데이터를 시계열에 배치하여 일부 차트를 그릴 수 있습니다. 이러한 시나리오를 어떻게 influxdb가 처리 할 수 있습니까? 추가 전용 파일을 완전히 다시 작성합니까?타임 스탬프가 포함 된 데이터를 과거의 시계열 DB에 삽입하십시오.
이렇게 이해합니다. InfluxDB는 데이터가있는 각 시간 블록에 대한 논리 데이터베이스 (샤드)를 만듭니다. 기본적으로 샤드 그룹 기간은입니다. 따라서 예를 들어 타임 스탬프가 포함 된 측정을 삽입하면 4 주 전, 그들은 다음 주에 파편에 영향을 미치지 않습니다.
각 샤드 내에서 들어오는 쓰기는 먼저 WAL (write ahead log)에 추가되고 메모리에 캐시됩니다. WAL 및 캐시가 충분히 꽉 차면 레벨 0 TSM (시간 구조화 된 병합 트리) 파일로 변환되어 디스크로 스냅 샷됩니다. 이 파일은 읽기 전용이며 측정은 먼저 시리즈별로 순서대로 수행됩니다.
TSM 파일이 커지면 함께 압축되어 레벨이 높아집니다. 여러 수준 0 스냅 샷은 압축되어 수준 1 파일을 생성합니다. 덜 자주, 여러 레벨 1 파일을 압축하여 레벨 2 파일을 생성하는 등 최대 레벨 4까지 압축합니다. 압축은 TSM 파일이 최소 일련의 세트를 포함하도록 (이상적으로) 최적화되고 다른 TSM과 최소한으로 겹치도록 보장합니다 파일. 이는 특정 시리즈/시간 조회에 필요한 TSM 파일 수를 줄여야 함을 의미합니다.
따라서 InfluxDB는 무작위 타임 스탬프로 쓰기 작업을 수행 할 때 어떻게 고통을 겪을까요? 타임 스탬프가 드문 드문 드문 드문 분단 그룹 기간이 짧은 경우, 즉 대부분의 쓰기가 다른 샤드를 치면, 우리는 많은 샤드로 끝날 것입니다. 이는 비효율적 인 많은 거의 비어 있지 않은 데이터 파일을 의미합니다 (바로이 문제는 해당 FAQ에서 다룹니다). 다른 한편, 임의의 시간 소인이 하나 또는 두 개의 샤드에 집중되어있는 경우, 해당 TSM 파일의 하위 레벨 TSM 파일은 시간이 상당히 겹치기 때문에 좁은 시간 범위의 u 리에서도 모든 파일을 검색해야합니다. 이것은 이러한 종류의 쿼리에서 읽기 성능에 영향을줍니다.
자세한 내용은 다음 리소스에서 찾을 수 있습니다 :