私は、SQL サーバー テーブルをキューとして使用するメッセージング システムを備えたプラットフォームを使用しています。
そのシステムはこれに基づいていました: Using Tables as queues
ATM では、データの耐久性/一貫性を保証するために、この分散スキーマが主に SQL ロックとディスク操作に基づいているため、スケーラビリティの問題に直面しています。
ディスクベースの I/O ボトルネックを解決し、悪い分散ロジックを改善するために、ディスクベースの SQL テーブルを SQL 2014 & 2016 で利用可能なインメモリ SQL (Hekaton) に変更することを考えています。
私はすでに Hekaton についていくつか読んだことがありますが、これが最善のアプローチであるかどうか、またはこれらのキューをインメモリに実装できるかどうか、またこれが最善のアプローチであるかどうかはまだわかりません。
これらのキューのほとんどは悲観的同時実行を実装しており、Hekaton はロック システムを使用せず、楽観的同時実行のみを使用します(マルチバージョニングに基づく)。悲観的な同時実行性を楽観的なものに変更することは「常に」(これは悪い言葉であることは知っています) 可能ですか? たとえば、上記のキューで。
Hekaton は、多くの挿入/削除 (エンキュー/デキュー)、行の並べ替え (FIFO キュー)、およびテーブル サイズの多くのバリエーション (サーバー上のワークロードの変動によってキュー サイズが増減します) に対応していますか? ネイティブ ストア プロシージャのクエリ パフォーマンスの統計を適切に更新することはできますか?
ネイティブ コンパイル SQL ストア プロシージャはパフォーマンスを大幅に向上させると思いますが、この種の実装 (相関 FIFO キュー) が Hekaton で使用するのに適しているかどうかはわかりません。メモリ キュー」の実装は、Hekaton を使用しています。