0

私たちが構築してきたアプリケーションは、機能の大部分が整っているという点で固まり始めています。これにより、少し息抜きができるようになり、持続性モデルとその管理の評価を開始しています。この部屋の大きな象は RavenDB だと言えるでしょう。機能的にはまだ問題を経験していませんが、管理には満足していません. クエリの実行、コレクションの切り捨てなどの単純なタスクは、プラットフォームとドキュメント ベースの NoSql ソリューション全般に​​慣れていないため、私たちにとって挑戦的です。もちろん、私たちはそれを学ぶことができますが、それは自信、時間、そして既存の Sql Server スキルセットを活用することだと思います. 例えば、数週間にわたって数百万のイベントをシステムに送り込み、正常に処理されたというメッセージが MSMQ の監査キューにルーティングされました。また、ServiceInsight をインストールし、Audit キュー内のメッセージを処理したため、サーバー上のすべてのディスク領域が消費されました。これを修正する方法がわからなかったため、RavenDB 用に見つけたデータ ファイルを文字通り削除する必要がありました。ただ言っておきますが、それを行うと、あらゆる種類の頭痛が発生しました。

そのことを念頭に置いて、私はサービス エンドポイントのトランスポートおよび/または永続性に Sql Server を潜在的に活用することの実現可能性と利点を評価する責任を負っています。さらに、Sql Server を活用するように ServiceControl と ServiceInsight を構成するためのガイダンスも使用できます。これらの設定や、考慮すべき欠点やアーキテクチャの問題を特定することに関して、提供できる情報があれば大歓迎です。

ありがとう、ジェフリー

4

2 に答える 2

3

SQL 永続性を使用するために必要な構成 (実装の詳細) はほとんどありませんが、ブローカー スタイルのアーキテクチャに変更する場合、SQL トランスポートの使用はインフラストラクチャの決定よりもアーキテクチャの決定の方が多く、そのルートをたどる前に考慮する必要がある意味があります。

ServiceControl と ServiceInsight の永続性:

ServiceControl はデフォルトのトランスポートとして MSMQ を監視しますが、ServiceControl を使用して、RabbitMQ、SqlServer などの他のトランスポートもサポートできます。その方法の詳細については、こちらを参照してください。

現時点では、ServiceControl はその永続性を RavenDb に依存しており、ServiceControl は Raven 機能に依存しているため、それを SQL に変更することはできません。

HTH

于 2014-01-17T18:12:14.243 に答える
1

RavenDB の ServiceControl の使用について (これは、ServiceInsight UI にデータを提供する基礎となるサービスです):

Sean Farmar が (上記で) 述べたように、ポスト ベータ リリースでは、SC の容量使用率を完全に制御できるように、メッセージの有効期限とオンデマンドの監査メッセージ削除コマンドを含める予定です。

ServiceControl データベースの場所のドライブ/パスを変更して、より大きなドライブを使用できるようにすることもできます。

ServiceControl (およびそれを使用する ServiceInsight / ServicePulse) は、分析、デバッグ、および運用監視を目的としていることに注意してください。限られた量の監査済みデータを保存することを目的としています (スループットと容量のニーズに基づいて、メッセージ数としてカウントすると大幅に異なる場合がありますが、データベースのストレージ容量は最大 16 TB です)。

監査済みデータの長期保存が必要な場合は、ServiceControl HTTP API にフックして、メッセージのデータをさまざまな長期 / 無制限サイズ / 低コストのストレージ ソリューション (例: http://aws.amazon.com ) に転送できます。 /氷河）。

これがお客様のニーズに合っているかどうか、さらに質問があるかどうかをお知らせください

ダニー。

于 2014-01-18T17:59:02.630 に答える