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