인플럭스DB(InfluxDB) #5 - Schema설계 및 데이터Layout

 

이번 포스팅은 요즘 핫한 InfluxDB에 대하여 작성하도록 하겠습니다.

InfluxDB 역시 작년 기상청 프로젝트에서 전국에서 관측되는 데이터를 효과적으로 처리하기 위하여 검토되었고 그때 자료조사를 한 내용입니다.

 

순서는 

 

2020/06/11 - [개발관련 자료] - InfluxDB #1 - 개요 및 특징

2020/06/11 - [개발관련 자료] - InfluxDB #2 - 주요 개념

2020/06/11 - [개발관련 자료] - InfluxDB #3 - 용어 정리

2020/06/11 - [개발관련 자료] - InfluxDB #4 - SQL DB와 비교

2020/06/11 - [개발관련 자료] - InfluxDB #5 - Schema설계 및 데이터Layout

2020/06/11 - [분류 전체보기] - InfluxDB #6 - In-Memory Indexing과 TSM(Time-Structured Merge Tree)

2020/06/11 - [개발관련 자료] - InfluxDB #7 - TSI(Time Series Index) 개요

2020/06/11 - [개발관련 자료] - InfluxDB #8 - TSI(Time Series Index) 세부 정보

2020/06/11 - [개발관련 자료] - InfluxDB #9 - Linux CentOS 설치

2020/06/12 - [개발관련 자료] - InfluxDB #10 - 사용법

 

으로 진행되며 도입 검토 차원에서 이루어진 조사라서 실무적용 보다는 InfluxDB란 어떤 것인지 파악하는 정도로만 생각하시면 될듯합니다.

 

---

모든 InfluxDB 유스케이스는 특별하며 스키마는 그 고유함을 반영합니다. 그러나 스키마를 설계할 때 따라야 할 일반적인 지침과 피해야 하는 사항 있습니다.

 

 

1. 일반적인 권장 사항

 

• 특별한 순서 없이 다음과 같이 하는 것이 좋습니다.
• 메타 데이터를 태그로 인코딩

      - 태그는 인덱싱되고 필드는 인덱싱되지 않습니다.

      - 즉, 태그에 대한 쿼리는 필드에 대한 쿼리보다 성능이 좋습니다.

      - 일반적으로 검색어는 태그로 저장된 내용과 필드로 저장되는 내용을 안내해야 합니다.

      - 데이터를 자주 쿼리하는 메타 데이터 인 경우 태그에 데이터 저장

      - 함께 사용할 계획이라면 데이터를 태그에 저장하십시오.

      - InfluxQL 함수와 함께 사용할 계획이라면 데이터를 필드에 저장하십시오.

      - 문자열이 아닌 다른 문자열이 필요한 경우 필드에 데이터 저장 - 태그 값은 항상 문자열로 해석됩니다.

 

 

• InfluxQL 키워드를 식별자 이름으로 사용하지 마십시오.

      - 이것은 필수는 아니지만 쿼리 작성을 단순화합니다.

      - 식별자를 큰따옴표로 묶을 필요가 없습니다.

      - 식별자는 데이터베이스 이름, 보존 정책 이름, 사용자 이름, 측정 이름, 태그 키 및 필드 키입니다.

      - 식별자가 다른 문자를 포함하고 있는 경우 식별자에 큰따옴표로 묶어야 합니다. ex)[A-z,_].

 

 

2. Discouraged schema design

 

• 특별한 순서 없이 다음과 같이 하는 것이 좋습니다.
• 너무 많은 시리즈를 갖지 않는다.

      - UUID, 해시 및 임의의 문자열과 같이 매우 가변적인 정보가 포함된 태그는 대개 높은 시리즈 카디널리티로 알려진 데이터베이스의 많은 수의 시리즈로 이어집니다.

      - 높은 시리즈 카디널리티는 많은 데이터베이스 워크로드에 대해 높은 메모리 사용량을 유발하는 주된 요인입니다.

      - 시스템에 메모리 제약 조건이 있는 경우 태그 대신 필드로 고급 카디널리티 데이터를 저장하는 것이 좋습니다.

 

• 측정 이름에 데이터 인코딩 안 함

      - 일반적으로 이 단계를 수행하면 쿼리가 간단해집니다.

      - InfluxDB는 동일한 측정 내에 속하는 데이터를 병합합니다.

      - 자세한 측정 이름보다 태그를 사용하여 데이터를 구분하는 것이 좋습니다.

       

ex) line protocol로 대표되는 다음 스키마를 고려하십시오.

 

Schema 1 - Data encoded in the measurement name   -------------   blueberries.plot-1.north temp=50.1 1472515200000000000   blueberries.plot-2.midwest temp=49.8 1472515200000000000

      - 태그가 없는 긴 측정 이름(blueberries.plot-1.north)은 흑연 인식과 비슷합니다.

      - plot이나 region 등의 정보를 측정 이름에 인코딩하면 데이터를 쿼리하기 어렵습니다.

      - 예를 들어, 플롯1과 플롯2 모두의 평균 온도를 계산하는 것은 스키마1에서 가능하지 않습니다.

      - 이를 라인 프로토콜에 표시된 다음 스키마와 비교하십시오.

 

Schema 2 - Data encoded in tags   -------------   weather_sensor,crop=blueberries,plot=1,region=north temp=50.1 1472515200000000000   weather_sensor,crop=blueberries,plot=2,region=midwest temp=49.8 1472515200000000000

 

      - 다음 쿼리는 north지역에 속하는 블루베리의 평균 temp을 계산합니다.

      - 두 쿼리 모두 비교적 간단 하지만 정규 표현식을 사용하면 특정 쿼리를 훨씬 복잡하거나 불가능하게 만들 수 있습니다.

 

# Schema 1 - Query for data encoded in the measurement name   > SELECT mean("temp") FROM /\.north$/     # Schema 2 - Query for data encoded in tags   > SELECT mean("temp") FROM "weather_sensor" WHERE "region" = 'north'

 

• 하나의 태그에 두 개 이상의 정보를 넣지 마십시오.

      - 위의 요점과 마찬가지로 단일 태그를 여러 조각으로 분리하여 태그로 분리하면 쿼리가 간단해지고 정규 표현식의 필요성이 줄어듭니다.

 

ex) line protocol로 대표되는 다음 스키마를 고려하십시오.

 

Schema 1 - Multiple data encoded in a single tag   -------------   weather_sensor,crop=blueberries,location=plot-1.north temp=50.1 1472515200000000000   weather_sensor,crop=blueberries,location=plot-2.midwest temp=49.8 1472515200000000000

 

      - 위의 데이터는 다수의 분리된 파라미터를 인코딩하여, plot과 region이 긴 태그 값( plot-1.north)으로 인코딩됩니다.

      - 이를 라인 프로토콜에 표시된 다음 스키마와 비교하십시오.

 

Schema 2 - Data encoded in multiple tags   -------------   weather_sensor,crop=blueberries,plot=1,region=north temp=50.1 1472515200000000000   weather_sensor,crop=blueberries,plot=2,region=midwest temp=49.8 1472515200000000000

 

      - 다음 쿼리는 north지역에 속하는 블루베리의 평균 temp를 계산합니다.

      - 두 쿼리가 비슷하지만 스키마 2에서 여러 태그를 사용하면 정규식을 사용할 필요가 없습니다.

 

# Schema 1 - Query for multiple data encoded in a single tag   > SELECT mean("temp") FROM "weather_sensor" WHERE location =~ /\.north$/     # Schema 2 - Query for data encoded in multiple tags   > SELECT mean("temp") FROM "weather_sensor" WHERE region = 'north'

 

 

3. Shard group 기간 관리

 

○ 샤드 그룹 기간 개요

• InfluxDB는 데이터를 샤드 그룹에 저장합니다.
• 샤드 그룹은 RP(Retention Policy)로 구성되며 특정 시간 간격 내에 있는 타임스탬프가 있는 데이터를 저장합니다.
• 이 시간 간격의 길이를 샤드 그룹 기간이라고 합니다.
• 샤드 그룹 지속 시간이 제공되지 않으면 샤드 그룹 지속 시간은 RP가 생성된 시점의 RP 지속 시간에 의해 결정됩니다. 기본값은 다음과 같습니다.

RP 지속 시간	샤드 그룹 기간
<2일	1시간
>=2일 및 <=6개월	1일
>6개월	7일

 

• 샤드 그룹 기간은 RP 당 구성할 수도 있습니다.

 

○ 샤드 그룹 지속 시간 트레이드 오프

• 최적의 샤드 그룹 지속 시간을 결정하려면 다음 사이의 균형을 찾아야 합니다.
• 더 긴 샤드로 전반적인 성능 향상

      - 샤드 그룹 길이가 길어지면 InfluxDB가 동일한 논리 위치에 더 많은 데이터를 저장할 수 있습니다.

      - 이렇게 하면 데이터 중복이 줄어들고 압축 효율성이 향상되며 경우에 따라 더 빠른 쿼리가 가능해집니다.

 

• 짧은 샤드가 제공하는 유연성

      - 샤드 그룹 기간을 짧게 하면 시스템이 데이터를 더 효율적으로 삭제하고 증분 백업을 기록 할 수 있습니다.

      - InfluxDB가 RP를 적용하면 RP 기간보다 오래된 점이 있더라도 개별 데이터 포인트가 아닌 전체 샤드 그룹을 삭제합니다.

      - 샤드 그룹은 샤드 그룹의 종료 시간 이 RP 지속 시간보다 오래된 경우에만 제거됩니다.

      - 예를 들어, RP의 하루 지속 시간이 1시간이면 InfluxDB는 매시간 1시간 분량의 데이터를 삭제하며 항상 25개의 샤드 그룹을 갖습니다.

      - 하루 중 매시간 하나씩, 부분적으로 만료되는 추가 샤드 그룹이 있지만, 전체 샤드 그룹이 24시간보다 오래될 때까지 제거되지 않습니다.

 

○ 샤드 그룹 기간 권장 사항

• 기본 샤드 그룹 지속 시간은 대부분의 경우 잘 작동합니다.
• 그러나 처리량이 많거나 오래 실행되는 인스턴스는 더 긴 샤드 그룹 기간을 사용하면 도움이 됩니다.
• 다음은 긴 샤드 그룹 기간에 대한 몇 가지 권장 사항입니다.

RP 지속 시간	샤드 그룹 기간
<=1일	6시간
1일 이상 7일 미만	1일
>7일 및 <=3개월	7일
>3개월	30일
무한한	52주 이상

 

• 샤드 그룹 기간을 결정할 때 고려해야 할 몇 가지 다른 요소는 다음과 같습니다.

      - 샤드 그룹은 가장 빈번한 쿼리의 가장 긴 시간 범위의 두 배가 되어야 합니다.

      - 샤드 그룹은 각각 샤드 그룹당 100,000개 이상의 포인트를 포함해야 합니다.

      - 샤드 그룹마다 시리즈당 1,000포인트이상 포함해야 합니다.

 

 

○ backfilling을 위한 샤드 그룹 기간

• 과거의 큰 시간 범위를 다루는 이력 데이터를 일괄적으로 삽입하면 한 번에 많은 수의 샤드가 생성됩니다.
• 수백 또는 수천 개의 조각으로 작성하는 동시 액세스 및 오버헤드로 인해 성능이 저하되고 메모리가 소모될 수 있습니다.
• 기록 데이터를 작성할 때 일시적으로 샤드 그룹 길이를 길게 설정하여 샤드를 적게 만들 것을 권장합니다.
• 일반적으로 샤드 그룹 기간이 52주이면 backfill 작업에 적합합니다.