EventStore対MongoDb
MongoDbでイベントソースを実装するよりも、EventStore（ http://geteventstore.com ）を使用することの利点を教えてください。
私が尋ねる理由は、私たちの会社にはMongoDbを毎日使用する多くの人々がいるからです。ただし、イベントソーシングでは機能しません。彼らは主題について完全に暗闇にいるわけではありませんが、どこかでそれを実装しようとしているわけでもありません。
イベントソーシングに最適なプロジェクトを開始しようとしています。明確に定義された約16のイベントと、明確に定義された約7つの予測があります。 「約」と言うのは、製品が使用されているのを見て、さらに多くの予測やイベントが必要になることを知っているからです。
REST APIを使用して、組織の他の部分が消費するAPIを最初に使用するアプローチになります。
グレッグヤングが定義する方法でイベントソーシングについて多くを読みましたが、実際にイベントソーシングソリューションを実装したことはありません。
これはグリーンフィールドプロジェクトです。すべてをRESTインターフェースとして公開するので、テクノロジーの制限はありません。EvenStoreでの実務経験またはMongoDbでのイベントソーシングの経験がある場合は、教えてください。
また、イベントソーシングに関するほぼ完全に関連のない質問：イベントストアに直接クエリを行うことはありますか？または、常に新しいプロジェクションを作成し、それらのプロジェクションを設定するイベントを再生しますか？
免責事項私はグレッグヤングです（私の名前が読めない場合:)）
とにかく削除されると思いますが、私はこの質問に答えます。私にとってこの質問だけでは少し奇妙ですが、答えはかなり奇妙です。時間をかけて各返信に個別に回答するのではなく、すべてのコメントをこの返信に書き込みます。
1）詳細なモノのカスタムバージョンでのみ実行されるというコメントがありますが、これは当てはまりません（1年以上も使用されていません）。モノに作成した重要なパッチを待機していました（例：threadpool.cがマスターにヒットする）。これが起こった。
2）EventStoreは、3条項のBSDライセンスです。あなたが私たちがオープンソースではないと主張する方法がわからない。また、その後ろに会社があり、商業的なサポートを提供しています。
3）誰かが9月にバージョン3に進むと言っていました。バージョン1は2年前にリリースされました。バージョン2ではクラスタリングが追加されました（明らかに、単一ノードと比べていくつかの重大な変更）。バージョン3では、競合する消費者を抱える能力など、多くのものが追加されています。この間、実際のクライアントプロトコルに関してはほとんど変更されていません（特にHTTP APIを使用している場合）。
推奨事項で本当に気になるのは、比較対象を理解していないようだということです。これは、「neo4jとleveldbのどちらを使用すればよいですか」とほぼ同じ意味になります。 leveldbの上にグラフデータベースを構築することもできますが、これはかなりの作業になります。
この場合のMongoは、OPが自分で書き込む必要があるイベントストアのストレージエンジンになります。プロダクション品質のイベントストアを作成することは、最も基本的な操作さえ必要な場合、ストレージエンジンに加えて簡単な作業です。
私は これはこの質問に相当するメーリングリストに対応して を書きました：
Mongoで次のことをどのように行いますか？：
順序付け/楽観的同時実行性などを使用して、ストリームとの間でイベントの書き込みと読み取りを行います。
次に：
プロジェクションは、書き込まれたのと同じ方法でストリームから読み取る必要はありません。プロジェクションは通常、イベントタイプに関心があり、適切な順序で書き込まれたストリームに関係なく、タイプTのすべてのイベントを必要とします。
また、たとえば、ライブをプッシュイベント通知からプル情報の処理（ポーリングなど）に切り替える機能も必要になるでしょう。
Kafka、datomic、およびEvent Storeが比較されている場合は、もっと理にかなっています。
他の返信は、EventStoreのツールやメリットについては触れておらず、私が紹介するMongoDBのメリットについてのみ言及しています。ただし、私の経験は限られています。
短所から始めましょう...
- 自分で積極的にサポートするバージョンを決定することにつながるチェックインはたくさんあります。チームはリリースを固めていますが、リリースから18か月後でもバージョン3に到達していることは、サポートしているバージョンを別のより新しいバージョンに引き上げる必要があることを示すものです（これはプラットフォームにも影響を与える可能性があります）展開先を選択します）。
- すべてのプラットフォームで簡単に機能するわけではありません（特に、クラウド環境またはDockerベースのlxcコンテナーに移動しようとしている場合）。これの一部は、Mongoなどの他のDBを取り巻くコミュニティによるものです。しかし、チームはクロスプラットフォームの安定性を維持しながら、読み取り/書き込みパフォーマンスを向上させてきたようです。時が経つにつれ、今日の時代には魅力的でないベアメタルOS実装からあまり離れたくないと気づきました。
- Monoの特別バージョンを使用します。古いバージョンのMonoのサポートを見つけることは、プロセスを根管に近づけるのにのみ役立ちます。
- EventStoreのパフォーマンスを最大限に活用するには、実際にアーキテクチャについて考える必要があります。イベントストアのフラットファイルへの出力とイベントデータは、急速に拡大する可能性があります。ディスクの故障率はどのくらいですか？物事はどのように圧縮されていますか？アーカイブしましたか？等。あなたは多くのコントロールを持ち、コントロールはデータをイベントとして保存することに向けられています。ただし、長期的にディスクを最適化して保存する機能をグレッグヤング自身が私のGraveに引用できると確信していますが、同様のケースに遭遇した経験のある成熟したMongoコミュニティを見つける可能性は高いです。
そして長所...
- RESTful-それはAtomPubです。あなたのストリームは十分に具体的ではありませんか？別のものを作成し、httpがあなたの心のコンテンツになるまで行います。ルーティングに懸念がある場合は、http転送を実行してください。セキュリティに不安があるため、httpプロキシを前面に配置します。シンプル！
- イベントが新しいデータの生成を開始すると、プロジェクションをテストして構築するための素晴らしいツールとUIのスイートがあります（たとえば、プロジェクションをデバッグする方法としてchrome browserを使用します... ya Javaスクリプト）で書かれている
- 読み取りパフォーマンス-アプリケーションはフラットファイルに出力するため、カーネルレベルのキャッシュを取得し、http経由でそれらを公開できます。また、インデックスは、大規模なデータセットに対する予測をクエリするためにストリーム全体にあります（ただし、インデックスのパフォーマンスが時間の経過とともに上昇すると感じています）。
私は個人的にこれをコア/ミッションクリティカル/または成長するアプリケーションに使用しません！ただし、イベント環境を面白く保つためのサイドケースがある場合は、それを提供します。個人的には今のところモンゴに固執する必要があります。