(논문) The FastLanes Compression Layout - Decoding 100 Billion Integers per Second with Scalar Code, VLDB 2023 (5. Conclusion and Future Work)

본 글은 논문 The FastLanes Compression Layout: Decoding > 100 Billion Integers per Second with Scalar Code (VLDB '23) 를 읽고 정리한 글입니다.

별도의 명시가 없는 한, 본 글의 모든 그림은 위 논문에서 가져왔습니다.

목차

• 1. Introduction
• 2. FastLanes
• 3. Evaluation
• 4. Related Work
• 5. Conclusion and Future Work (현재 글)

5. Conclusion and Future Work §

5.1. Conclusion §

• 현재의 상황을 대략적으로 요약해 보면 다음과 같다고 할 수 있다:
  • 우선, 현재의 많은 DBMS 들은 data parallelism 을 충분히 활용하고 있지 않다.
    • 즉, SIMD 가 줄 수 있는 많은 것들을 충분히 활용하지 못하고 있으며
    • SIMD 말고도 GPU 혹은 TPU 와 같은 parallel HW 들이 많이 나오고 있는데
    • CPU 의 frequency 및 core 의 개수가 정체되어 있는 이 시점에, 이런 parallelism 을 최대한 활용하는 것은 DBMS 에게 있어 또 다른 성능 향상의 기회가 있을 것이다.
  • 이 data parallelism 을 활용하기 위해서는, sequential data dependency 문제를 해결해야만 한다.
• 따라서 data parallelism 을 늘리면서도 sequential data dependency 를 해결하기 위해서는 새로운 data layout 이 필요했고, 그 결과가 본 논문이 제시하고 있는 FastLanes 와 Unified Transposed Layout 이다.
• FastLanes 에서는 BP, DELTA, RLE 와 같은 lightweight compression scheme (LWC) 들을 가속하고 있고, FLMM1024 라는 가상의 register 와 instruction set 을 정의하여 가속화 로직을 설계하였으며, 이 가상 architecture 는 어떠한 실존 architecture 로도 구현될 수 있게 하였다.
  • 저 가상 resource 관련해서는, 이것을
  • Naive scalar code 로 구현한 방법 (Scalar) 및
  • Scalar code 를 이용해 vectorize 하는 방법 (Scalar_T64),
  • Scalar code 를 compiler 에 의해 vectorized code 로 바꾸는 방법 (Auto-vectorized),
  • 그리고 명시적인 SIMD intrinsic 을 사용하는 방법 (SIMD)
  • 네가지를 제시해 portability 를 늘렸다.
• FastLanes 는 data decoding 에 대해 이놈 하나에만 집중한 것이 아니라 DBMS 의 system 전체의 관점 (즉, 더 넓은 시점) 에서 바라보았다고 한다.
• 즉, data decoding 은:
  • DB 에서 HW resource limit 을 고려해야 하는 pipeline 의 일부이고
  • Column 은 value 각각 처리하기 보다는 vector 단위로 pipeline 해야 하는 대상이며
  • Scan 에는 하나의 column 만을 decode 하지는 않고
  • Decoding 은 vectorized software subsystem 에 포함되는 중요한 component 이고
  • 다양한 architecture 가 존재함에 따라 architecture-free 하게 디자인 하여 기술적인 부담을 줄여야 해야 한다는 것이다.
• 그 결과로 FastLanes 를 사용하면 훨씬 빠른 decompression 이 가능하다:
  • FastLanes 에서의 Interleaved Bit-packing Layout 은 기존의 sequential layout 에 비해 몇배나 더 빨랐고
  • FastLanes 에서는 decompression 결과가 가장 작은 L1 cache 에도 들어올 수 있었기 때문에 중간중간 memory 로부터 데이터를 가져오고 방출하는 기존의 query execution 과 훨씬 더 빠르게 할 수 있었다고 한다.

5.2. Future Work §

• 위에서도 말한 것처럼, FastLanes 에서는 BP 된 데이터를 원본의 데이터 크기로 복원하는 것 (fully, eager decompression) 이 아니라 lane 크기에 맞을 정도로만 데이터를 복원하는 방식 (compressed vector) 을 사용하여 데이터의 크기를 줄여 cache 에서 바로 데이터를 가져다가 query execution 을 할 수 있게 했다.
• 여기서 한가지 연구해볼만한 것은, CPU 가 아닌 GPU 나 TPU 에서도 이런 것이 가능할지 이다.
• FastLanes 에서는 decompression speed 뿐만 아니라 compression ratio 도 향상시켰는데, 이들을 (BtrBlocks 마냥) cascading 해서 결과적으로 Snappy 나 Zstd, LZ 와 같은 general-purpose compression scheme 으로 만드는 것 또한 추가적으로 해볼 연구라고 한다.
• 마지막으로, FastLanes 를 Parquet 와 같은 open-source data format 과 통합하여 end-to-end evaluation 을 하는 것도 future work 로 남겨놨다고 한다.
  • 시도해 보긴 했으나, cascading 을 한다는 것은 chunk 를 recursive-compression 될 수 있게 배치하고 이에 대한 metadata 를 관리해야 하기에 추후의 연구로 남긴듯