그림 1- 1 은 행 및 열 스토리지의 도식입니다. 테이블에는 rowid, 날짜/시간, 고객명, 수량 등 5 개의 필드 (열) 가 있으며, 그림에서 빨간색 화살표는 저장 순서를 나타냅니다.
저장 형태에 따라 다른 응용 프로그램 시나리오가 결정됩니다.
일반적으로 열 저장은 대용량 데이터 (높은 압축비) 및 분석 작업 (소수의 열) 에 더 적합합니다. 잦은 삭제 (전체 열 검색) 및 업데이트 (재압축) 작업에는 적합하지 않습니다.
그림 2- 1 은 열 저장소에서 사전 테이블을 기반으로 테이블을 인코딩하고 압축하는 예를 보여 줍니다. 소스 테이블은 왼쪽에 있습니다. 오른쪽 위 테이블에 표시된 것처럼 이 테이블의 고객 및 품목 필드 값이 5 개뿐인 경우 출처 테이블의 행 수가 크면 고객 및 품목 필드에 많은 중복 값이 있습니다. 저장 공간을 절약하기 위해 두 필드를 인코딩합니다. 즉, 하나의 사전 테이블 (오른쪽 위) 을 사용하여 두 필드의 서로 다른 값을 기록하고 다음 표는 원래 문자열을 오른쪽 위 테이블 값에 해당하는 인덱스 (정수 1, 2,3,4,5) 로 바꿉니다. String 은 이러한 인덱스보다 훨씬 많은 저장 공간을 차지하므로 차지하는 저장 공간을 크게 압축할 수 있습니다.
열 저장소를 기반으로 하는 두 가지 일반적인 구현은 hbase 와 parquet 입니다. 여기서,
퍼즐 바닥의 파일 구조는 그림 3- 1 과 같습니다.
그림에서 볼 수 있듯이 1 패치 파일은 헤더 (1), 블록 (다중) 및 바닥글 (1) 으로 구성되며 각각 다음을 담당합니다.
그림 3-2 는 parquet 파일에 있는 블록, 행 그룹, 열 블록 및 페이지 간의 관계를 보여줍니다.
간단히 말해서:
따라서 철자 파일을 큰 excel 테이블과 비교하면 다음과 같습니다.