11. Hardware-accelerated Query Processing (Bigdata and Knowledge Management Systems 2, SNU GSDS)

서울대학교 데이터사이언스대학원 정형수 교수님의 "빅데이터 및 지식 관리 시스템 2" 강의를 필기한 내용입니다.

• 목차

완성되지 않은 강의록

• 사진이랑 보충 설명 넣고, AIDE 는 별도의 논문 리뷰 작물로 분리할 계획입니다.

AIDE (VLDB’23) §

• NDP 는 아주 큰 개념
  • Storage 로 가면 ISP (In-Storage Processing) 이 되고
  • Memory 로 가면 PIM (Process In Memory) 가 된다.
• 이 ISP 로 query offloading 을 해보자.

The good §

• 일단 update 는 in-memory 에서 처리되게 냅두고, OLAP query 에서 JOIN 을 CSD 로 offloading 하면 더 좋지 않을까?
  • 아니면 parallel 하게; JOIN 의 일부는 host 에서 하고 다른 JOIN 은 CSD 에서 처리하면 host DBMS 의 부담을 더 줄일 수 있지 않을까?

The bad §

• 라고 생각하면 오산이다.
• 근데 여기서 당면한 첫번쨰 문제는 data format 이다: CSD 에 offloading 할 computation 이 특정 DB 에 종속되어있다면 해당 DB 에서밖에 사용하지 못한다.
  • 다른 DB 에서 사용하려면 이 logic 을 다른 DB layout 으로 바꿔야 하는데 이건 맨땅에 해딩하는거나 다름이 없다.

• 가령 위의 그림을 보면 지금까지 나온 모든 CSD 관련 논문들이 전부 vendor-neutral 하지 않다는 것을 알 수 있다.
• 두번째 문제는 CSD 의 computation power 가 별로이고, CSD 내부에서도 random IO 는 여전히 느리기 때문에 CSD 내에서 version traversal 을 하는 것은 매우 별로라는 것이다.

The ugly §

• 그래서 첫번째 문제는 canonical layout 와 vendor-neutral operation 을 정의하여 구현하고, 다른 DB 에서도 사용할 수 있게 하여서 해결한다.
• 그리고 두번째 문제는 Prescreen 이다: host library 에서 봐야 할 version 을 미리 결정해서 CSD 에 던져 주고, CSD 에서는 얘네들만 읽게 하면 CSD 내부에서의 version traversal 을 제거할 수 있다.

Prescreening §

• 우선 Prescreening 이 뭔지부터 알아보자.
• 간단히 말하면, visibility 정보만을 담은 것을 빌드한 후, CSD 에 던지기 전에는 query 의 timestamp 를 이용해 여기에서 읽어야 하는 version 들만을 채로 걸러서 (Sift) CSD 에 던진다.

• 구체적으로는,
  • 각 version 에 대해서 visibility information (timestamp) 와 이 version 이 있는 위치 (location) 을 묶은 자료구조인 Version Index 를 만들고,
    • 당연히 visibility information 은 Min, Max timestamp 로 구성되고
    • Location 은 파일 내에서 version 에 대한 offset 과 size 로 구성된다.
  • 모든 version 들에 대해 빌드해 Version Index Table 을 빌드한다.
    • Postgres 에서는 segment 별로 build 되어 segment 랑 같이 저장되고,
    • MyRocks 에서는 SST 별로 build 되어 SST 랑 같이 저장된다고 한다.
  • 그리고, Query plan 의 query timestamp 를 이용해서, 이 Version Index Table 내에서 어떤 version 들을 읽어야 하는지 한번 채로 거른다. 이 과정을 Prescreen 이라고 한다.
    • 즉, 이것 자체가 snapshot 이 되는 셈이다.
  • 그리고 CSD 내에서는 이 채로 거른 Version Index 들을 이용해 version traversal 없이 데이터에 접근한다.

• 실제로는 위와 같이 최적화하여 실행한다.
  • 저 Prescreen 된 version index 들을 sorting 하여 읽어야 하는 구역을 disjoint 하게 구분한 뒤,
  • CSD 내의 각 core 가 parallel 하게 scan 한다.
• 또한, latency hiding 을 위해서 data file 을 CSD 내에서 사용할 수 있게 하기 위해 flush 하는 동안 prescreening 을 진행한다고 한다.

Canonical Interface §

• 이것은 별거 없다.
• 위에서는 version index 에 location 이 들어간다고 했는데, 구체적으로는 offset, version len, header len, nullmap 으로 구성된 Canonical Tuple ID (CTID) 가 들어간다.
• 따라서 이놈을 보면 일단 version 의 전체 length 와 nulll 정보를 알 수 있다.
• 그리고, ISP command 로 각 column 들의 길이를 알려준다.
• 이것을 조합하면, 그냥 byte stream 일 뿐인 tuple 을 해석할 수 있게 된다.

Evaluation §

• Selectivity 가 좋으면 효과가 나지만 full scan 의 경우에는 flush overhead 때문에 별로였다고 한다.
• 그리고 LLT 가 있어서 version chain 이 아주 긴 경우에도 효과가 좋았다고 한다.
• 근데 삼성 CSD 는 발열이 심해서 별로였다고 한다.