問題タブ [memory-optimized-tables]

私は、SQL サーバー テーブルをキューとして使用するメッセージング システムを備えたプラットフォームを使用しています。

そのシステムはこれに基づいていました: Using Tables as queues

ATM では、データの耐久性/一貫性を保証するために、この分散スキーマが主に SQL ロックとディスク操作に基づいているため、スケーラビリティの問題に直面しています。

ディスクベースの I/O ボトルネックを解決し、悪い分散ロジックを改善するために、ディスクベースの SQL テーブルを SQL 2014 & 2016 で利用可能なインメモリ SQL (Hekaton) に変更することを考えています。

私はすでに Hekaton についていくつか読んだことがありますが、これが最善のアプローチであるかどうか、またはこれらのキューをインメモリに実装できるかどうか、またこれが最善のアプローチであるかどうかはまだわかりません。

これらのキューのほとんどは悲観的同時実行を実装しており、Hekaton はロック システムを使用せず、楽観的同時実行のみを使用します(マルチバージョニングに基づく)。悲観的な同時実行性を楽観的なものに変更することは「常に」(これは悪い言葉であることは知っています) 可能ですか? たとえば、上記のキューで。

Hekaton は、多くの挿入/削除 (エンキュー/デキュー)、行の並べ替え (FIFO キュー)、およびテーブル サイズの多くのバリエーション (サーバー上のワークロードの変動によってキュー サイズが増減します) に対応していますか? ネイティブ ストア プロシージャのクエリ パフォーマンスの統計を適切に更新することはできますか?

ネイティブ コンパイル SQL ストア プロシージャはパフォーマンスを大幅に向上させると思いますが、この種の実装 (相関 FIFO キュー) が Hekaton で使用するのに適しているかどうかはわかりません。メモリ キュー」の実装は、Hekaton を使用しています。

キューを実装するために、ディスク内のキューをメモリ内 SQL Server 2016 に移行しています。

これは私のキュー形式です:

これは私Enqueueのネイティブ SQL Server ストアド プロシージャです。

Dequeueネイティブの SQL Server ストアド プロシージャを書き留めようとしていUPDATEますが、SELECT または変数テーブルの結果を使用して実装する方法に問題があります。

これまでのところ、私は試しました：

しかし、私はこのエラーが発生します:

サブクエリ (別のクエリ内にネストされたクエリ) は、ネイティブにコンパイルされたモジュールを含む SELECT ステートメントでのみサポートされます。

そこで、変数を使用して結果を格納するという別のアプローチを試みました。

まず、テーブル型を作成しました:

これまでのところとても良いので、私はそれを使用しようとしました：

次のエラーが表示されます。

スカラー変数「@result」を宣言する必要があります。

@result( がonを使用している場合のみWHERE @result.MsgId = dbo.SimpleQueue.MsgId)

ディスク SQL Server テーブルで使用する古いデキュー プロセスを次に示します。

その UPDATE と OUTPUT を更新された値にするにはどうすればよいですか (これは重要であるため、高いパフォーマンスを発揮します)。

SQL Server 2016 RC 2 でメモリ最適化テーブルの削除トリガーを作成しようとしています。

このクエリを実行すると、次のエラーが発生します。サブクエリ (別のクエリ内にネストされたクエリ) は、ネイティブにコンパイルされたモジュールを含む SELECT ステートメントでのみサポートされます。

現在のシステムは次のように構築されました。

DB テーブルには約 500 万のレコードがあります。必要に応じて、たとえば 100 万レコードの結果セットを取得し、アプリケーション全体でそれらをキャッシュに保持し、完了したらそれらを削除します。

ここで、.NET アプリケーションのメモリを使用する代わりに、「ディスク ベースのテーブルがまだ 500 万のレコードを保持している間に、メモリ内のテーブルを使用して 100 万のレコードをメモリ内のテーブルに保持することは可能ですか?」