QTune: A Query-Aware Database Tuning System with Deep Reinforcement Learning 리뷰
몇번째 세미나지..
이제 곧 끝이다.. 방학.. ㅎㅎ..
힘드렁,,
QTune
DS-DDPG를 사용한 튜닝 모델이다. 기존의 RL을 사용하는 모델인 CDBTune과의 차이점으로 일단 CDBTune은 database의 state에 관련한 information을 사용하여 튜닝을 진행하지만 query의 information은 사용하지 않는다. QTune에서는 튜닝할 때 쿼리의 information이 사실은 database state information보다 더 중요하다고 얘기하면서 두 정보를 모두 튜닝에서 사용한다. 일단 내용 자체에 강화학습 특히 actor-critic이 있어서 CDBTune만큼 읽기 어려웠던 것 같다..
일단 시작!!
+) 본문에 있는 ppt 자료는 모두 글쓴이가 제작한 ppt 입니다!
제가 잘못이해하고 있는 부분이 있거나 질문이 있으신 경우에는 자유롭게 댓글 남겨주세요!!! :)
INTRODUCTION
논문에서는 먼저 기존에 존재하고 있는 튜닝 기법에 대해 한계점을 서술한다.
데이터베이스 튜닝은 원래 DBA (사람)이 해왔는데 사실 .. knob의 갯수가 너무 많고 DBMS 종류도 너무 다양하기 때문에 사람이 튜닝을 진행하기에는 시간이 너무 오래걸리고 효율적이지 못하다는 문제점이 있다.
그래서 automatic tuning model에 대한 연구가 시작됨!
여기서는 다행히도 내가 읽었던 세 개의 논문의 모델들과 비교를 진행한다.
1. BestConfig
휴리스틱한 방법을 사용하기 때문에 history에 비슷한 configuration이 없다면 좋은 knob value를 찾기 힘들다는 단점을 가지고 있다.
2. OtterTune
OtterTune은 data-repository에서 이전의 튜닝과정에서 사용된 (training된) workload에 대한 정보를 가져다가 지금 input으로 들어온 workload와 가장 비슷한 workload를 mapping하는 과정을 거치게 된다.
그렇기 때문에 처음 튜닝을 진행하려면 training 할 때의 sample이 필요한데 확실히 high-quality의 sample로 training을 해야 mapping이 잘되기 때문에 DBA들에게 좋은 sample을 받아야하는데 그게 너무 힘들다고 한다..
그리고 사실 모든 input workload가 꼭 data-repository에 저장되어있는 workload와 유사할 수는 없기 때문에 knob recommendation에 확실성이 떨어질 수 있다고 이야기 한다.
3. CDBTune
일단 SQL query workload를 knob recommendation을 할 때마다 새롭게 실행시켜야하기 때문에 시간이 많이 걸린다.
또한 coarse-grained tuning(i.e., tuning for readonly workload, read-write workload, write-only workload)만 가능하며
fine-grained tuning (i.e., tuning for a specific query workload)이 불가능하다.
그 이유는 위에서 언급한 대로 CDBTune에서는 쿼리information을 튜닝과정에서 사용하지 않기 때문!
그래서 QTune에서는 DRL model을 사용하여 query-aware database tuning system을 제안한다.
첫번째로는 SQL query들을 query info (query type, tables)와 cost info (query cost)를 통해 vector featurizing을 진행한다.
이후에 이 vector값을 DRL method의 input으로 넣어서 적절한 configuration parameter를 추천해주게 된다.
기존의 DRL method와의 다른 점은 Qtune에서는 Actor-Critic을 사용하는 Double-State Deep Deterministic Policy Gradient (DS-DDPG) 를 사용한다.
음 여기서 double state라고 이야기하는 이유는 나중에 model architecture와 함께 이야기해보겠다!
SYSTEM OVERVIEW
QTune에서는 세가지의 database tuning 세분성을 가지고 있다.
- Query-level tuning
- Workload-level tuning
- Cluster-level tuning
세가지이고 내 생각에는 저자들이 쿼리레벨과 워크로드레벨 튜닝을 진행하였을 때 생기는 단점을 보완하기 위해 클러스터 레벨의 튜닝기법을 제안하는거 같다. 일단은 모든 레벨의 튜닝 과정과 장단점에 대해 설명해보겠습니당
Query-level tuning
- Query-level tuning
: SQL query 각각 하나마다 configuration knob을 추천해주는 방식이다.
그렇기 때문에 latency는 낮겠지만 throughput도 낮을 수 밖에 없다. 참고로 이 논문에서 이야기하는 throughput이란 우리가 평소에 알고 있는 의미와는 조금 다르게 [tuning time + 결과값] 이라고 이야기한다.
이 ppt에서 Q2V (Query 2 Vector)는 뒤 내용에서 어떻게 이루어지는지 자세히 설명할 예정이다. 일단 전체적인 흐름은 다음과 같다.
1. 주어진 쿼리에 대해서 Q2V를 통해 featur vector를 생성한다.
2. Tuner는 이 vector값을 input으로 받아서 continuous한 knob value를 추천한다.
3. 추천받은 knob value에 대해서 system은 query를 실행한다.
일단 쿼리 하나하나를 병렬적으로 실행시키지 못한다는 점을 유의하면 된다.
Workload-level tuning
- Workload-level tuning
: 하나의 전체적인 query workload에 대해서 configuration knob을 recommendation하는 방식이다.
그렇기 때문에 throughput은 높지만 latency도 낮다는 단점을 가지고 있다.
그 이유로는 일단 동시적으로 튜닝된 knob을 쿼리에서 실행시키기 때문에 throughput은 높지만 다른 workload에 대해서는 다른 knob value값을 튜닝해야하기 때문에 latency도 높아지게 된다.
전체적은 흐름은 쿼리 레벨과 비슷하지만 Q2V에서 약간의 차이가 있다.
1. workload에 대한 각 쿼리에 대해서 feature vector를 생성하고 그 벡터들을 merge하는데 어떤식으로 merge를 하는지는 논문에 설명되어있지 않다.
2. Tuner는 이 벡터를 input으로 넣어서 continuous knob value를 추천한다.
3. 마찬가지로 System은 추천받은 knob value에 대해서 query를 실행한다.
Cluster-level tuning
- Cluster-level tuning
: 각 query에 대해서 유사한 knob을 사용하는 query끼리 clustering을 진행하고 그 그룹마다 configuration parameter를 recommendation해준다.
드디어 대망의 cluster-level tuning,,
마찬가지로 여기서 추가된 V2P (Vector 2 Pattern)와 P2C (Pattern 2 Cluster)도 뒤에서 어떻게 진행되는지 설명할 예정이다.
이 레벨에서는 앞의 두 레벨과는 다르게 높은 throughput과 낮은 latency를 얻을 수 있다.
위에서 언급했듯이 비슷한 knob을 사용하는 query끼리 group을 만들고 거기서 사용되는 knob을 tuning해주기 때문이다. 또한 각 group이 병렬처리가 가능하기 때문에 latency가 낮다.
전체적인 흐름은 다음과 같다.
1. 앞 선 두 레벨과 같이 먼저 쿼리들에 대해서 feature vector를 생성한다.이후 원래는 바로 Tuner로 넘어가서 각 vector에 대한 configuration pattern을 찾아서 mapping 해주어야한다.
(여기서 말하는 configuration pattern이란 , vector에 해당하는 쿼리가 자주 사용하는 configuration의 특징을 뜻하는 것 같다.)
하지만! configuration의 범위는 너무 continuous하기 때문에 각각의 쿼리에 대해서 mapping을 해주기가 너무 어렵다. 그렇기 때문에 추가된 부분이 V2P라고 할 수 있다.
2. V2P 부분에 그림과 같이 DS-DDPG와 DL-Model 두가지가 실행되는데 하나씩 설명해보면!
DS-DDPG 에는 input으로 vector값이 들어가고 output으로는 tuning된 knob value가 나오게 된다. 이후 Vector 2 Pattern을 통해서 continuous한 knob value를 discrete하게 바꿔준다. 그 값이 A의 집합이라고 보면 된다.
DL-Model 에도 마찬가지로 input에는 vector 값이 들어가고 output으로는 featurizing된 query에 대한 configuration pattern을 예측해준다. 이걸 P 집합으로 봐주면 된다.
3. P2C를 통해 discrete하게 바뀐 knob value (A)와 예측된 configuration pattern (P)에 대해 clustering을 진행해준다. 이건 U집합이겠다!
4. 이렇게 clustering된 U집합에 대해서 workload-level tuning에서 진행했던 것 처럼 하나의 클러스터에 포함된 knob값들에 대한 feature vector를 생성한 후 merge를 해준다.
5. 그럼 Tuner는 이 벡터를 input으로 넣어서 다음 knob value를 추천한다.
6. System은 뭘 할까요?!?!?! 추천받은 knob value에 대해서 query를 실행시킨다.
끝!
자 그럼 이 세세한 단계들이 어떻게 이루어지는지 설명을 시작해보겠습니당,,
QUERY FEATURIZAION
How to vectorize the queries
query를 vectorize하는데는 세가지 challenge가 존재한다.
첫번째는 query information (e.g., which tables are involved in the query) 을 capture해야한다는 점.
두번째는 query를 실행시키고 cost(e.g., the selection cost and join cost) 를 캡쳐해야한다는 점.
세번째는 서로 다른 쿼리에 대한 벡터의 각 기능이 동일한 의미를 갖도록 query information과 cost information을 균일하게 특성화해야한다는 점 이다.
Query Information
먼저 Query Information이 어떤건지 알아보도록하자.
다음과 같이 Query type, Tables, Attributes, Operations 네가지로 이루어져 있다.
해당 설명은 ppt에 잘 설명해놓아서 따로 적지는 않겠다!
그런데 여기서 우리는 Attributes과 Operation은 featurize를 하지 않는다고 얘기한다.
왜냐하면 일단 query cost가 operation information을 이미 capture를 할 것이기 때문에 굳이 두 번 featurize를 할 필요는 없다고 얘기한다.
다음으로 operation은 너무 specific해서 오히려 generalization ability를 감소시킬 수 있다고 얘기한다.
또한 attributes과 operation은 너무 자주 update되기 때문에 매번 값을 바꿔주기에는 너무 효율적이지 않기 때문이다.
Query Information vectorize 하는 법
Query Information을 vectorize하는 방법이당.
일단 4+|T| dimensional을 유지한다고 한다. 여기서 앞의 4는 query type이 4개여서 더해주는 거고,, 뒤 테이블 갯수는 각 쿼리에서의 전체 테이블 갯수를 더해주면 된다. 그래서 위 예시에서는 4 + 8 =12 ! 12 dimenstional을 유지한다.
vector로 나타내는 법은 간단하다. 쿼리에서 사용되는 query type에는 1로 표시하고 그렇지 않은 부분은 0으로, 마찬가지로 그 쿼리에서 사용되는 table에는 1로 표시해주고 그렇지 않은 부분은 0으로 표시해주면 된다.
Cost Information vectorize 하는 법
다음은 query cost를 vectorize하는 법이다.
사실 이 부분은 완벽하게 이해되진 않았지만 일단 같은 operation의 값끼리 더해주고 child의 값을 빼준다. (왜인지 모르겠음.,,) 그렇게 나온 총 합은 mean값을 빼주거나 std deviation으로 나눠주는 등 의 방식으로 normalization을 거쳐 vectorize를 진행한다.
Normalized Feature Vector
자 이렇게 query information과 query cost information을 모두 vectorize 했기 때문에 concat을 해주면! Query Featurization완료!
이제 QTune의 꽃이라 할 수 있는 DS-DDPG에 대해 알아부자,,
DRL FOR KNOB TUNING
DS-DDPG
전체적인 figure는 다음과 같다. 순서대로 설명해보자면!
1. 먼저 Q2V는 앞에서 공부한 대로 주어진 query에 대해서 vector값으로 featurizing해준다.
2. 그 값에 대해서 Predictor는 쿼리를 실행시킨 후의 outer metrics의 변화량을 예측한다. 여기서 predictor는 deep neural network이다.
또 outer metric이란 성능 지표를 말하고 Inner state는 knob 값, 즉 우리가 tuning해야하는 값을 뜻한다.
3. Environment에서는 어떤 knob값에 대해 쿼리를 실행시키기 전의 outer metric 값인 S와 쿼리를 실행시킨 후의 outer metric값인 S' , 그리고 쿼리를 실행시킨 후의 outer metrics의 변화량에 대해서 observation을 진행한다.
헷갈려서 다시 한 번 정리하자면,
S : 주어진 knob 값에 대해서 쿼리를 진행시키기 전의 outer metric 값 (즉, recommendation knob값 이전의 outer metric)
S' : 주어진 knob 값에 대해서 쿼리를 진행시킨 후의 outer metirc 값 (즉, recommend 받은 knob값의 outer metric)
∆S : 위 둘 사이의 outer metric의 변화량
DS-DDPG
4. S'에 대한 observation은 Agent에게 넘어간다. Actor는 S'을 input으로 받아서 action을 output으로 낸다.
여기서 output이란 tuning된 knob configuration을 의미한다.
5. Critic은 Actor가 보내온 Action에 대해서 각각의 Score을 매겨서 전달해준다. 이런식으로 Actor의 weight가 update된다.
=> Actor-Critic에 대해서 아주아주아주 간단하게 이야기를 한다면 Actor가 Critic에게 '이러한 Action을 하려고 합니다' 라고 전송하였을 때 Critic은 그 Action에 대한 Score을 매겨서 Actor에게 전달해준다. 그럼 Actor는 Score의 값이 제일 큰 Action을 골라서 실행하게 된다.
6. 이후에 골라진 Action (즉, tuning된 knob configuration)에 대해서 워크로드에서는 쿼리를 실행시키고 성능에 대한 reward값을 Critic에게 전달하면서 Critic의 weight가 업데이트 된다.
이 DS-DDPG에 대한 자세한 Training 알고리즘이랑 reward function에 대한 내용은 완벽하게 이해를 하기 힘들었고, 당장 이해하지 않아도 된다고 판단되어서 후에 다시 정리하려고 한다.
QUERY CLUSTERING
마지막 단계인 쿼리 클러스터링이다.
앞 전에서 cluster-level tuning 설명할 때의 그림을 가져와서 다시 한 번 보자!
자 지금부터 하는 내용은 Vector 2 Pattern 부분이다.
앞에서 얘기했던 것 처럼 DS-DDPG와 DL-Model 두가지가 사용되는데 DS-DDPG로 tuning된 knob값에 대해서 각 knob을 configuration pattern과 mapping시키기에는 힘들기 때문에 knob값을 discrete하게 만드는 과정이 필요하다고 했다.
Configuration Pattern - Continuous to Discrete
방법은 아주 간단함!
DS-DDPG를 통해 tuning된 knob값이 knob의 default 값과 비슷하다면 0으로
default값보다 크다면 1로
default값보다 작다면 -1로 해준다.
이게 아주 정확하게 discrete한 값으로 변환해줄 필요는 없기 때문에 대강적으로 비슷하면 ~ 많이 크면 ~ 많이 작으면 ~ 이런식으로 한다고 한다.
Configuration Pattern DL-model
이번에는 DL model에 대한 설명이다.
이 model은 일단 training을 시킬 때는 쿼리와 그 쿼리에 대한 real pattern을 sample로 하여 training 시킨다.
후에 예측을 할 때에는 쿼리에 대한 feature vector값을 input으로 넣으면 그 query vector 값에 대한 configuration pattern 값을 output으로 내도록 한다. 그러면 예측한 pattern과 실제 pattern 간의 loss값을 최소로 하는 것이 목적이겠다!
Query Clustering
이제 진짜 마지막,,, 쿼리 클러스터링을 해주는데 아무 클러스터링 알고리즘을 다 적용할 수 있다고 한다.
이 논문에서는 DBSCAN이라는 알고리즘을 사용하였고 이 알고리즘은 거리 측정과 함께 클러스터링할 수 있는 최소 갯수에 따라서 가까운 pattern을 grouping한다고 한다.
자 ,,, 여기까지가 전체적인 내용이고 실험은 언제나 그랬듯이,, 나중에 추가하도록 하겠다.
근데 개인적으로 막 의미있는 실험은 없었던거같음,,
암튼 여기까지 끝!