メモリ最適化テーブル-維持が本当に難しいのでしょうか？
MS SQL 2012から2014にアップグレードすることの利点を調査しています。SQL2014の大きなセールスポイントの1つは、メモリが最適化されたテーブルで、これによりクエリが明らかに高速になります。
メモリ最適化テーブルには、次のようないくつかの制限があることがわかりました。
- 番号
(max)サイズのフィールド - 行あたり最大1KB
timestampフィールドなし- 計算列はありません
UNIQUE制約なし
これらはすべて迷惑行為とみなされますが、パフォーマンスの利点を得るために本当に回避したい場合は、計画を立てることができます。
本当のキッカーは、あなたがALTER TABLEステートメントを使用すると、インデックスのINCLUDEリストにフィールドを追加するたびに this rigmaroleを実行する必要があります。さらに、ライブDBのMOテーブルにスキーマを変更するには、ユーザーをシステムからシャットダウンする必要があるようです。
これはまったくとんでもないことだと思います。Microsoftがこの機能にこれほど多くの開発資金を投資できたとは信じられず、維持するのが非常に非現実的なままであったからです。これは私が棒の間違った終わりを得たにちがいないという結論に私を導きます。メモリ最適化されたテーブルについて何かを誤解しているのかもしれません。そのため、テーブルを維持することは実際よりもはるかに難しいと思いました。
それで、私は何を誤解しましたか？ MOテーブルを使用しましたか？それらを使用して維持することを実用的にするある種の秘密の切り替えまたはプロセスはありますか？
いいえ、インメモリは本当にこれは洗練されていません。アジャイルに精通している場合は、「最小限の出荷可能な製品」の概念を理解できます。インメモリはそれです。 MSはSAPのHanaとその同類への対応を必要としていたと感じています。これは、2014年のリリースの期間中にデバッグできるものです。
他のものと同様に、インメモリにはそれに関連するコストと利点があります。主な利点は、達成できるスループットです。あなたが言及したように、コストの1つは変更管理のオーバーヘッドです。これはそれを役に立たない製品にするわけではありません、私の意見では、それはそれが純利益を提供するケースの数を減らすだけです。列ストアインデックスが更新可能になり、インデックスをフィルターできるように、インメモリの機能が今後のリリースで改善されることは間違いありません。
SQL Server 2016が一般提供されました。私が思ったように、 インメモリOLTP は多くの機能強化を受けています。ほとんどの変更は、従来のテーブルがしばらくの間楽しんでいた機能を実装しています。私の推測では、インメモリテーブルと従来のテーブルの両方について、将来の機能が同時にリリースされると思います。テンポラルテーブルは適切なケースです。このバージョンの新機能 In-Memory と disk-based の両方のテーブルでサポートされています。
新しいテクノロジーの問題の1つ、特に機能が完全ではないためかなり大声で公開されたV1リリースは、誰もがワゴンに飛び乗って、すべてのワークロードにぴったりであると想定していることです。そうではありません。 HekatonのスイートスポットはOLTP 256 GB未満のワークロードであり、2〜4ソケットで多くのポイントルックアップを行います。これはワークロードと一致しますか？
制限の多くは、ネイティブにコンパイルされたプロシージャと組み合わせたインメモリテーブルに関係しています。もちろん、メモリ内のテーブルを使用することでこれらの制限の一部を回避できますが、notネイティブにコンパイルされたプロシージャを使用するか、少なくとも排他的ではありません。
明らかに、パフォーマンスの向上がyour環境でかなり大きいかどうか、そしてかなり大きい場合は、トレードオフに価値があるかどうかをテストする必要があります。インメモリテーブルのパフォーマンスが大幅に向上している場合、INCLUDE列で実行するメンテナンスの量が気になる理由はわかりません。インメモリインデックスは、定義によるものです。これらは、従来の非クラスター化インデックスの範囲またはフルスキャンでのルックアップを回避するために本当に役立つはずであり、これらの操作はメモリ内テーブルで実際に発生するはずではありません（ここでも、ワークロードをプロファイルして、どの操作が改善されるかを確認する必要がありますそしてそれはそうではありません-それはすべてが有利なわけではありません）。今日、どのくらいの頻度でインデックスのINCLUDE列を操作しますか？
基本的に、V1の形式ではまだ価値がない場合は、使用しないでください。これは、多くのお客様areが限界に耐える意欲があり、この機能を使用していても、それらにかかわらず大きな利益をもたらすことを除いて、私たちが回答できる質問ではありません。
SQL Server 2016
SQL Server 2016に向かっている場合は、 インメモリOLTPで見られる機能強化と、いくつかの制限の解消について をブログに書いています。最も注目すべき点：
- 最大耐久テーブルサイズの増加：256 GB => 2 TB
- LOB/MAX列、null許容列のインデックス、BIN2照合要件の削除
- プロシージャの変更と再コンパイル
- ALTER TABLEの一部のサポート-オフラインになりますが、インデックスを変更および/または削除/再作成できるはずです（ただし、現在のCTPビルドではサポートされていないようなので、これを保証しないでください）
- DMLトリガー、FK /チェック制約、MARS
- または、NOT、IN、EXISTS、DISTINCT、UNION、OUTER JOIN
- 並列処理
できないメモリ最適化テーブルを右クリックしてdesignerをプルアップし、Sql Server Management Studioから好きなように新しい列を追加します。 できない名前の変更テーブルの手段として、テーブル名内をクリックします。 （これを書いている時点でのSQL 2014）。
代わりに、テーブルを右クリックして、新しいクエリウィンドウに作成コマンドのスクリプトを入力できます。この作成コマンドは、新しい列を追加することで修正できます。
したがって、テーブルを変更するには、データを格納するを新しいテーブル、一時テーブル、またはテーブル変数に含めることができます。次に、新しいスキーマを使用してテーブルをドロップして再作成する、最後に実際のデータをコピーして戻すを実行できます。この3コンテナーシェルゲームは、ほとんどのユースケースで不便です。
しかし、解決しようとしているパフォーマンスの問題がない場合は、メモリ最適化テーブルに悩む必要はありません。
次に、制限と回避策がユースケースにとって価値があるかどうかを検討する必要があります。パフォーマンスに問題がありますか？他のすべてを試しましたか？これにより、パフォーマンスが10〜100倍向上しますか？それを使用するか使用しないかは、いずれにせよ、頭を悩ませることになるでしょう。