Lamina vs Storm

Question

ストリーミング数値データをかなり大量（> 30G /日）処理するためのプロトタイプのリアルタイムモニタを設計しています。私はこれがClojureに書かれたいと思っています。言語が "Observer + State Machine"システムに適しているように思われるので、これがおそらく終わるでしょう。

私がフレームワークで見つけた主な候補は、LaminaとStormです。 RiemannとPulseもありますが、前者はフレームワークではなく完全な解決策であるようですが、私は最終的な設計にはまだコミットしません。パルスのレポは少し維持されていないように見えますか？

私が知りたいのは、これらの2つのプロジェクトはどのようなデータおよびワークフローに最適化されていますか？ストームはより成熟しているようですが、Laminaはより構成可能で、「Clojureic」（私の背景はPythonですので、これを高く評価する傾向があります）。私はオンラインを読んでから見つけた

何：

• ストームは、ビッグデータ（ストリーム）焦点を当てたように思わ、コアは、ClojureののDSLとストレートのJavaです。多くの既存のデータソースに対して、pre = builtハンドラがあるようです。

• Laminaは、Clojureを抽象化するためのコードをreused as a base for other eventing systemsとするより軽量で再利用可能なコンポーネントです。データソースはコードで処理する必要があります。

• 両方とも、すぐに使用できる集約/分割/計算ライブラリの便利なセットを持っています。 Laminaのgraphviz統合は素敵です。

Answer 1

それは私があなたの要件を理解して何からご使用に近いように思われ、一種の「Hadoopのようですが、ストリーミングのために」なるように設計されたため、ストームは、クラスタの管理と流れで失敗したノードの処理を組み込みました場合。

Answer 2

ラミナは大丈夫ですが、Storm - clusterコンピューティング管理のキラー機能が完全に欠けているようです。 Stormクラスターは、ノードのクラスター全体で計算を分散させるという厄介な作業の大部分を処理し、Stormフレームワークに収まる限り、ビジネスロジックに集中するだけです。私が見ることができるところから、Laminaはあなたの計算を整理する良い方法を提供しますが、それが必要なものならスケーリングの細部をすべて考慮しなければなりません。

Answer 3

ストームはおそらく悪い選択ではありませんが、数値データの「30GB以上」は大きなデータではなく、小さなデータです。半近代的なコンピュータであれば、薄層の1つのノードで簡単に多くのデータを処理できます。とにかくStormを使いたいかもしれないので、一度サーバーを増やす必要がある領域に入ると、簡単に拡張できますが、Stormをセットアップするための初期の摩擦があると思います（クラスタを維持する際の摩擦も継続しています）あなたがスケールアップする必要がなければ無駄になります。