読者です 読者をやめる 読者になる 読者になる

db tech showcase 大阪2013 Hekaton セッションメモ

Database Watch(2013年6月版):SQL Server 2014 処理高速化の仕掛け/Redshiftの先行評価の内容とは? (1/2) - @IT で SQLCAT 多田 さんのお話しが載っていたので、
この前の db tech showcase 大阪 2013 | Insight Technology, Inc. での Hekaton セッションの個人的なメモを書いておきます。

ほぼ、上記記事と同じ内容です。

メインメモリ最適化

 メモリ中データの最適化
  ページの概念は、メモリとディスクの行き来を想定している。メモリ内で完結するならページである必要が無い。
 インデックスはメモリ中のみ(Hash/Range)
  インデックスのメンテナンスに関するI/O無し
  インデックスはデータファイルに存在しない(ファイルサイズ減)
 バッファプール無し/B-Tree 無し
  B-Tree の場合、1行にアクセスするために、数ページ辿る必要がある
  Hekaton では、ハッシュインデックス。目的の行にダイレクトにアクセス
 ストリームベースのストレージ
  従来のチェックポイントでは、大量のランダムI/Oを発行
 メインメモリ
  Hekaton は UPDATE しない
   Timestamp を保持した追記型
  テーブルは行の集まり/行は複数バージョン保持
   それぞれの行は、2つのタイムスタンプによる有効範囲を保持している

T-SQL のフルコンパイル

 上がらないクロック => CPU を浪費しない必要性
 従来は、インタプリタ
 プロシージャコールは、DLLのエントリポイント
  コンパイルされたストアドプロシージャは DLL として保存される
   マシンコードまでコンパイルする
 フルコンパイルは、Hekaton だけ
  使える SQL 文にも制限がある
  通常の SQL Server のストアドはフルコンパイルしづらい
   ディスクにデータがあるため、コンパイル時に最適な実行プラン等を決められない

ロックフリーの高並列

 マルチバージョン楽観的並列制御下でのフルACID
  UPDATE は、内部的に INSERT
   有効範囲外データは、GC で回収
  =>後から UPDATE を発行した方が負ける
   COMMIT では無い!!
   =>通常の SQL Server だと、UPDATE でロックが掛かるので後から来た UPDATE はロックが解除されるのを待つ。
 コアエンジンがロックフリーなアルゴリズム
  CPUインストラクションレベルでの排他制御 (CMPXCHG)
 ロック/ラッチ/スピンロック なし
  アプリケーションによるロック競合
  ページラッチ/ページIOラッチ
  内部構造へのアクセスのためスピンロック
トランザクションログは同じファイルを利用
 ログレコードは少し変わっている


V1では、高速化を要するデータ・アプリケーションの一部の移行をターゲットにしている
 いきなり全部 Hekaton ではない
Hekaton もデータはファイルに書き込みを行う
 書き込みは非同期だから、書き込み前にサービスが落ちたらデータは消失する?
 =>commit 時にトランザクションログには書き込みを行うのでそこから復旧可能