[D23] SQL Server 2014 リリース記念！～Hekaton, カラムストアを試して、さらにギンギンに速くしてみました！～by Daisuke Hirama

Hekaton, カラムストアを試して、
さらにギンギンに速くしてみました！
Copyright © 2014 Insight Technology, Inc. All Rights Reserved.
平間大輔
株式会社インサイトテクノロジー
SQL Server 2014 リリース記念！

なぜ、今出したのか？

どっちが速い？
速い！
新しい！
多い！

チェックポイントはQPI
Xeon E5-4600
(Sandy Bridge-EP)
Xeon E7-4800
(Westmere-EX)

NUMAの恐怖
0
200
400
600
800
1000
1200
ノード0 ノード１ノード2 ノード3
Sandy Bridge-EP RAID1 1組のスループット(MB/s)

戦える武器をついに手にした
Xeon E7-4800 v2
(Ivy Bridge-EX)

NUMA node間の速度も違う
3

10GB/s越え!
0
2000
4000
6000
8000
10000
12000
4KB 8KB 16KB 32KB 64KB
SSD22本(RAID10)のスループット (MB/s)

2 Socket マシンだってすごい

Numa Node間のQPIは2本
Xeon E5-2600 (Sandy Bridge)
Xeon E5-2600v2 (Ivy Bridge)

SSDの性能限界を引き出す!
0
2000
4000
6000
8000
10000
12000
14000
4KB 8KB 16KB 32KB 64KB 128KB 256KB 512KB 1024KB
SSD22本(RAID10)のスループット(MB/s) - 2socket machine
reading - random
reading - sequential
writing - random
writing - sequential

IOPSもすごいぞ
0
50000
100000
150000
200000
250000
300000
350000
400000
450000
4KB 8KB 16KB 32KB 64KB 128KB 256KB 512KB 1024KB
reading - random
reading - sequential
writing - random
writing - sequential

ここまでのまとめ
• データベースサーバーは注意深く選ぼう
• CPUコア数も大事だけどI/Oがキモだよ。
• Xeon E5-4600シリーズ(v2も)は罠だ!
• ストレージはディスク単体よりトータルのスループ
ットが重要

いよいよ、SQL Server 2014の新機能へ!

実用的になったカラムストアインデックス
※全ての図版について、出典：SQL Server 2014 自習書より

CPUキャッシュに最適化
※db tech showcase 2013 Tokyo 熊澤氏の講義資料より

最大値・最小値も自動格納

実行時間は 1/3 !
CSIなし CSIあり

更新してしまうと…
CSIなし CSIあり CSIあり更新後

リビルドで復活!

TPC-Hは３部門でトップに

新機能の大本命、その名はHekaton
In memory OLTP機能
メモリ最適化テーブル
データの永続化も可能
ネイティブコンパイルストアドプロシージャ
ロック・ラッチ待ちなし
既存のテーブルと共存可能

行の生存期間を行内に持つ
Row header Payload (table columns)
Begin Ts End Ts StmtId IdxLinkCount
8 bytes 8 bytes 4 bytes 2 + 2 (padding)
bytes
8 bytes * (IdxLinkCount)
※Microsoft Build 2014より
• メモリ最適化テーブルの行フォーマット

古い行へはポインタで
50, ∞ John Paris
Timestamps NameChain ptrs City
Hash index
on Name
Transaction 100:
UPDATE City = ‘Prague’ where Name = ‘John’
No locks of any kind, no interference with transaction 99
100, ∞ John Prague
90, ∞ Susan Bogota
100
Transaction 99: Running compiled query
SELECT City WHERE Name = ‘John’
Simple hash lookup returns direct pointer to ‘John’ row
Background operation will
unlink and deallocate the
old ‘John’ row after
transaction 99 completes.
※Microsoft Build 2014より

Hekatonを使うためには
• PRIMARY KEY制約が必須
• FOREIGN KEY, CHECK, UNIQUE制約は使えない
• CHARとVARCHARのコードページは1252(Latin1)のみ
• スキーマ変更不可(インデックスの追加作成も不可!)
• トリガー不可
• インデックス内の全ての列はNOT NULL
• インデックス内の文字列型の照合順序はBIN2のみ
• 複数データベースにまたがるクエリ不可
• トランザクション内の分離レベルはSNAPSHOT, REPEATABLE
READ, SERIALIZABLEのみ、かつwith句でのテーブルヒントとして
指定する必要あり
• ネイティブコンパイルストアドプロシージャでの制限
– カーソル不可
– サブクエリ不可
– ディスクベースのテーブルへのアクセス不可
– ビューへのアクセス不可 …まだまだあるよ!

TPC-Cで勝負だ!
ベンチマークツールHammerDBを既存のアプリケーション
に見立て、以下の通り修正
– メモリ最適化テーブルに変更
– 主キーを設定(元テーブルはUNIQUEインデックス)
– 全クエリにWITH(SNAPSHOT)ヒントを追加
– データの永続化を選択
以下は使わず(もし使えばパフォーマンス向上の余地あり)
– HASHインデックスは使わない
– ネイティブコンパイルストアドプロシージャは使わない
 使ったら10倍以上の性能向上との情報もあるけど…
環境は以下の通り
– DBサイズは約10GB
– マシンはMemory: 768GB, SSD: 750GB
→ つまり、通常でも全データがバッファに載る環境

DEMO
DEMO

sys.dm_os_wait_statsで理由を確認
wait_type 10秒間での待機時間(ms)
WRITELOG 643289
WAIT_XTP_HOST_WAIT 44180
LAZYWRITER_SLEEP 20055
SLEEP_TASK 15141
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 12001
XE_TIMER_EVENT 11439
HADR_FILESTREAM_IOMGR_IOCOMPLETION 10065
DIRTY_PAGE_POLL 10063
WAITFOR 10003
REQUEST_FOR_DEADLOCK_SEARCH 10001
LOGMGR_QUEUE 9780
WAIT_XTP_OFFLINE_CKPT_NEW_LOG 7273
BROKER_TO_FLUSH 5128
SOS_SCHEDULER_YIELD 1650
PREEMPTIVE_OS_WRITEFILE 233
PREEMPTIVE_OS_FILEOPS 18
PREEMPTIVE_OS_CREATEFILE 17
SOS_PHYS_PAGE_CACHE 2
PREEMPTIVE_OS_CLOSEHANDLE 2
LCK_M_IU 2
PREEMPTIVE_OS_DELETEFILE 1
LOGPOOL_FREEPOOLS 1
wait_type 10秒間での待機時間(ms)
CXPACKET 1078921
WRITELOG 432895
PAGELATCH_EX 214532
PAGELATCH_SH 152736
LCK_M_X 99154
LCK_M_S 96476
CXROWSET_SYNC 50585
LAZYWRITER_SLEEP 20024
SLEEP_TASK 15224
LATCH_EX 12703
DIRTY_PAGE_POLL 10063
HADR_FILESTREAM_IOMGR_IOCOMPLETION 10025
XE_TIMER_EVENT 10001
WAIT_XTP_OFFLINE_CKPT_NEW_LOG 10001
WAITFOR 10000
REQUEST_FOR_DEADLOCK_SEARCH 9998
LOGMGR_QUEUE 9815
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 8008
BROKER_TO_FLUSH 5132
SOS_SCHEDULER_YIELD 2604
LCK_M_RIn_NL 1651
LATCH_SH 592
LCK_M_RS_S 400
LCK_M_RS_U 233
CMEMTHREAD 203
LCK_M_U 199
EXECSYNC 181
PAGEIOLATCH_SH 57
PREEMPTIVE_OS_WRITEFILE 39
PREEMPTIVE_OS_WRITEFILEGATHER 23
PREEMPTIVE_OS_FILEOPS 17
PREEMPTIVE_OS_GETDISKFREESPACE 10
LCK_M_IX 7
PREEMPTIVE_OS_FLUSHFILEBUFFERS 5
RESOURCE_SEMAPHORE_MUTEX 3
PAGELATCH_UP 1
通常のテーブルメモリ最適化テーブル

Hekatonでもディスクアクセスするの?

Hekatonは本物だ
• Hekatonは単にメモリ上にテーブルを載せただけのものでは
ない。専用のトランザクション分離レベルを導入し、ロック・ラッ
チ待ちをなくすことで、たとえ全データがキャッシュに載るDB
であってもさらに速くなる。
• 既存の環境を持ってくるときは要注意。
– テーブル、プロシージャの修正がほぼ必須
– スナップショット分離への変更に伴うアプリケーションの見直しも必要
• データ永続化をするならストレージにも注意。
みんな、SQL Server 2014で幸せになろうぜ!

[D23] SQL Server 2014 リリース記念！～Hekaton, カラムストアを試して、さらにギンギンに速くしてみました！～by Daisuke Hirama

More Related Content

What's hot

Viewers also liked

Similar to [D23] SQL Server 2014 リリース記念！～Hekaton, カラムストアを試して、さらにギンギンに速くしてみました！～by Daisuke Hirama

More from Insight Technology, Inc.

Recently uploaded

[D23] SQL Server 2014 リリース記念！～Hekaton, カラムストアを試して、さらにギンギンに速くしてみました！～by Daisuke Hirama