ブログ@nnaka2992

データベースってなんだよ

RDBでの結合手法を比較した論文を読みました

この記事の趣旨

2016年に発表された"An Experimental Comparison of Thirteen Relational Equi-Joins in Main Memory"という 論文を読みました。 様々な結合手法を包括的に比較した論文でどのような結合方法がどのような時に適しているかを示しています。

An Experimental Comparison of Thirteen Relational Equi-Joins in Main Memory

著者について

Stefan Schuh、Xiao Chen、Jens Dittrichのグループによる論文。 いずれもDBMSや分析システム、Hadoopなどにおける検索高速化・最適化の研究を行なっている。

問題意識

関係結合はほとんど全てのクエリプランにおいて中核をなす処理であり、定期的に研究・改良され再検討 されてきた。 新たな手法が提案され実験を行なわれるものの、それぞれ結果において比較を困難にする要素や 幾らかの矛盾を孕んでいた。

例えば同じハッシュベースの結合アルゴリズムの比較でも実装が異なったり、複数の論文でパフォーマンス比較で 正反対の結果を示しているためである。

そのため単純に論文執筆時点で最も高速な結合アルゴリズムを結論づけることが困難であった。

手法

本論文では結合方法を以下の3つに分類した 1. パーティションベースハッシュジョイン
結合対象となるリレーションをペアとなるキャッシュに収まる小さなパーティションに分割し結合する手法。 ハッシュテーブルの構築と結合されるデータの探索のキャッシュミスを最小にする事を目的としている。

  1. パーティションベースハッシュジョイン
    1つのグローバルパーティションテーブルを構築しながら結合を行なう手法で、マルチスレッドと順番に依存しない 実行によりキャッシュミスのパフォーマンス劣化を隠蔽している。

  2. ソートマージジョイン
    結合対象となるリレーションを結合キーでソートし、結合を行なう手法。 ソートはSIMDによりベクトル化される。

検証ではこれらの結合方法を以下の3つのテストで使用するために、全部で13のアルゴリズムを検証している。 1. ブラックボックス比較
基本となる3種4実装の結合方法をブラックボックス的に比較する。

  1. ホワイトボックス比較
    ブラックボックス比較で検証する結合方法に先行研究で示された最適化を施した上で比較を行なう。

  2. パラレルラディックスジョイン比較
    NUMAを考慮した結合におけるそれぞれのパフォーマンスを比較する。

Table 2: reference table for the algorithms evaluated in this paper
Table 2

結果

  1. パーティション結合の一種であるリモート書込みを排除したCPR系アルゴリズムは小さな入力に対して有効ではない
  2. スケールの大きい結合ではとくに理由が無い場合、パーティションベースのジョインを利用する
  3. 大きなサイズのページを利用する
  4. ソフトウェアライトコンバインバッファ()を利用する
  5. パーティションジョインでは適切なパーティションビットを利用する
  6. できるかぎりシンプルなアルゴリズムを利用する
  7. NUMAを考慮したアルゴリズムを利用する
  8. 実行時間とクエリ時間は同一ではない

作業時間

  • read
    • 31:34
    • 31:34
  • author
    • 35:18
    • 3:46
  • summary
    • 77:50
    • 42:32

コンパイルとベクトル化による最適化のパフォーマンスを比較した論文を読みました

この記事の趣旨

2018年に発表された"Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask"という論文を読みました。 最新のクエリエンジンの特性をまとめ、どのようなワークロードに向くのかという指針を示すないようです。

Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask

Timo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, Peter Boncz

著者について

Timo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, Peter Bonczのグループによる 論文。

いずれも大規模データにおけるクエリパフォーマスや最適化に関する研究を行なっている。

問題意識

分析ワークロードに向いた最新のクエリエンジンはベクトル化またはデータ中心のコード生成に基づいている。 どちらのモデルも従来のエンジンに比べオーバーヘッドが少く、非常に効率的なものの概念的には 大きく異なっている。

この2つのモデルの違いは、DBMSの実行エンジンのソースコードの構成とその性能 特性を決定する基本的なもので、クエリ実行モデルを超える多くの設計で異なる。

本論文はことなる2つのモデルを再実装し、環境差異のないマシンで実行することで それぞれのモデルがどのように違うのか。どのような用途に最適なのかを検証している。

手法

検証手法は著者らがC++で再実装したデータ中心モデルの「Taper」とベクトル化中心の「Tectorwise」を 同一のマシンでパフォーマンス検証を行っている。

検証項目は以下から成る 1. インメモリOLAPワークロードでのマイクロアーキテクチャ分析 1. SIMDの利点の検証 1. マルチコアCPUにおけるクエリ並列化 1. 異なるハードウェアでのパフォーマンス

結果

  1. インメモリOLAPワークロードでのマイクロアーキテクチャ分析
    全体的にはほぼ同レベルのパフォーマンスを発揮する一方で、対象となるクエリによって異なる特徴を示した。 アグリゲーション処理ではTectorwiseが優位になるが、ハッシュ処理がメインになる処理ではTaperが優位性を示す。 これはTectorwiseのベクトル化処理ではキャッシュミスを隠しパフォーマンスを向上させる一方で、 ハッシュ処理は単純なループなためである。 Taperはハッシュ処理において複雑なループを行なう一方、ブランチミスによるキャッシュ失敗に大きなペナルティがあるため である。

    Figure 3: Performance – TPC-H SF=1, 1 thread
    Figure 3: Performance – TPC-H SF=1, 1 thread

  2. SIMDの利点の検証
    SIMDを評価するにはTectorwiseのみを用いた。 SIMDではスカラーなデータをベクトルに変換するペナルティは少く、最大8.4倍の性能向上が確認された。
    しかし複雑なクエリでは少ない性能向上に留まった。 これはOLAPクエリのパフォーマンス向上はデータアクセスに縛られる為である。

    Figure 6: Scalar vs. SIMD Selection in Tectorwise – (a) 40% selectivity. (b) Secondary selection: Input selection vector selects 40% and selection selects 40%. (c) Runtime of TPC-H Q6, SF=1
    Figure 6: Scalar vs. SIMD Selection in Tectorwise

  3. マルチコアCPUにおけるクエリ並列化
    TyperとTectorwiseの比較に用いたクエリで実験したところ、Hyperでは11.7倍、Tectorwise7.2倍の平均高速化が測定された。 いずれのモデルもスケールに対応している。またインメモリワークロードにおける実験で示された、それぞれのクエリの得意不得意 はマルチコアにも引きつがれている。

  4. 異なるハードウェアでのパフォーマンス
    Intel Skylake、Intel Knights Landing、AMD Ryzenで対照実験を行なったものの、 いずれのハードウェアでもTyper、Tectorwiseともに有効に動作した。

作業時間

  • read
    • 29:26
    • 29:26
  • author
    • 33:23
    • 3:57
  • summary
    • 76:37
    • 42:44

感想

VoectorwiseとHyperのいずれを使うべきか。どちらが優れているかといった疑問に答えるないようだった。

SIMDによるベクトル処理の最適化とRDBでの応用について扱った、最適化に関する論文を読みました

この記事の趣旨

2020年に提案された"Make the most out of your SIMD investments: counter control flow divergence in compiled query pipelines"という論文を読みました。

SIMDによるベクトル処理の最適化とRDBでの応用について扱った、最適化に関する論文です。

Make the most out of your SIMD investments: counter control flow divergence in compiled query pipelines

Harald Lang, Linnea Passing, Andreas Kipf, Peter Boncz, Thomas Neumann, Alfons Kemper

著者について

Harald Lang、 Linnea Passing、 Andreas Kipf、 Peter Boncz、 Thomas Neumann、 Alfons Kemperのグループ による研究

いずれも最新のアーキテクチャでのクエリ最適化やデータ分析における検索手法などを研究している。

問題意識

CPUの発展にともないあたらしいCPUアーキテクチャが登場した。Single Instruction Multiple Data(SIMD)では RDBSIMDによるベクトル処理能力の向上により、クエリコンパイラの実行パイプライン全体をベクトル化して 高度なデータ並列性の恩恵を受けることが出来るようになった。

一方でクエリ全体をベクトル化して実行することで、SIMDによるクエリ評価が忙しくなる。 SIMD評価で結果に寄与しない評価が単純にオーバーヘッドとなってしまう。

手法

本論文ではリフィルアルゴリズムとそのアルゴリズムをクエリパイプラインプランに統合する手法 で上記の問題の解決を試みている。

リフィルアルゴリズムは基本的に新しい要素を宛先レジスタの希望する位置にコピーするアルゴリズムで、 メモリからレジスタレジスタからレジスタへのコピーの2パターンが存在する。

クエリパイプラインプランに統合するリフィル戦略ではConsume EverythingパターンとPartial Consumeパターンが 存在する。

Consum Everything戦略は、タプルをバッファリングするために使用される追加のベクターレジスタを割り当てる方法で 利用率が低い場合、オペレータはこれらのタプルの処理を延期する。つまり、この反復ではボディは実行されず(条件が 満たされない場合)、代わりにアクティブなタプルがこれらのバッファレジスタに移動することになる。

Partial Consume戦略ではconsume()コードを入力の一部に適用する方法で、制御フローを前のオペレータに戻し、アクティブな データ断片のみをベクトルレジスタに残すことで実行を延期している。

作業時間

  • read
    • 29:40
    • 29:40
  • author
    • 33:40
    • 4:00
  • summary
    • 60:04
    • 26:36

感想

前回に引続き個人的には難しいと感じる論文だった。 2000年前後の提案にくらべ、2015年前後の論文ではハードウェアアーキテクチャを中心とした手法がピックアップされている。 単純に自分の知識不足、理解力不足なので勉強するしかない。

NUMAアーキテクチャでのクエリ最適化に関する論文を読みました

この記事の趣旨

"Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework for the Many-Core Age"という2014年に発表された、多コアサーバにおけるクエリ最適化 手法をあつかった論文を読みました。

[Morsel-Driven Parallelism: A NUMA-Aware Query

Evaluation Framework for the Many-Core Age](https://15721.courses.cs.cmu.edu/spring2023/papers/07-scheduling/p743-leis.pdf) Viktor Leis, Peter Boncz, Alfons Kemper, Thomas Neumann

著者について

Viktor Leis、 Peter Boncz、 Alfons Kemper、Thomas Neumannのグループによる研究 いずれもデータベースと 高速化かを中心に研究している。

問題意識

コンピュータアーキテクチャの進化にともない、二つのあたらしい問題 が生じた。

  1. 多コアを利用するためにクエリを数百のスレッドに均等に分散させる
  2. それをNUMA(Non-Uniform Memory Access)による順序通りではないメモリアクセスで実現する必要がある。

これらの要因からplanベースの並列処理による不可分散とコンテキストスイッチボトルネックが問題になりスケールが難しかった。

NUMAによってデータとアクセススレッドがどのチップに配置されるかによって、 データ項目のアクセスコストが異なるため、コンピュータ自体がネットワークになって おり、多コア並列化では、RAMやキャッシュ階層を考慮する必要がある。

この論文ではMoral-drivenクエリ実行フレームワークを提案している。

手法

提案手法は並列クエリ処理のため、morselドリブンクエリ評価フレームワークを提示した。 これはメニーコア時代の分析クエリ性能の主要なボトルネックである 負荷分散、スレッド同期、メモリアクセス局所性およびリソース弾力性を 解決することを目的としている。

ベースとなるアイデアは以下の2つに分けられる。

  1. メモリ上のデータをmorselと呼ばれる小さなバッチに分割し、バッチごとに処理を 実行したあとにそれぞれの処理結果をグローバルハッシュテーブルとしてまとめる。
    Figure 3: NUMA-aware processing of the build-phase
    Figure 3: NUMA-aware processing of the build-phase
  2. ディスパッチャと呼ばれる並行パイプライン制御を行ない、ワーカースレッドをタスクに割り当てる
    これによりクエリ実行中でも柔軟な並列度の変更を可能とした
    Figure 5: Dispatcher assigns pipeline-jobs on morsels to threads depending on the core
    Figure 5: Dispatcher assigns pipeline-jobs on morsels to threads depending on the core

まとめとして著者はきめ細かいスケジューリング、完全演算子並列化、低オーバーヘッド同期、 NUMA対応スケジューリングの原理を用いて、他のシステムでもメニーコアスケーリングを 改善できると示唆している。

作業時間

  • read
    • 28:36
    • 28:36
  • author
    • 32:45
    • 3:09
  • summary
    • 60:37
    • 27:52

感想

近現代のサーバアーキテクチャで主流になっているNUMAでのクエリパフォーマンス向上のための論文のため、 古典的なものに比べ概念が難しいものが多い。

もう少し理解を深めたい。

列指向DBMSにおけるデータを提案した論文を読みました

この記事の趣旨

"MonetDB/X100: Hyper-Pipelining Query Execution"という2005年に発表された、 列指向DBMSを提案した論文を読んでいきます。

分析ワークロード向けRDBMSにおける初期実装であるMonetDBを扱った論文で、提案時期が 2005年と古くはあるものの現代のDWHの礎となる内容です。

MonetDB/X100: Hyper-Pipelining Query Execution

Peter Boncz, Marcin Zukowski, Niels Nes

著者について

Peter Boncz、Marcin Zukowski、Niels Nseのグループによる論文。 いずれの著者も機械学習や分析におけるDBMSについて研究している。

問題意識

2005年当時のDBMSは他のアプリケーションに比べ、IPCが低くなる傾向にあった。 原因はほとんどのDBMSコンパイラの最適化を阻害する実装だったためである。 これはRDBMSが実装された当時に比べCPUやコンパイラが発達したためで、この論文では C-store DBMSであるMonetDBと従来のR-store DBMSをそれぞれTPC-Hで評価を行い、 パフォーマンス阻害要件と最適化方法を提案している。

手法

CPUによるIF文の処理方法はDBMSにとっては選択性が低く、そういった実行は予測不可能 でありクエリ実行を著しく劣らせた。 提案手法ではMonetDB/X100として効率的なシーケンシャルアクセスに向けた、C-storeス トレージとクエリエンジンを実装した。 RAMは提案手法のデータアクセスと同様の方法で圧縮して保存し、Cacheでは なベクトル化された処理にもとづくパイプライン実装を使用した。 CPUにおいてもベクトル型における式計算を提供し、コンパイラが高効率な処 理を生成した。

結果として提案手法は従来のDBMS実行に比べTPC-Hで優れた性能をしめした。

作業時間

  • read
    • 21:32
    • 21:32
  • author
    • 29:00
    • 7:28
  • summary
    • 56:20
    • 27:20

感想

2005年と古く、またVolcano-likeなど知らない概念も登場した。

提案内容としては現代のDWHが採用しているものだった。

論文外の感想

今回本文を読む時間を大幅に短くしてみたが、それにともない理解度も低下した気がする。

やっぱり30分以上で読むのがよさそう。

列指向DBMSにおけるデータ圧縮手法の論文を読みました

この記事の趣旨

"Integrating Compression and Execution in Column-Oriented Database Systems"とい う2006年に発表されたそれまで行指向DBMSで培われてきた圧縮方法による、検索高速化手 法を列指向DBMSに適用・評価した論文を読んで行きます。

Integrating Compression and Execution in Column-Oriented Database Systems

Daniel J. Abadi, Samuel R. Madden, Miguel C. Ferreira

著者について

Daniel J. Abadi、Samuel R. Madden、Miguel C. Ferreiraのグループ。 それぞれDBMSやデータ分析に関連する手法やパフォーマンスについて研究している。

問題意識

2006年ごろの研究ということもありC-storeデータベースの研究が少なかった時期の論文。 既に検索パフォーマンスに寄与することがしられていたR-storeデータベースの圧縮手法 を、C-storeへ応用や評価を行なった。

手法

提案手法は以下の圧縮技術の組み合わせからなる。

  1. Null圧縮
    Nullや0、空白を削除しどこに存在したかのみを記録する圧縮方法
  2. 辞書エンコーディング
    頻出するパターンをより短い文字列に起き変える圧縮手法
  3. Run Lengthエンコーディング
    どの文字がどこで何回出現したのかを記録する圧縮方式
  4. ビットベクターエンコーディング
    カテゴリカルなデータに有効なエンコーディングで、 それぞれのカテゴリに属するかどうかをバイナリで表現する圧縮方法
  5. Lempel-Zivエンコーディング
    GZIPでも使用されている圧縮方式。データの非重複ブロックを解析して既存のデータは 対応するブロックへのポインタに、それ以外のみを新規に追加する。

提案手法は圧縮方式が増えてもアクセスパターンをシンプルに留めるためにアクセス方法 をAPIとして隠蔽した。 そのため異なるエンコーディングも同一のAPIで保存でき、同一のAPIでも取得できる。

当然ながら一つのエンコーディングで全てのデータに対応することは難しく、論文では使 用すべき圧縮スキームの選び方を以下のようにまとめている。

Figure 10: Decision tree summarizing our results regarding the proper selection of compression scheme.
Figure10

感想

C-storeにおける古典的な圧縮手法がまとまった論文だった。 近代DWHを利用する側では意識することが少ない部分だったためあたらしい 知識も多かった。

作業時間

  • read
    • 26:50
    • 26:50
  • author
    • 33:30
    • 6:40
  • summary
    • 58:20
    • 24:50

Column Sketchesというindex手法の論文を読みました

この記事の趣旨

前回と同様に CMU Advanced Databas Systems Spring2023のReading Assignmentとして出ている論文を 読んで行きます。最近論文を読めてなかったのですが、この記事 でモーベーションが上がったので再開しました。

ころころやり方を変えるのはよろしくないものの、モチベーションのために先の記事のやり方でやります。

今回はColumn Sketchという名前のIndex手法を提案した論文です。Lossy Compressionを採用した当手法がどのように、 高速で堅牢な検索を実現しているのかについて述べています。

Column Sketches: A Scan Accelerator for Rapid and Robust Predicate Evaluation

Brian Hentschel, Michael S. Kester, Stratos Idreos

著者について

Brain、Michael、Stratosのグループによる論文。いずれも機械学習とデータアクセスについて研究している。

問題意識

既存のindex手法ではそれぞれに得意/不得意があり多くのアクセスパターンに対応できる方法がなかった。 またデータ分析で用いられるような列指向ストレージに対応しているものが少なかった。

Column SketchはデータをLossy Compressionを使用してindexを作成する手法でこれらの問題を解決した。

手法

提案手法はデータを任意のbit長に変換し、bitで表わされたデータに対して初回の検索を行なうことで大幅に検索速度を 向上させた。

またこの手法は数値型のみではなく、varcharなどで表わされたカテゴリカルタイプを数値として扱うことで、データ分析に必要な データタイプに対応している。

提案手法は8bit数値型であれば以下のようなマッピングによって達成される。

  1. for x, y ∈ I8, S (x) ≠ S (y) ⇒ x ≠ y
  2. for x, y ∈ I8, S (x) < S (y) ⇒ x < y

以下の図は8bitデータに対してWHERE x < 90がどのようにindex作成され評価されるかの例である。

Column Sketches use their compression map to transform (possibly compressed) values in the base data to smaller code values in the sketched column. These codes are then used to filter most values in the base data during predicate evaluation.
Figure2: Column Sketch

index作成段階では数値をレンジベースで任意の個数のbitに圧縮する。 そして評価時には90を含むデータより大きい値をすべて取得し、90を含むレンジに対しては個別に評価を行なう。

感想

読んでいる段階では数値型のみに対応したindexであれば、B-treeで十分ではないかと思ったものの 読み進めていくと限定的ながらも文字型にも対応していて、分析用途では必要な機能が備わっているなと思った。 全文テキスト検索のような用途には応用が難しそうで、銀の弾丸はないなと感じた。

作業時間

  • read
    • 27 min
    • 27 min
  • author
    • 32 min
    • 5 min
  • summary
    • 58 min
    • 26 min

論文以外への感想

今回採用した論文の読み方をやってみた 思ったのは事前に1時間で読んでまとめるぞと決めたことで随分集中して論文を読めました。 あと今まで論文を原文で読まなきゃという個人的な使命感があったのですが、翻訳することで随分効率があがったので 今後は翻訳してしまおうと思いました。

Readableは文末のrea-dableのような表記や翻訳されない部分(おそらく数式を含む文章?)があるものの、 フォーマットが維持されているため原文と照しあわせながら読めば非常に効率がよかったです。 毎日論文読むなら正直買いです。

毎日論文読みたいので課金しました。がんばるぞ!