[d23] sql server 2014 リリース記念！～hekaton,...

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 Name Chain 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で幸せになろうぜ!