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 時にトランザクションログには書き込みを行うのでそこから復旧可能