Kudu는 Columnar Storage로 칼럼마다 압축 방식과 인코딩 방식을 지원합니다. 또한 Primary Key가 필수고 B+트리로 저장되어있어서 인덱스 처럼 저장되어있어서 delete, update 등 Random Access가 빠른 특징을 갖고 있습니다. 또한 Parquet처럼 Sequental read에도 최적화 되어있습니다. Parquet, Kudu, Hbase 간 primary key를 기준으로 Random Access 그리고 substring() 연산통해서 성능 비교 시 Kudu가 Parquet와 Hbase의 중간 정도 성능을 보이 연구 또한 있습니다.(참고자료에 있음)
또한 Table들은 Tablet(partition)으로 구성되어있는데, resiliance를 위해 여러 노드에 분산저장되어 있습니다. 이러한 Tablet들 간에 Raft Consensus Algorithm을 통해 높은 HA를 구성하고 있습니다. Kudu는 Data Storage이기 때문에 Impala, Spark와 같은 질의 처리 엔진과 연동해야합니다.
Transaction Semantics
Scans(read)
Client는 Master Leader에게 request를 보내고 마스터 서버는 Metatdata통해서 응답을 주게 됩니다. Kudu는 read operation 시 Consistent Read를 위해 MVCC를 사용합니다. read시 해당 두 가지의 mode가 있는데 READ_LATEST(default) 는 가장 최신본의 commit 시점의 데이터를 읽지만 replica마다 최신버전이 반영안되어 있을 수 있습니다. READ_AT_SNAPSHOT은 특정 시점의 timestamp를 지정하면 해당 시점의 snapshot 의 버전을 확인할 수 있습니다. 후자의 경우, 회계작업 등 배치작업 등 시 사용될 수 있습니다.
Write
Insert 작업은 Oracle과 같이 처음에 Request오면 WAL에 작성 후, MemRowset이라는 memory 영역에 데이터를 씁니다. 이 후, 특정 시점에 Disk에 flush하여 DiskRowSet의 Base Data라는 곳에 데이터를 저장해둡니다. DiskRowSet 마다 DeltaMemStore 메모리 영역이 할당되어있는데, Update 시에는 Insert와 비슷하게 DeltaMemStore에 저장해두었다가 특정 시점에 Delta File에 flush 하게 됩니다. Update 시 어떤 DeltaMemStore에 저장해야할까는 Bloom Filter를 사용해서 정합니다.
Compaction
Client 입장에서 Read 및 Transaction 작업 시 MRS, DRS 등 참고해야할게 많아서 성능을 높이기 위해 Kudu는 내부 설정에 따라 데이터 Compaction 작업을 하게 됩니다. Compaction을 하게 되면 Rowset에 대한 depth가 줄어듦에 따라 primary key 값이 한 곳에 모여두어서 탐색 시 읽어야할 rowset이 줄게 됩니다.
1) Merge Compaction(rowser compaction) : 여러개의 DiskRowset을 합치는 역할을 하게 됩니다. 그러면 Bloom Filter 에 의해서 성능 효과가 납니다.
2) Delta Stroe compaction : Minor Delta Compaction, Major Delta Compaction
* Reference
'빅데이터 > Storage Engine' 카테고리의 다른 글
| Hbase (0) | 2023.04.06 |
|---|
