39

私はStormを使用していますが、多くのユース ケースで問題ありません。最近、Storm の高レベルの抽象化であるTridentを調べました。1 回限りの処理をサポートし、ステートフルな処理を容易にします。

しかし今、私は疑問に思っています.なぜ、ストームの代わりに常にトライデントを使用できないのですか?

これまでに読んだこと：

  • Trident はメッセージをバッチで処理するため、スループット時間が長くなる可能性があります。
  • Trident はまだトポロジ内のループを処理できません。

ストームの代わりにトライデントを使用する場合、他に不利な点はありますか? 現時点では、上に挙げた欠点はわずかだと思います。

Trident で実装できないユースケースは?

余波：

私が質問をしたので、私の会社は最初にトライデントに行くことにしました。パフォーマンスに問題がある場合にのみ純粋な Storm を使用します。悲しいことに、これは積極的な決定ではなく、デフォルトの動作になっただけです (その時は私はいませんでした)。

彼らの仮定は、ほとんどのユースケースで状態または一度だけの処理が必要であるか、近い将来に必要になるというものでした。Storm から Trident へ、またはその逆に移行することは簡単な変換ではないため、彼らの理由は理解できますが、私の個人的な意見では、状態のないストリーム処理の概念はすべての人に理解されておらず、それが Trident を使用する主な理由でした。

4

5 に答える 5

46

To answer your question: when shouldn't you use Trident? Whenever you can afford not to.

Trident adds complexity to a Storm topology, lowers performance and generates state. Ask yourself the question: do you need the "exactly once" processing semantics of Trident or can you live with the "at least once" processing semantics of Storm. For exactly once, use Trident, otherwise don't.

I would also just like to highlight the fact that Storm guarantees that all messages will be processed. Some messages might just be processed more than once.

于 2013-10-10T06:21:37.487 に答える
20

レイテンシを可能な限り低くすることが目標であり、1 回だけの処理が必要ない場合は、Storm を使用する方が Trident よりも優れています。

于 2013-06-26T19:10:40.013 に答える
1

Chris さん、これら 2 つがオープン ソース テクノロジであるため、trident は嵐に乗ったシナリオの唯一の実装として機能します。もちろん、これはパフォーマンスのオーバーヘッドをもたらしました。トライデントが要件を満たせなかった場合は、ストームの上に独自の状態実装を作成します。Trident は、やがて Trident-ML などのより高いレベルのプロジェクトを生み出しました。

于 2014-03-06T14:59:59.547 に答える
0

フィルタリング + タプルへのフィールドの追加を行いたいとします。ストームを使用する場合、通常、フィルタリング、フィールドの追加に 2 つのボットを使用します。そのため、グローバル グループ化を使用してタプルを新しいボルトに送信する必要があります。そのため、ここでは帯域幅がボトルネックになる可能性があります。

trident を使用することで、単一のマシンで上記の操作を実行できます。したがって、この場合、再グループ化は必要ありません。「正確に1回」/「少なくとも1回」に加えて、そのようなユースケースは、何を使用するかなどを区別できます。

トライデントは一種のグループ化論理グループ化です

于 2015-07-29T08:59:01.847 に答える