6

分析されるメッセージの継続的なストリームがあります。分析では、著者、トピック、センチメント、単語数、一連の単語など、さまざまな変数が返されます。システム内のユーザーは、一致した場合にアラートをトリガーするルールを定義できます。ルールは sql-database に保存する必要があります。ルールは、メッセージ分析からの単一基準の結合ですword-count > 15 && topic = 'StackOverflow' && sentiment > 2.0 && word-set contains 'great'。許可された各ルール基準は、メッセージ分析の最後に提供されます。その後、ルール検証がトリガーされ、Java で実装されます。

すべてのメッセージは、システム内のすべてのユーザーによって定義されたすべてのルールをチェックする必要があり、多くの計算能力を消費します (現在、1 秒あたり 10 以上のメッセージがあり、チェックするルールは 10,000 以上になります)。照合プロセスを高速化するための一般的なパターンはありますか? 1 つずつではなく、ルールを並行してチェックできるようにするためでしょうか? 純粋な SQL でこれを行うことは可能ですか?さまざまなタイプのルールのスキーマはどのようになりますか?

4

2 に答える 2

2

あなたの考慮事項は、マッチングのスループットだけではありません。たとえば、ルールを維持する必要があります。

しかし、すべてのルールを満たすために必要なすべてのフィールドを含むルールとメッセージの静的セットを想定してみましょう。SQL を使用すると、構造はテーブルから始まりmessageます。このテーブルにはinsertトリガーがあります。挿入トリガーは、ルールへの一致を担当します。これを行う最善の方法は何ですか？

毎秒 10 件以上のメッセージがあるため、各マッチがシングル スレッドであっても、処理は本質的に並列になります。試合を並列化するのにどれだけの労力が必要かわかりません。データベースの並列処理は、通常、SQL ステートメント間ではなく、SQL ステートメント内で行われます。

あらゆる種類のソリューションがあります。たとえば、ルールを巨大なストアド プロシージャのコードとしてエンコードできます。これは維持するのに悪夢であり、ストアド プロシージャの長さの制限を超える可能性があり、非常に遅くなる可能性があります。

別のクレイジーなアイデア。ルールに一致するメッセージをそのルールのテーブルに保存し、一致するメッセージのみをロードする制約を設定します。あなたのプロセスは無数の挿入ステートメントのように見えます。

もっと真剣に、次のようなコードをさらに進めます。

select *
from rules
where . . .

結果セットには一致するルールがあります。句は次のwhereようになります。

select *
from rules r
where @wordcount > coalesce(r.wordcount, 0) and
      @topic = coalesce(r.topic, @topic) and
      . . .

つまり、すべてのルールのすべての可能な比較がwhere節に含まれます。また、ルールは前処理されて、必要な句が特定されます。

外部変数を省略して、クエリに直接アクセスすることもできます。

select *
from rules r cross join inserted i
where i.wordcount > coalesce(r.wordcount, 0) and
      i.topic = coalesce(r.topic, @topic) and
      . . .

はい、これは SQL で実現可能です。そして、マッチングを並行して行うことができます。データベースの比較に適した形式でルールを取得する作業を行うだけです。

于 2013-01-09T16:46:33.717 に答える
1

SQLを使用していませんが、C＃で同様の問題を解決しました。

移植性のために、ルールをシリアル化されたXMLとしてデータベースに保存しました。

アプリケーションの起動時、またはルールテーブルが変更されたとき（ルールキャッシュを強制的にフラッシュするとき）、データベースからすべてのルールをロードし、それらを適切なクラスに逆シリアル化しました。

次に、各アプリサーバーにデータが届くと、受信データに対してルールを実行し、ルールを渡すために適切なアクションを実行しました。（当時、アプリサーバーのprocでアクションを実行していましたが、今はキューにダンプします。）

これには、計算をアプリクラスター全体に分散させ、データベースマシンですべてのサイクルを吸収し続けることがないという利点があります。

于 2013-01-09T16:47:32.723 に答える