1

はじめに太字を多用しておりますことをお詫び申し上げます。私の長い質問の仕方を簡単に理解したかったのです。

データへの複数アクセスに問題があります。

次の問題を実装する必要があります。多くの (約 100) TCP 接続を持つサーバー アプリケーションSERVER_A (TIdServer に基づく) があります。これらの接続のそれぞれの目的は次のとおりです。

  • CLIENTからステータス メッセージ (2 ～ 5 秒ごと) を取得します。ステータスには、テキストとして保存された 3 つの二重数値が含まれます。
  • SERVER_A からCLIENTに回答を送信- ステータスを取得した後

これらのステータス (約 100) は、Firebird データベース テーブル - TABLE (私はこの AnyDAC を使用しています) に保存する必要があります。各CLIENTには、その番号とそのレコードがTABLEにあります。

3 つの別のローカル ネットワーク クライアント アプリケーション - LOCAL_APPLICATIONSもTABLEにアクセスする必要があります。TABLEからの統計データを視覚化する必要があります。

LOCAL_APPLICATIONSは、 TABLEのレコードの 1 つを変更する必要がある場合があります。結果として、この変更は、応答としてSERVER_Aの TCP 接続を介して適切なCLIENTに配信される必要があります。

問題は、そのような解決策が達成される効率にあります。

これまでのところ、すべての TCP 呼び出しが個別にTABLEにデータを書き込み、Firebird に大規模な過負荷を引き起こし、LOCAL_APPLICATIONSによる操作はいずれ も非常に低速です。

したがって、私は尋ねることができます:正しいアプローチは、SERVER_AにLOCAL_ARRAYを構築し、すべての TCP 接続からデータを収集し、それらすべてを一定の時間間隔で定期的に (たとえば 2 秒ごとに) TABLEに保存することですか? もしそうなら、効率的なデータ同期を行う方法: LOCAL_ARRAYのロックを変更し、そこからデータを読み取ってTABLEにデータを保存する間にロックしますか?

接続ステータスごとに単一の変数を使用し、LOCAL_ARRAYを使用して、1 つのCLIENTからデータを挿入する際にLOCAL_ARRAYのすべてのフィールドをロックしないよう にすることをお勧めします。しかし、それは柔軟な解決策ではありません。

私のアイデアは効率を上げるのに良いですか？というかそうじゃない？より良い解決策は何ですか？

よろしく Artik

4

2 に答える 2

3

CQRS パターンを見てください。

CQRS はCommand Query Responsibility Segregationの略です。その中心にあるのは、情報を読み取るために使用するモデルとは異なるモデルを使用して情報を更新できるという単純な概念です。この単純な概念は、情報システムの設計に重大な影響をもたらします。

私の実験から、これはクライアント サーバー アーキテクチャでスケーリングと応答性を実装するための非常に優れたパターンです。

クエリに別のデータベース (可能であればメモリ内) を使用して、データを書き込むためのコマンド駆動型バスを使用できます。

これは、実装したいものに非常に近いです。おそらく、この CQRS パターンのようなより高度な情報が役立つかもしれません。

たとえば、CQRS では、複数のコマンドを 1 つのトランザクション内で SQL ステートメントの 1 つの "バッチ" に結合して、速度を上げるのが一般的です。一部の DB では、配列バインディングが可能であり、さらに高速になります。

ソース コードがないと、何が問題なのかを突き止めるのが難しくなります。あなたが示している数字で、アプリケーションの本当のボトルネックを見つけなければならないと思います。実際、FireBird の制限に到達するにはほど遠いと思いますが、それを制限するのは使用方法です。巧妙なキャッシュを追加し、明確な CQRS パターンを使用すると、大いに役立つ場合があります。

于 2013-04-28T12:35:28.790 に答える
0

クライアント側: サーバー/テーブルに「オンラインです」または「オフラインです」、またはユーザーがアクションを実行したときにこのようなメッセージを伝える関数/手順を作成します。2 ～ 5 秒ごとにステータス メッセージを送信する代わりに、

サーバー側: クライアントから新しいメッセージが到着したときに、最新の変更 (テーブルがいっぱいではない) のみをクライアントに通知する関数/手順を作成します。

または、このためにfirebirdでプロシージャを作成できます。これにより、ネットワークとサーバーのトラフィック/負荷が低下します。

編集：

別のアイデアは次のとおりです。標準データを識別/リストするための追加のテーブルを作成できます。どうですか？

クライアントに、またはクライアントから「HOT」、「COLD」、「COOL」のデータを送受信しているとします。長いテキストは、ネットワークとデータベースの負荷が高くなることを意味します。すべてのものの標準としてリストされているテーブルを作成できます。例を挙げましょう。

テーブル名 HotColdCool

ID   Description
1    HOT
2    COLD
3    COOL

このテーブルを使用すると、全文ではなく ID (任意の種類の int) のみを送受信します。これにより、多くのクライアントに対するネットワークとデータベースの負荷が軽減されます。

あなたのプロジェクトについてもっと説明してくれれば、私はあなたにそれについてもっと多くのアイデアを与えることができます.

于 2013-04-29T13:36:11.613 に答える