メモリ最適化テーブル-メンテナンスが本当に難しいのでしょうか？

私は、MS SQL 2012から2014へのアップグレードの利点を調査しています。SQL2014の大きなセールスポイントの1つは、クエリを超高速にするメモリ最適化テーブルです。

メモリ最適化テーブルには、次のようないくつかの制限があることがわかりました。

• いいえ(max)サイズのフィールドありません
• 行ごとに最大1 KB
• timestampフィールドなし
• 計算列はありません
• UNIQUE制約なし

これらはすべて迷惑と見なされますが、パフォーマンス上のメリットを得るために本当に回避したい場合は、計画を立てることができます。

実際のキッカーは、ALTER TABLEステートメントを実行できないという事実であり、インデックスのリストにフィールドを追加するたびに、このリマロールを実行する必要がINCLUDEあります。さらに、ライブDBのMOテーブルにスキーマを変更するには、ユーザーをシステムから締め出す必要があるようです。

マイクロソフトがこの機能にこれほど多くの開発資金を投資したとは信じられないほど、これはまったくとんでもないことであり、維持するのは非常に実用的ではありません。これは、私がスティックの間違った終わりを得たに違いないという結論に私を導きます。メモリを最適化したテーブルについて誤解していたため、実際よりも保守がはるかに困難であると思われました。

それで、私は何を誤解しましたか？MOテーブルを使用しましたか？それらを使用および保守するのに実用的な何らかの種類の秘密のスイッチまたはプロセスがありますか？

いいえ、メモリ内は実際にこれは磨かれていません。アジャイルに精通しているなら、「最小限の出荷可能な製品」の概念を知っているでしょう。インメモリはそれです。私は、MSがSAPのHanaとその同類に対する応答を必要としていると感じています。これは、2014年リリースの時間枠でデバッグできるものです。

他のメモリと同様、インメモリにはコストと利点があります。主な利点は、達成可能なスループットです。コストの1つは、前述のように、変更管理のオーバーヘッドです。これは無駄な製品にはなりませんが、私の意見では、純利益をもたらすケースの数を減らすだけです。列ストアインデックスが更新可能になり、インデックスをフィルター処理できるように、メモリ内の機能が今後のリリースで改善されることは間違いありません。

SQL Server 2016が一般公開されました。予想どおり、インメモリOLTPには多くの機能強化が施されています。ほとんどの変更は、従来のテーブルがしばらくの間楽しんでいた機能を実装しています。私の推測では、メモリ内のテーブルと従来のテーブルの両方について、将来の機能が同時にリリースされると思われます。テンポラル表は、ケースインポイントです。このバージョンの新機能は、インメモリテーブルとディスクベーステーブルの両方でサポートされています。

新しいテクノロジーの問題の1つ（特に、機能が完全ではないとして大々的に公開されたV1リリース）は、誰もが時流に乗って、すべてのワークロードに完全に適合すると想定していることです。そうではありません。Hekatonのスイートスポットは、256 GB未満のOLTPワークロードであり、2〜4ソケットで多くのポイントルックアップを行います。これはワークロードに合っていますか？

制限の多くは、ネイティブにコンパイルされたプロシージャと組み合わされたメモリ内テーブルに関係しています。もちろん、インメモリテーブルを使用することでこれらの制限の一部をバイパスできますが、ネイティブにコンパイルされたプロシージャを使用しないか、少なくとも排他的ではありません。

明らかに、環境のパフォーマンスが大幅に向上するかどうかをテストする必要があります。もしそうであれば、トレードオフに値するかどうかをテストする必要があります。インメモリテーブルのパフォーマンスが大幅に向上している場合、INCLUDE列で実行するメンテナンスの量が心配になる理由はわかりません。メモリ内インデックスは、定義によりカバーされます。これらは、従来の非クラスター化インデックスの範囲またはフルスキャンでのルックアップを回避するのに本当に役立つはずです。また、これらの操作はメモリ内のテーブルで実際に行われることは想定されていませんそして、それはそうではありません-それはすべてwin-winではありません）。今日、どのくらいの頻度でインデックスのINCLUDE列を使用していますか？

基本的に、V1形式でまだ価値がない場合は、使用しないでください。それは、多くの顧客にあなたに伝えることを除いて、あなたのために答えることができる質問ではありませんが制限に喜んで従い、それらの機能にもかかわらず大きなメリットを得るためにこの機能を使用。

SQL Server 2016

SQL Server 2016に向かっている場合は、インメモリOLTPで見られる機能強化と、いくつかの制限の解消についてブログに記載しています。最も注目すべきは：

• 最大耐久テーブルサイズの増加：256 GB => 2 TB
• LOB / MAX列、NULL入力可能列のインデックス、BIN2照合要件の削除
• プロシージャの変更と再コンパイル
• ALTER TABLEの一部のサポート-オフラインになりますが、インデックスを変更および/またはドロップ/再作成できるはずです（ただし、これは現在のCTPビルドではサポートされていないようですので、これを保証として受け取らないでください）
• DMLトリガー、FK /チェック制約、MARS
• または、IN、IN、EXISTS、DISTINCT、UNION、OUTER JOIN
• 並列処理

Sql Server Management Studio内から、メモリを最適化したテーブルを右クリックしてデザイナーを表示し、必要に応じて新しい列を追加することはできません。名前を変更する手段として、テーブル名内をクリックすることもできません。（これを書いている時点でのSQL2014。）

代わりに、テーブルを右クリックして、作成コマンドのスクリプトを作成できますを新しいクエリウィンドウにます。この作成コマンドは、新しい列を追加することで修正できます。

したがって、テーブルを変更するには、新しいテーブル、一時テーブル、またはテーブル変数にデータを保存できます。次に、新しいスキーマでテーブルを削除して再作成し、最後に実際のデータをコピーして戻します。この3コンテナシェルゲームは、ほとんどのユースケースで少し不便です。

ただし、解決しようとしているパフォーマンスの問題がない場合は、メモリ最適化テーブルを使用する必要はありません。

次に、制限と回避策がユースケースにとって価値があるかどうかを検討する必要があります。パフォーマンスに問題がありますか？他のすべてを試しましたか？これにより、パフォーマンスが10〜100倍向上しますか？どちらを使用するか、使用しないかは、どちらかといえば簡単です。

運用サーバーでインメモリOLTPを大きな問題なく使用できます。このテクノロジーを銀行および決済会社で使用し、

一般に、ワークロードが高すぎる場合は、メモリ最適化テーブルを使用できます。インメモリOLTPを使用すると、パフォーマンスが30倍に向上します。Microsoftは、SQL Server 2016および2017でこの制限のほとんどを修正しています。メモリ最適化テーブルのアーキテクチャは、ディスクベースのテーブルとはまったく異なります。

メモリ最適化テーブルには2つのタイプがあります。耐久性のあるテーブルと耐久性のないテーブル。永続テーブルと非永続テーブルは、テーブルデータをメモリに常駐させます。さらに耐久性のあるテーブルは、回復データとスキーマのためにデータをディスクに保持します。失われたデータはここで重要であるため、運用シナリオのほとんどでは永続テーブルを使用する必要があります。たとえば、ETLの読み込みやキャッシュなどのシナリオでは、非耐久性のテーブルを使用できます。

この電子ブックを使用して、このテクノロジーの使用方法を学ぶことができます。

カレン・デラニー： https

ドミトリ・コロトケビッチ：https ://www.apress.com/gp/book/9781484227718