最近（以及預感接下來的一年）會讀很多很多的paper......不如開個帖子記錄一下讀paper心得
New Hardware / non volatile memory
....
Streaming
....
Cloud / Distributed
PolarFS: An Ultra-low Latency and Failure ResilientDistributed File System for Shared Storage Cloud Database
https://zhuanlan.zhihu.com/p/87030280
AI+DB
A. Pavlo et al., Self-Driving Database Engineering, in Unpublished Manuscript, 2019
寫到這里啦：Self-Driving Database
CDBTune: An End-to-End Automatic Cloud Database Tuning System Using Deep Reinforcement Learning
2333
OtterTune: Automatic Database Management System Tuning Through Large-scale Machine Learning
筆記在這里：Link
后來我們借鑒OtterTune的思想，開發了AutoTiKV
Links:
https://www.cnblogs.com/pdev/p/10948322.html
https://www.cnblogs.com/pdev/p/11318880.html
Query-based Workload Forecasting forSelf-Driving Database Management Systems
在Self-driving Database這篇綜述中，曾經提到過self-driving的DBMS需要能預測未來的workload情況。這篇文章就是來解決這個問題的，更具體一點說是predict the expected arrival rate of queries（也就是QPS） in the future based on historical data，並且特指是SQL Query。
其實有很多類似的工作也在試圖做這個玩意兒，比如這篇是用LSTM預測應用程序的resource utilization（比如cpu usage, memory usage, balabala），但這些metric有個缺點就是比如硬件配置改變時（以及像本文的scenario下，當DBMS的底層設計改變了時），之前測的就不准啦。所以不如從上層的東西入手，預測業務的workload情況。比如能預測到雙11，或者每天晚上是個訪問高峰，那么就可以配合automatic knob tuning的一些工具來自動調優啦。其中本文重點關注了三種有代表性的workload pattern（見Fig1），個人感覺選的倒都挺經典的：
本文要解決這么幾個難點：
- 如何設計一個好的ML model
- 如何降低原始數據的complexity（因為SQL語句的花樣很多，對每種query分別預測是不可能的）
- 要做的這個framework必須能全自動化
根據上面的思路，本文開發了QueryBot5000（QB5000），它的pipeline如下圖所示：
這三個部分的具體細節如下：
- Pre-processor：首先DBMS會把所有接收到的Query轉發給QB5000。雖然SQL語句花樣很多，但從語義來看種類還是很有限的嘛（Such similar queries execute withthe same frequency and often have the same resource utilizationin the system.）。因此就可以用pre-processor總結出語義基本一致，只是參數不同的Query，把相似的query歸類總結成一個generic query template。
- Cluster：上面總結了之后，發現啊template（語義不同的Query的種類數量）還是有很多，需要進一步減少template的數量。具體細節先不看了.......大致意思就是把arrival rate相近的Query template合並起來（比如說兩種template都在同一張表上操作，那么它們的arrival rate就可能很接近，可以合並，也具有可以用ml來學習的潛力）。最后選出占了總數的95%的Query。
- Forecast：好的經過之前兩頓猛如虎的操作，現在the framework has converted raw SQL queries into templates and grouped them into clusters，並且有了它們的QPS的歷史數據（the number of queries executed per minute for each cluster）。現在是時候用ML model來predict（estimate the number of queries that the application will execute in the future）啦。這也是我們要關注的重點。因為NoSQL語義比較少，不需要前兩步啊哈哈哈哈。
Forecast這一節我們專門拉出來看。本文考察了以下幾個model：
- Linear Regression (LR)：比較簡單嘛......它的優勢是簡單，可以避免過擬合，需要的訓練數據也比較少。
- Kernel Regression (KR)：相對於Linear Regression，Kernel方法可以實現對一些非線性函數的回歸。看似很猛如虎，但它也比較復雜，需要的訓練數據多，容易過擬合。在作者的實驗中，LR對短時間（比如1小時）內的prediction比較好，而KR對長時間（比如一天）的prediction比較好。Kernel方法也分很多種......本文中使用的是Nadaraya–Watson kernel regression，這也是一個無參數的方法。？？？？
- RNN：其實這里就用的LSTM。LSTM可以“記憶”數據在過去時間段的一些特征，並應用到預測未來上。它的缺點也是模型復雜，需要的sample多。（所以ML中並不是模型越復雜就越好......是需要根據實際情況做很多的tradeoff的）
- ENSEMBLE：另外有一種方法叫做ensemble learning，可以結合兩種不同模型的優點。在本文中作者就把LR和RNN給ensemble到了一起，拼成了一個新model（equally averaging the prediction results of the LR and RNN models），這里我們記為ENSEMBLE
作者在實驗中發現：
- 1). ENSEMBLE方法的average prediction accuracy比較好，但它無法預測出帶有周期性尖峰的workload。比如對於大學申請的網站，每年的申請deadline之前都是一個高峰，但平時沒什么人訪問（見Fig1b）。
- 2). KR的average prediction accuracy並不如ENSEMBLE，但是只有它能預測出帶有尖峰的workload。
綜合上述結果，作者提出了一個HYBRID模型，自動根據不同情況決定采用上面哪種model。針對尖峰這個feature我們可以這樣設計：如果KR預測出的結果（its predicted workload volume）比ENSEMBLE的結果大K%（K是一個threshold，這里定為150%），就使用KR的結果，否則使用ENSEMBLE的結果。
接下來還有些細節需要考慮。比如Prediction Horizons（要預測多長時間內的workload，相當於Regression圖上x坐標的范圍）和Prediction Intervals（模型的直接輸出結果是預測多長時間內的Query數量，相當於x坐標上每個點的單位）。這里作者把interval設為一分鍾。也就是對於horizon時間段內的每一分鍾，預測這一分鍾內的arrival rate of queries。（還有些細節可參考6.2節）
最后是實驗環節啦。對於cluster，結論是選擇top5的類就可以了，后面訓練的時候把這top5的cluster混合到一起作為training data，只訓練一個model。我們重點關注Forecast的效果。在下面的實驗中，使用過去3周的數據Train，然后實驗了不同的Prediction Horizon。
對於模型的選擇，理論上說應該是不能選擇對超參數過於敏感的模型，這是因為fne-tuning a model’s hyperparameters is by itself a hard optimization task。而在實驗中也證實了這一點（Fig7，但這里好像沒有說實驗的Prediction interval.....好在后面還會專門討論這個）：
- 在Horizon比較短的時候（一天以內），LR比RNN的表現還要好。因為短時間內的the relationship between the arrival rate observed in the recent past and the arrival rate in the near future is more linear than for longer horizons。 而復雜的模型反倒有可能過擬合。
- 在Horizon比較長的時候（一天及以上），the relationship between the past and the future also grows in complexity。RNN的表現會比較好
- 綜合了上述兩個model的ENSEMBLE的overall性能最好。
- 只有HYBRID可以預測到帶有尖峰的workload pattern
另外作者還選擇了如下幾個模型做對比：
- Autoregressive Moving Average (ARMA)：這是一種時間序列模型（其實時間序列也是一個可以考慮的方向）。但是它的效果並不是很穩定，在38%的case下都不好。這是因為the model is sensitive to its hyperparameters. The optimal hyperparameter settings for ARMA are highly dependent on the statistical properties of the data, such as stationarity and the autocorrelation structure.
- Feed-forward Neural Network (FNN)：就是普通的多層神經網絡...被RNN完爆
- Predictive State Recurrent Neural Network (PSRNN)：LSTM的一個變種。然而在這里還是被LSTM完爆...
- Kernel Regression (KR)：單純KR的效果其實一般般...因為it is prone to error when it has not seen inputs in training that are close to the input to make the prediction with。但是后面預測尖峰的時候還真是會用到它
對於有尖峰的workload pattern，這里使用1 hour的interval，用full workload history來訓練，然后試圖預測出一周后的workload是否會出現尖峰。在這種情況下，只有KR順利預測出了尖峰（Fig9）。這是因為its prediction is based on the distance between the test points and training data, where the influence of each training data point decreases exponentially with its distance from the test point。
對於Prediction Horizon的選擇，在BusTracker的數據上測試發現還是Prediction Horizon比較短的時候效果好...比如1 hour的時候就比1 week好（Fig8）
對於Prediction Interval的選擇，interval越短的效果會越好（shorter intervals provide more training samples and better information for learning），但interval太小了也會導致noise多，模型更復雜，訓練也更久，因此這也是個tradeoff。最終實驗發現總的來說1 hour的interval比較好。（一個future work就是自動設置interval）
Link：
https://zhuanlan.zhihu.com/p/37182849
https://github.com/pentium3/QueryBot5000
Characterizing, Modeling, and Benchmarking RocksDB Key-ValueWorkloads at Facebook
這篇paper介紹了如何分析實際場景中的workload，以三種典型的workload（UDB，ZippyDB，UP2X）為例。
之前我們用ycsb等工具做過benchmark，但它只能支持有限的幾種key-value分布[ YCSB-generated workloads ignore key space localities. In YCSB, hot KV-pairs are either randomly allocated across the whole key-space or clustered together. This results in an I/O mismatch between accessed data blocks in storage and the data blocks associated with KV queries. ]，很難准確的模擬實際情況。而本文的工作是將線上的實際數據進行trace，然后replay並且analyze。在分析的過程中，我們重點關注熱點數據落在哪些kv區間[ The whole key space is partitioned into small key-ranges, and we model the hotness of these small key-ranges. ]，試圖發現其中和業務場景相關的一些pattern，然后在設計benchmark時，queries are assigned to key-ranges based on the distribution of key-range hotness, and hot keys are allocated closely in each key-range.
Trace和Replay都是比較工程化的東西...也不太是本文的重點。第三章介紹了這一過程中需要記錄的一些metrics。
接下來都是analyze出來的一些東西：
- ch4.1 不同種類Query（get/put/...）的占比
- ch4.2 KV pairs的熱點分布情況
- ch4.3 QPS的變化情況，可以從中看出不同時段的訪問量
- ch5 key/value的大小情況
- ch6
在analyze之后，作者探索了是否能用benchmark工具來模擬出盡可能和現實情況像的workload。
Blockchain
....
Spatial DB
...
Transaction
...
Query Optimizer
...
GraphDB
...
Security / Privacy
...
....