점점 더 많은 엔터프라이즈 데이터가 저장됨에 따라 스토리지 용량, 쿼리 성능 및 스토리지 비용 간의 모순은 기술 팀의 일반적인 문제입니다. 이 문제는 Elasticsearch와 ClickHouse의 두 가지 시나리오에서 특히 두드러집니다.서로 다른 핫 데이터의 쿼리 성능 요구 사항을 충족하기 위해 이 두 구성 요소는 아키텍처 설계에서 데이터를 계층화하기 위한 몇 가지 전략을 가지고 있습니다.
동시에 스토리지 미디어 측면에서 클라우드 컴퓨팅의 발달과 함께 개체 스토리지는 저렴한 가격과 탄력적인 확장 공간으로 인해 기업의 호의를 얻었습니다. 점점 더 많은 기업이 웜 데이터와 콜드 데이터를 개체 스토리지로 마이그레이션합니다. 그러나 인덱스 및 분석 구성 요소가 오브젝트 스토리지에 직접 연결되면 쿼리 성능 및 호환성과 같은 문제가 발생합니다.
이 기사에서는 이 두 가지 시나리오에서 핫 및 콜드 데이터 계층화의 기본 원칙과 JuiceFS를 사용하여 객체 스토리지에 존재하는 문제를 처리하는 방법을 소개합니다.
01- Elasticsearch 데이터 계층 구조에 대한 자세한 설명
ES가 핫 및 콜드 데이터 계층화 전략을 구현하는 방법을 소개하기 전에 세 가지 관련 개념인 데이터 스트림, 인덱스 수명 주기 관리 및 노드 역할을 이해하겠습니다.
데이터 스트림
Data Stream(데이터 스트림)은 ES에서 중요한 개념으로 다음과 같은 특징을 가지고 있습니다.
- 스트리밍 쓰기: 고정 크기 컬렉션이 아니라 스트림으로 작성된 데이터 세트입니다.
- 추가 전용 쓰기: 추가 쓰기 방식으로 데이터를 업데이트하고 기록 데이터를 수정할 필요가 없습니다.
- 타임스탬프: 각각의 새 데이터 조각에는 데이터가 생성되었을 때 타임스탬프 레코드가 있습니다.
- 다중 인덱스: ES에는 인덱스 개념이 있으며 각 데이터 조각은 결국 해당 인덱스에 속하지만 데이터 흐름은 더 높은 수준의 더 큰 개념이며 데이터 흐름 뒤에 많은 인덱스가 있을 수 있습니다. 다른 규칙에 따라 생성됩니다. 데이터 스트림은 많은 인덱스로 구성되어 있지만 최신 인덱스만 쓰기 가능하고 기록 인덱스는 읽기 전용이며 일단 고정되면 수정할 수 없습니다.
로그 데이터는 데이터 스트림의 특성에 부합하는 데이터 유형으로 추가 및 기록만 가능하며 타임스탬프도 있어야 합니다.사용자는 일별 또는 기타 차원과 같은 다른 차원을 기반으로 새로운 인덱스를 생성합니다.
아래 그림은 데이터 흐름 인덱싱의 간단한 예입니다.데이터 흐름을 사용하는 과정에서 ES는 기록 인덱스 대신 최신 인덱스에 직접 기록하며 기록 인덱스는 수정되지 않습니다. 앞으로 더 많은 새로운 데이터가 생성됨에 따라 이 인덱스도 오래된 인덱스로 침전됩니다.
아래 그림과 같이 사용자가 ES에 데이터를 쓰면 크게 두 단계로 나뉩니다.
- 1단계: 데이터가 먼저 메모리의 인 메모리 버퍼 버퍼에 기록됩니다.
- 2단계: 버퍼는 특정 규칙과 시간에 따라 로컬 디스크로 떨어지며, 이는 ES에서 세그먼트라고 하는 아래 그림의 녹색 영구 데이터입니다.
이 과정에서 약간의 시차가 있을 수 있으며, Persistence 과정에서 쿼리를 트리거하면 새로 생성된 Segment를 검색할 수 없습니다. 세그먼트가 지속되면 상위 쿼리 엔진에서 즉시 검색할 수 있습니다.
인덱스 수명 주기 관리
ILM이라고 하는 인덱스 수명 주기 관리는 인덱스 수명 주기 관리입니다. ILM은 인덱스의 수명 주기를 5단계로 정의합니다.
- 핫 데이터(Hot): 자주 업데이트하거나 쿼리해야 하는 데이터입니다.
- 웜 데이터(Warm): 더 이상 업데이트되지 않지만 여전히 자주 쿼리되는 데이터입니다.
- 콜드 데이터(Cold): 더 이상 업데이트되지 않고 쿼리 빈도가 낮은 데이터입니다.
- 고정 데이터: 더 이상 업데이트되지 않고 거의 쿼리되지 않는 데이터입니다. 이러한 종류의 데이터는 상대적으로 가장 느리고 저렴한 저장 매체에 안전하게 저장할 수 있습니다.
- 데이터 삭제(Delete): 더 이상 필요하지 않으며 안심하고 삭제할 수 있는 데이터입니다.
인덱스든 세그먼트든 인덱스의 데이터는 이 단계를 거치게 되는데 이 분류 규칙은 사용자가 ES의 데이터를 매우 잘 관리할 수 있도록 도와주며 사용자가 스스로 여러 단계에 대한 규칙을 정의할 수 있습니다.
노드 역할
ES에서 각 배포 노드에는 노드 역할인 노드 역할이 있습니다. 각 ES 노드에는 마스터, 데이터, 수집 등과 같은 다른 역할이 할당됩니다. 사용자는 데이터 관리를 위해 위에서 언급한 다양한 수명 주기의 단계와 노드 역할을 결합할 수 있습니다.
데이터 노드에는 핫 데이터를 저장하는 노드, 웜 데이터, 콜드 데이터 또는 극도로 콜드 데이터를 저장하는 노드 등 다양한 단계가 있습니다. 기능에 따라 노드에 서로 다른 역할을 할당하고 역할이 다른 노드에 대해 서로 다른 하드웨어를 구성해야 합니다.
예를 들어 핫 데이터 노드의 경우 고성능 CPU 또는 디스크를 구성해야 하며, 웜 및 콜드 데이터 노드의 경우 기본적으로 데이터 쿼리 빈도가 낮은 것으로 간주되며 이때 특정 컴퓨팅 리소스에 대한 하드웨어 요구 사항은 다음과 같습니다. 실제로 그렇게 높지 않습니다. .
노드 역할은 수명 주기의 여러 단계에 따라 정의되며 각 ES 노드는 여러 역할을 가질 수 있으며 이러한 역할은 일대일 대응이 아닙니다. 예를 들어 ES의 YAML 파일에서 구성할 때 node.roles는 노드 역할의 구성입니다. 이 노드에 대한 역할에 따라 여러 역할을 구성할 수 있습니다.
node.roles: ["data_hot", "data_content"]
라이프 사이클 정책
데이터 스트림, 인덱스 수명 주기 관리 및 노드 역할의 개념을 이해한 후 데이터에 대한 몇 가지 다른 수명 주기 정책을 만들 수 있습니다.
인덱스의 크기, 인덱스의 문서 수, 인덱스가 생성된 시간과 같이 수명 주기 정책에 정의된 다양한 차원의 인덱스 특성에 따라 ES는 사용자가 자동으로 데이터를 롤링하도록 도울 수 있습니다. 특정 수명 주기 단계에서 다른 단계로, ES의 용어는 롤오버입니다.
예를 들어 사용자는 인덱스 크기 차원을 기반으로 기능을 지정하거나, 핫 데이터를 웜 데이터로 롤링하거나, 웜 데이터를 콜드 데이터로 롤링할 수 있습니다. 이러한 방식으로 수명 주기의 여러 단계 간에 인덱스가 롤링될 때 해당 인덱스 데이터도 마이그레이션되고 롤링됩니다. ES는 이러한 작업을 자동으로 완료할 수 있지만 수명 주기 정책은 사용자가 정의해야 합니다.
아래 스크린샷은 사용자가 수명 주기 정책을 그래픽으로 구성할 수 있는 Kibana의 관리 인터페이스입니다. 위에서 아래로 핫 데이터, 웜 데이터, 콜드 데이터의 세 단계가 있음을 알 수 있습니다.
핫 데이터 단계의 고급 설정을 확장하면 아래 그림의 오른쪽에 표시된 세 가지 옵션과 같이 다른 차원 특성을 기반으로 위에서 언급한 정책 구성을 더 자세히 볼 수 있습니다.
- 인덱스의 크기는 다이어그램의 예에서 50GB이며, 인덱스의 크기가 50GB를 초과하면 핫 데이터 단계에서 웜 데이터 단계로 롤링됩니다.
- 문서의 최대 수는 ES의 인덱스 단위는 문서이고 사용자 데이터는 문서의 형태로 ES에 기록되므로 문서의 수 또한 측정 가능한 지표입니다.
- 최대 인덱스 생성 시간.예시 30일.인덱스가 30일 동안 생성되었다고 가정하면 이 시점에서 방금 언급한 핫 데이터 단계에서 웜 데이터로의 롤오버가 트리거됩니다.
02- ClickHouse 데이터 계층 구조에 대한 자세한 설명
아래 그림은 MergeTree 엔진인 ClickHouse의 데이터 관리 모드를 생생하게 보여주는 러시아 네스팅 인형 세트입니다.
- 테이블: 그림 맨 오른쪽에는 가장 큰 개념이 있습니다. 사용자가 가장 먼저 생성하거나 직접 액세스하려는 것은 테이블입니다.
- 파티션: 더 작은 차원 또는 더 작은 세분성입니다. ClickHouse에서 데이터는 저장을 위한 파티션으로 나뉘며 각 파티션에는 식별자가 있습니다.
- 파트: 각 파티션에서 여러 파트로 더 세분화됩니다. ClickHouse 디스크에 저장된 데이터 형식을 보면 각 하위 디렉터리가 파트라고 생각할 수 있습니다.
- Column: Part에서 일부 더 작은 데이터, 즉 Column을 볼 수 있습니다. ClickHouse의 엔진은 컬럼 스토리지를 사용하며 모든 데이터는 컬럼 스토리지로 구성됩니다. Part 디렉토리에 많은 열이 표시됩니다.예를 들어 테이블에 100개의 열이 있으면 100개의 열 파일이 있습니다.
- 블록: 각 열 파일은 블록 단위에 따라 구성됩니다.
다음 예에서는 테이블 디렉터리 아래에 4개의 하위 디렉터리가 있으며 각 하위 디렉터리는 위에서 언급한 Part입니다.
$ ls -l /var/lib/clickhouse/data/<database>/<table>
drwxr-xr-x 2 test test 64B Aug 8 13:46 202208_1_3_0
drwxr-xr-x 2 test test 64B Aug 8 13:46 202208_4_6_1
drwxr-xr-x 2 test test 64B Sep 8 13:46 202209_1_1_0
drwxr-xr-x 2 test test 64B Sep 8 13:46 202209_4_4_
다이어그램의 가장 오른쪽 열에서 각 하위 디렉토리의 이름 앞에는 202208과 같이 시간이 붙을 수 있습니다. 이 접두어는 202208이 실제로 파티션의 이름입니다. 파티션 이름은 사용자가 직접 정의하지만 규칙이나 일부 관행에 따라 일반적으로 이름 지정에 시간이 사용됩니다.
예를 들어 파티션 202208에는 두 개의 하위 디렉터리가 있고 하위 디렉터리는 부품입니다. 파티션은 일반적으로 여러 부품으로 구성됩니다. 사용자가 ClickHoue에 데이터를 쓰면 먼저 메모리에 쓰여진 다음 메모리의 데이터 구조에 따라 디스크에 지속됩니다. 동일한 파티션의 데이터가 상대적으로 크면 디스크에서 많은 부분이 됩니다. ClickHouse는 테이블 아래에 너무 많은 부품을 만들지 말 것을 공식적으로 권장합니다. 정기적 또는 비정기적으로 부품을 병합하여 총 부품 수를 줄입니다. Merge의 개념은 MergeTree 엔진의 이름의 유래 중 하나인 Part를 병합하는 것입니다.
예제를 통해 파트를 이해해 봅시다. Part에는 많은 작은 파일이 있을 것이며, 그 중 일부는 사용자가 데이터를 빠르게 찾을 수 있도록 인덱스 정보와 같은 메타 정보입니다.
$ ls -l /var/lib/clickhouse/data/<database>/<table>/202208_1_3_0
-rw-r--r-- 1 test test ?? Aug 8 14:06 ColumnA.bin
-rw-r--r-- 1 test test ?? Aug 8 14:06 ColumnA.mrk
-rw-r--r-- 1 test test ?? Aug 8 14:06 ColumnB.bin
-rw-r--r-- 1 test test ?? Aug 8 14:06 ColumnB.mrk
-rw-r--r-- 1 test test ?? Aug 8 14:06 checksums.txt
-rw-r--r-- 1 test test ?? Aug 8 14:06 columns.txt
-rw-r--r-- 1 test test ?? Aug 8 14:06 count.txt
-rw-r--r-- 1 test test ?? Aug 8 14:06 minmax_ColumnC.idx
-rw-r--r-- 1 test test ?? Aug 8 14:06 partition.dat
-rw-r--r-- 1 test test ?? Aug 8 14:06 primary.id
예제의 오른쪽에서 Column이 접두어로 붙은 파일은 실제 데이터 파일이며 일반적으로 메타 정보에 비해 크기가 큽니다. 이 예에서는 A와 B 두 개의 열만 있지만 실제 테이블에는 많은 열이 있을 수 있습니다. 메타 정보와 색인 정보를 포함한 이 모든 파일은 함께 작동하여 사용자가 다른 파일 사이를 빠르게 이동하거나 검색할 수 있도록 도와줍니다.
ClickHouse 스토리지 전략
ClickHouse에서 핫 데이터와 콜드 데이터를 계층화하려면 ES에서 언급한 것과 유사한 수명 주기 정책을 사용합니다. 이를 ClickHouse의 스토리지 정책이라고 합니다.
ES와 약간 다른 ClickHouse는 공식적으로 데이터를 핫 데이터, 웜 데이터, 콜드 데이터와 같은 다른 단계로 나누지 않습니다.ClickHouse는 몇 가지 규칙과 구성 방법을 제공하며 사용자는 계층화 전략을 스스로 공식화해야 합니다.
각 ClickHouse 노드는 동시에 여러 디스크 구성을 지원하며 저장 매체는 다양할 수 있습니다. 예를 들어 일반 사용자는 성능을 위해 ClickHouse 노드용 SSD 디스크를 구성하고 일부 웜 및 콜드 데이터의 경우 사용자는 기계식 디스크와 같은 저렴한 미디어에 데이터를 저장할 수 있습니다. ClickHouse 사용자는 기본 저장 매체를 인식하지 못합니다.
ES와 유사하게 ClickHouse 사용자는 각 부분 하위 디렉토리의 크기, 전체 디스크의 남은 공간 비율 등과 같은 데이터의 다양한 차원 특성을 기반으로 저장 전략을 공식화해야 합니다. 충족되면 스토리지가 트리거됩니다. 전략 실행. 이 전략은 한 디스크에서 다른 디스크로 부품을 마이그레이션합니다. ClickHouse에서는 노드에 의해 구성된 여러 디스크가 우선 순위를 가지며 기본적으로 데이터는 우선 순위가 가장 높은 디스크에 떨어집니다. 이를 통해 부품을 하나의 저장 매체에서 다른 저장 매체로 전송할 수 있습니다.
MOVE PARTITION/PART 명령과 같은 ClickHouse의 일부 SQL 명령은 수동으로 데이터 마이그레이션을 트리거할 수 있으며 사용자는 이러한 명령을 통해 일부 기능 검증을 수행할 수도 있습니다. 둘째, 어떤 경우에는 자동 전송이 아닌 수동을 통해 현재 저장 매체에서 다른 저장 매체로 부품을 명시적으로 전송하는 것이 바람직할 수도 있습니다.
ClickHouse는 스토리지 정책과 독립적인 개념인 시간 기반 마이그레이션 정책도 지원합니다. 데이터가 기록된 후 ClickHouse는 각 테이블의 TTL 속성에 의해 설정된 시간에 따라 디스크에서 데이터 마이그레이션을 트리거합니다. 예를 들어 TTL이 7일로 설정된 경우 ClickHouse는 현재 디스크(예: 기본 SSD)에서 우선 순위가 낮은 다른 디스크(예: JuiceFS)로 테이블의 데이터를 7일 이상 기록합니다.
03- 웜 및 콜드 데이터 스토리지: 개체 스토리지 + JuiceFS를 사용하는 이유는 무엇입니까?
기업이 클라우드에 웜 및 콜드 데이터를 저장하면 기존 SSD 아키텍처에 비해 스토리지 비용이 크게 절감됩니다. 기업은 또한 클라우드에서 탄력적인 확장 공간을 즐길 수 있으며 확장 및 축소 또는 일부 데이터 정리 작업과 같은 데이터 스토리지에 대한 운영 및 유지 관리 작업을 수행할 필요가 없습니다 . 웜 및 콜드 데이터에 필요한 저장 용량은 핫 데이터보다 훨씬 크며, 특히 시간이 지날수록 장기간 저장해야 하는 대량의 데이터가 생성됩니다. 해당 운영 및 유지 보수 작업에 압도됩니다.
하지만 오브젝트 스토리지에 Elasticsearch, ClickHouse와 같은 데이터 애플리케이션 구성 요소를 사용하면 쓰기 성능 및 호환성이 떨어지는 등의 문제가 발생합니다. 쿼리 성능을 고려하려는 기업은 클라우드에서 솔루션을 찾기 시작했습니다. 이러한 맥락에서 JuiceFS는 데이터 계층 아키텍처에서 점점 더 많이 사용되고 있습니다 .
다음 ClickHouse 쓰기 성능 테스트를 통해 SSD, JuiceFS 및 개체 스토리지에 대한 쓰기 성능 차이를 직관적으로 이해할 수 있습니다.
JuiceFS의 쓰기 처리량은 직접 연결된 개체 스토리지보다 훨씬 높고 SSD에 가깝습니다 . 사용자가 핫 데이터를 웜 데이터 계층으로 전송할 때 쓰기 성능에 대한 특정 요구 사항도 있습니다. 마이그레이션 프로세스 중에 기본 저장 매체의 쓰기 성능이 좋지 않으면 전체 마이그레이션 프로세스가 오랫동안 지연되어 전체 파이프라인 또는 데이터 관리에 일부 문제가 발생합니다.
아래 그림의 ClickHouse 쿼리 성능 테스트는 실제 비즈니스 데이터를 사용하고 테스트를 위해 몇 가지 일반적인 쿼리 시나리오를 선택합니다. 그 중 q1-q4는 전체 테이블을 스캔하는 쿼리이고 q5-q7은 기본 키 인덱스에 도달하는 쿼리입니다. 테스트 결과는 다음과 같습니다.
JuiceFS와 SSD 디스크의 쿼리 성능은 기본적으로 동일하며 평균 6% 정도의 차이가 있지만 개체 스토리지의 성능은 SSD 디스크보다 1.4~30배 낮습니다 . JuiceFS의 고성능 메타데이터 작업 및 로컬 캐싱 기능 덕분에 쿼리 요청에 필요한 핫 데이터가 ClickHouse 노드에 로컬로 자동으로 캐싱되어 ClickHouse의 쿼리 성능이 크게 향상됩니다. 참고로 위 테스트에서 오브젝트 스토리지는 ClickHouse의 S3 디스크 유형을 통해 액세스하므로 오브젝트 스토리지에는 데이터만 저장되고 메타데이터는 여전히 로컬 디스크에 있습니다. 오브젝트 스토리지가 S3FS와 유사한 방식으로 로컬에 마운트되면 성능이 더욱 저하됩니다.
또한 JuiceFS는 POSIX와 완전히 호환되는 파일 시스템이며 상위 계층 애플리케이션(예: Elasticsearch, ClickHouse)과 잘 호환된다는 점도 언급할 가치가 있습니다. 사용자는 기본 스토리지가 분산 파일 시스템인지 로컬 디스크인지 알지 못합니다. 오브젝트 스토리지를 직접 사용하면 상위 계층 애플리케이션과의 호환성을 잘 얻을 수 없습니다.
04- 실제 작동: ES + JuiceFS
1단계: 여러 유형의 노드를 준비하고 다른 역할을 할당합니다 . 각 ES 노드에는 핫 데이터, 웜 데이터, 콜드 데이터 저장 등과 같은 다양한 역할을 할당할 수 있습니다. 사용자는 다양한 역할의 요구 사항에 맞게 다양한 모델의 노드를 준비해야 합니다.
2단계: JuiceFS 파일 시스템을 마운트합니다 . 일반적으로 사용자는 웜 및 콜드 데이터 스토리지에 JuiceFS를 사용하며 ES 웜 데이터 노드 또는 콜드 데이터 노드에 JuiceFS 파일 시스템을 로컬로 마운트해야 합니다. 사용자는 기호 링크 또는 기타 방법을 통해 ES에 대한 마운트 지점을 구성할 수 있으므로 ES는 데이터가 로컬 디렉터리에 저장되어 있다고 생각하지만 이 디렉터리 뒤에는 실제로 JuiceFS 파일 시스템이 있습니다.
3단계: 수명 주기 정책 생성 . 이는 각 사용자가 사용자 정의해야 합니다. 사용자는 ES API 또는 Kibana를 통해 생성할 수 있습니다. Kibana는 수명 주기 정책을 생성하고 관리하는 비교적 편리한 방법을 제공합니다.
4단계: 인덱스에 대한 수명 주기 정책을 설정합니다 . 수명 주기 정책을 생성한 후 사용자는 이 정책을 인덱스에 적용해야 합니다. 즉, 인덱스에 대해 새로 생성된 정책을 설정해야 합니다. 사용자는 인덱스 템플릿을 통해 Kibana에서 인덱스 템플릿을 생성하거나 index.lifycycle.name을 통해 API를 통해 명시적으로 구성할 수 있습니다.
다음은 몇 가지 팁입니다.
팁 1: Warm 또는 Cold 노드의 복사본(복제본) 수는 1로 설정할 수 있습니다 . 모든 데이터는 기본적으로 JuiceFS에 배치되며 그 하위 계층은 개체 스토리지이므로 데이터의 신뢰성은 이미 충분히 높으므로 ES 측에서 사본 수를 적절하게 줄여 스토리지 공간을 절약할 수 있습니다.
팁 2: 강제 병합을 켜면 노드 CPU가 계속 점유될 수 있으므로 적절하게 끄십시오 . 핫 데이터에서 웜 데이터로 전송할 때 ES는 모든 핫 데이터 인덱스에 해당하는 기본 세그먼트를 병합합니다. 강제 병합 기능이 활성화된 경우 ES는 먼저 이러한 세그먼트를 병합한 다음 웜 데이터의 기본 시스템에 저장합니다. 그러나 세그먼트 병합은 매우 CPU를 많이 사용하는 프로세스입니다.웜 데이터의 데이터 노드도 일부 쿼리 요청을 수행해야 하는 경우 이 기능을 적절하게 해제할 수 있습니다. 저장.
팁 3: 웜 또는 콜드 단계의 인덱스는 읽기 전용으로 설정할 수 있습니다 . 웜 데이터 및 콜드 데이터 단계를 인덱싱할 때 기본적으로 이러한 데이터를 읽기 전용으로 간주할 수 있으며 이러한 단계의 인덱스는 수정되지 않습니다. 읽기 전용으로 설정하면 일부 메모리를 해제하는 등 웜 및 콜드 데이터 노드의 리소스를 적절하게 줄일 수 있으므로 웜 또는 콜드 노드의 일부 하드웨어 리소스를 절약할 수 있습니다.
05- 실제 작동: ClickHouse + JuiceFS
**1단계: 모든 ClickHouse 노드에 JuiceFS 파일 시스템을 탑재합니다. **이 경로는 모든 경로가 될 수 있습니다. ClickHouse에는 마운트 지점을 가리키는 구성 파일이 있기 때문입니다.
**2단계: ClickHouse 구성을 수정하고 JuiceFS 디스크를 추가합니다. **ClickHouse가 새 디스크를 인식할 수 있도록 새로 마운트된 JuiceFS 파일 시스템 마운트 지점을 ClickHouse에 추가합니다.
**3단계: 스토리지 정책을 추가하고 데이터 싱킹 규칙을 설정합니다. **이 저장 정책은 사용자의 규칙에 따라 기본 디스크에서 JuiceFS와 같은 지정된 디스크로 데이터를 비정기적으로 자동 싱크합니다.
**4단계: 특정 테이블에 대한 스토리지 정책 및 TTL을 설정합니다. **스토리지 전략을 수립한 후 특정 테이블에 적용해야 합니다. 테스트 및 검증 초기 단계에서 상대적으로 큰 테이블을 테스트 및 검증에 사용할 수 있으며, 사용자가 시간 차원에 따라 데이터를 싱크하려면 테이블에 TTL도 설정해야 합니다. 전체 싱킹 과정은 자동 메커니즘으로, ClickHouse의 시스템 테이블을 통해 현재 데이터 마이그레이션이 진행 중인 부품과 마이그레이션 진행 상황을 볼 수 있습니다.
**5단계: 확인을 위해 부품을 수동으로 이동합니다. ** MOVE PARTITION 명령을 수동으로 실행하여 현재 구성 또는 스토리지 정책이 유효한지 확인할 수 있습니다.
storage_configuration 아래 그림은 구체적인 예입니다. ClickHouse에는 디스크 구성을 포함하는 구성 항목이 있습니다. 여기에서 JuiceFS는 디스크로 추가됩니다. 이름을 "jfs"로 지정하지만 어떤 이름으로도 마운트할 수 있습니다 . . 점은 /jfs디렉토리입니다.
<storage_configuration> <disks> <jfs> <path>/jfs</path> </jfs> </disks> <policies> <hot_and_cold> <volumes> <hot> <disk>default</disk> <max_data_part_size_bytes>1073741824</max_data_part_size_bytes> </hot> <cold> <disk>jfs</disk> </cold> </volumes> <move_factor>0.1</move_factor> </hot_and_cold> </policies></storage_configuration>
더 아래에는 이라는 스토리지 정책을 정의하는 정책 구성 항목이 있습니다 hot_and_cold . 사용자는 핫 우선 순위에 따라 볼륨을 정렬한 다음 콜드 우선 순위에 따라 볼륨을 정렬하고 데이터는 먼저 다음으로 떨어지는 것과 같은 몇 가지 특정 규칙을 정의해야 합니다. 볼륨 디스크의 첫 번째 핫 및 기본 ClickHouse 디스크(일반적으로 로컬 SSD)입니다.
볼륨의 max_data_part_size_bytes 구성은 특정 부분의 크기가 설정된 크기를 초과하면 스토리지 정책의 실행이 트리거되고 해당 부분이 다음 볼륨, 즉 콜드 볼륨으로 싱크됨을 나타냅니다. 위의 예에서 콜드 볼륨은 JuiceFS입니다.
하단의 구성은 move_factor ClickHouse가 현재 디스크의 남은 공간 비율에 따라 스토리지 정책의 실행을 트리거한다는 의미입니다.
CREATE TABLE test ( d DateTime, ...) ENGINE = MergeTree...TTL d + INTERVAL 1 DAY TO DISK 'jfs'SETTINGS storage_policy = 'hot_and_cold'；
위 코드와 같이 스토리지 정책을 설정한 후 테이블을 생성하거나 이 테이블의 스키마를 수정할 때 SETTINGS의 storage_policy를 이전에 정의한 hot_and_cold 스토리지 정책으로 설정할 수 있습니다. 위 코드의 끝에서 두 번째 줄의 TTL은 위에서 언급한 시간 기반 레이어링 규칙입니다. 이 예에서 지정된 테이블의 d라는 열은 DateTime 유형이며 INTERVAL 1 DAY를 결합하면 새로운 데이터가 하루 이상 기록되면 데이터가 JuiceFS로 전송됩니다.
06- 전망
**첫째, 복사 공유. **ES든 ClickHouse든 데이터의 가용성과 신뢰성을 보장하기 위해 여러 개의 사본을 가지고 있습니다. JuiceFS는 기본적으로 공유 파일 시스템입니다. 데이터가 JuiceFS에 기록된 후에는 여러 복사본을 유지할 필요가 없습니다. 예를 들어, 사용자가 두 개의 ClickHouse 노드를 가지고 있고 둘 다 특정 테이블 또는 특정 부분의 복사본을 가지고 있고 두 노드가 모두 JuiceFS에 가라앉는 경우 동일한 데이터를 두 번 쓸 수 있습니다. ** 향후 상위 레이어 엔진에서 하위 레이어가 공유 스토리지를 사용한다는 사실을 인식하고, 데이터 싱크 시 복사본 수를 줄여 서로 다른 노드 간에 복사본을 공유할 수 있도록 할 수 있을까요? **애플리케이션 계층의 관점에서 볼 때 사용자가 테이블을 볼 때 부분의 수는 여전히 여러 복사본이지만 실제로 데이터가 본질적으로 공유될 수 있기 때문에 기본 저장소에는 하나의 복사본만 유지됩니다.
** 두 번째 포인트는 장애 복구입니다. **데이터가 원격 공유 스토리지에 가라앉은 후 ES 또는 ClickHousle 노드에 장애가 발생하면 장애에서 신속하게 복구하는 방법은 무엇입니까? 핫 데이터를 제외한 대부분의 데이터는 실제로 원격 공유 스토리지로 전송되었으며, 이때 새로운 노드를 복원하거나 생성하려는 경우 비용이 기존 로컬 디스크 기반 장애 복구 방법보다 훨씬 가벼울 것입니다. ES 또는 ClickHouse 시나리오에서 살펴볼 가치가 있습니다.
**세 번째 포인트는 저장과 계산의 분리입니다. **ES 또는 ClickHouse에 관계없이 전체 커뮤니티는 이러한 기존 로컬 디스크 기반 스토리지 시스템을 클라우드 네이티브 환경에서 실제 스토리지 컴퓨팅 분리 시스템으로 만드는 방법을 시도하거나 탐색하고 있습니다. 그러나 스토리지-컴퓨팅 분리는 단순히 데이터와 컴퓨팅을 분리하는 것이 아니라 쿼리 성능 요구사항, 쓰기 성능 요구사항, 다양한 차원의 튜닝 요구사항 등 상위 계층의 다양한 복합적 요구사항을 충족해야 한다. 여전히 스톡 분리의 일반적인 방향에서 탐색할 가치가 있는 많은 기술적 어려움이 있습니다.
**네 번째 요점은 다른 상위 수준 애플리케이션 구성 요소에 대한 데이터 계층 탐색입니다. **ES와 ClickHouse의 두 가지 시나리오 외에도 최근 Apache Pulsar의 웜 및 콜드 데이터를 JuiceFS로 싱크하려는 시도도 있었습니다. 사용된 전략 및 솔루션 중 일부는 이 문서에서 언급한 것과 유사합니다. 다만 Apache Pulsar에서는 싱크해야 하는 데이터 유형이나 데이터 형식이 다릅니다. 더 성공적인 연습 후 공유됩니다.
관련 자료: