SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

メモリ最適化テーブルの適用についての所感

one comment

昨日、メモリ最適化テーブル (Hekaton) の利用方法について数名の方からご質問いただきました。
Hekaton の利用方法について個人的な所感を。

私はまだ、案件での適用は経験していないため、経験則ではなくこんな感じかなという雑然とした内容になってしまってまいますが。
テーブルやクエリの制限などの仕様については前提として満たす必要がありますので、その辺は触れていません。

■データサイズについて


メモリ最適化テーブル のチェックポイントファイルの最大数は 128MB ×4,096 = 512GB となります。
Hardware Considerations for In-Memory OLTP in SQL Server 2014 によるとメモリ最適化テーブルの現状のサポートは 256GB となるようですので、テーブルのデータがこの範囲に収まるかどうかを検討する必要があります。
In Memory OLTP はすべてのデータをメモリ上に格納したうえで処理をすることが前提ですので、通常のディスクベースのテーブルと異なり、メモリが不足した場合にキャッシュアウトして領域を確保ということができませんのでメモリに収まるかが重要になってきます。

レコードはタイムスタンプを利用した、レコードの生存期間で管理がされるため、同一のレコードに対しての更新や削除を実施した場合は、メモリ上にはタイムスタンプの範囲が異なる更新前後のレコードが存在することになりますので、1 レコードに対してのメモリの消費が倍になることになります。
# メモリの解放は GC により実施されているようですので、解放は自動でされますが。

そのため、トランザクションの発生による更新頻度も考慮したうえでテーブルがサポートされるメモリにフィットするかを検討しておく必要があります。

256GB は中規模の DB であれば収まると思いますが、大規模適用しようとするとサイズが不足することが懸念されます。
大規模のデータベースで使用したい場合にはメモリ最適化テーブルのファイルグループはデータベース単位になりますので、データベースを分割したり、インスタンスを分けることで、データをうまくシャーディングして分散させることを検討する必要があるかと。

 

■永続化と非永続化


メモリ最適化テーブルのモードは [SCHEMA_ONLY] と [SCHEMA_AND_DATA] の 2 種類があり、チェックポイントファイルを使用してデータの永続化をするかを指定することができます。

非永続化した場合には、ログの書き込みサイズも抑制されるので、永続化と比較して処理を高速に行うことができます。

非永続化を使用するシナリオとしては SQL Server 2014 In-Memory OLTP – bwin Migration and Production Experience のセッション状態の管理 DB としての利用は面白いかもしれないですね。

永続化をした場合には、チェックポイントファイルにデータが書き込まれ、SQL Server のサービスを再起動した場合などはチェックポイントファイルの内容をメモリ上にロードして、メモリ最適化テーブルのデータの復元が行われます。
この際、データベースの状態は復旧中になり、復旧が完了するまでデータの操作ができなくなります。
そのため、永続化をした場合は、サービスの再起動時の復旧時間についても考慮をする必要が出てきます。
テーブルのサイズが大きくなれば、それだけ復旧にも時間がかかりますので。

格納するデータの特性を考慮し、永続化するか非永続かするかを見極める必要が出てきます。
DWH のワークテーブルのような一時的にデータを格納するような中間テーブルの場合には、永続化をする必要はありませんので非永続化のテーブルを使うことのは敷居が低いと思います。

 

■部分的な適用


メモリ最適化テーブルは高速に処理をすることができますのでいろいろなところに適用はしたいのですが、システム全体に適用しようとするとテーブルの制約がありますのでなかなか難しいかと思います。

全体的にメモリ最適化テーブルを使用するよりは、システムの一部に適用できないかということも考えていく必要があるのかと。
# 既存システムの改修 / 新規システムの構築でも考え方は同じで部分適用を視野に入れるとよいのかなと。

ネイティブコンパイルされたストアドプロシージャーもディスクベースのテーブル (通常のテーブル) との結合が現状はサポートされていないこともありますので、

  • 通常の T-SQL / ストアドプロシージャでアクセス
  • ネイティブコンパイルされたストアドプロシージャでアクセス

のどちらを使用するかは考慮しておく必要があります。

[一部のテーブルをメモリ最適化テーブルにして、T-SQL でアクセス] が一番適用がしやすいのかもしれないですね。

Written by masayuki.ozawa

9月 15th, 2013 at 11:46 am

Posted in SQL Server

Tagged with ,

One Response to 'メモリ最適化テーブルの適用についての所感'

Subscribe to comments with RSS or TrackBack to 'メモリ最適化テーブルの適用についての所感'.

  1. GCでメモリの解放が行われるということは、高頻度で書き込むとメモリがいっぱいになって書き込みエラーということもあるのだろうか、と思いました。(そのうちドキュメントが整備されるのでしょうけど)

    waquesseix

    17 9月 13 at 10:49

Leave a Reply

*