EventStore против MongoDb

Я хотел бы знать, какие преимущества есть при использовании EventStore (http://geteventstore.com) за использование источника событий в MongoDb.

Причина, по которой я спрашиваю, заключается в том, что в нашей компании работает целый ряд людей, которые ежедневно работают с MongoDb. Однако они не работают с Event Sourcing. Хотя они не совсем в темноте относительно предмета, они также не собираются внедрять его нигде.

Я собираюсь запустить проект, который отлично подходит для Event Sourcing. Есть около 16 очень четко определенных событий и около 7 четко определенных прогнозов. Я говорю "о", потому что я знаю, что будет спрос на большее количество прогнозов и событий после того, как они видят используемый продукт.

Этот подход будет первым API, с REST Api, который будут потреблять другие части нашей организации.

Хотя я много читал о Event Sourcing, как его определяет Грег Янг, я никогда не реализовал решение для поиска событий.

Это проект зеленого поля. Никаких технологических ограничений, поскольку мы собираемся разоблачить все как интерфейс REST. Поэтому, если у кого-то есть опыт работы с EvenStore или Event Sourcing с MongoDb, пожалуйста, просветите меня.

Также почти полностью не связанный вопрос о Event Sourcing: Вы когда-нибудь запрашивали хранилище событий напрямую? Или вы всегда будете создавать новые прогнозы и повторить событие, чтобы заполнить эти прогнозы?

Ответ 1

Отказ от ответственности Я Грег Янг (если вы не можете прочитать мое имя:))

Я собираюсь ответить на этот вопрос, хотя я считаю, что он, скорее всего, будет удален. Этот вопрос для меня немного странный, но ответы довольно странные. Я не буду тратить время, чтобы ответить на каждый ответ индивидуально, но вместо этого поместил все мои комментарии в этот ответ.

1) Есть комментарий, который мы запускаем только в пользовательской версии моно, которая является деталью, но... Это не так (и не было более года). Мы ждали критических исправлений, которые мы сделали для mono (как пример threadpool.c, чтобы поразить их хозяина). Это произошло.

2) EventStore является лицензией BSD с 3-мя статьями. Не знаете, как вы могли бы утверждать, что мы не являемся Open Source. У нас также есть компания за ее поддержкой и коммерческая поддержка.

3) Кто-то упомянул, что мы перешли к версии 3 в сентябре. Версия 1 была выпущена 2 года назад. Версия 2 добавила кластеризацию (очевидно, некоторые изменения прерывания vs single node). Версия 3 добавляет массу вещей, включая способность конкурировать с потребителями. За это время очень мало изменилось с точки зрения фактического клиентского протокола (особенно для тех, кто использует HTTP API).

Что действительно беспокоит меня в рекомендациях, так это то, что они, похоже, не понимают, что они сравнивают. Это было бы примерно эквивалентно тому, что я сказал: "Какой должен использовать neo4j или leveldb?". Вы могли бы создать себе базу данных графа поверх leveldb, но это будет довольно немного работы.

Mongo в этом случае будет механизмом хранения в хранилище событий, который OP должен будет написать сам. Написание хранилища событий качества продукции - это нетривиальное упражнение поверх механизма хранения, если вы хотите иметь даже самые основные операции.

Я написал это в ответ на список рассылки, эквивалентный этому вопросу:

Как вы будете делать следующее с Mongo?:

Запись и чтение событий в/из потоков с упорядочением/оптимизмом concurrency/etc

Тогда:

Ваши прогнозы не хотят читать из потоков так же, как они были написаны, проекции обычно интересуются типами событий и хотят, чтобы все события типа T были независимо от потока, написанного и в правильном порядке.

Вероятно, вы также захотите, например, возможность переключаться в реальном времени с уведомлений о нажатых событиях на обработку выталкиваемой информации (например, опрос) и т.д.

Было бы разумнее, если бы сравнивали Кафку, Датомический и Event Store.

Ответ 2

Увидев, как другие ответы не говорят о инструментах или преимуществах в EventStore и относятся только к преимуществам MongoDB, я буду звонить. Но обратите внимание, что мой опыт ограничен.

Я начну с минусов...

Есть много проверок, которые могут привести к тому, чтобы решить, какую версию вы будете активно поддерживать. В то время как команда закрепила свои выпуски, что они пришли к версии 3, даже спустя 18 месяцев после ее выпуска, это должен быть индикатор того, что вам нужно подтянуть версию, которую вы поддерживаете для другой более поздней версии (что также может повлиять на платформу вы решили развернуть).
Это не будет легко работать на каждой платформе (особенно если вы пытаетесь перейти к облачной среде или контейнеру lxc на докере). Некоторые из них связаны с сообществом, окружающим другие БД, такие как Монго. Но команда, похоже, работает на своих прикладах при работе на чтение/запись, сохраняя при этом стабильность кросс-платформы. По мере того, как время нажимает на меня, я обнаружил, что вы не хотите отклоняться слишком далеко от реализаций ОС, которые в этот день не привлекательны.
Использует специальную версию Mono. Поиск поддержки более старых версий Mono служит только для того, чтобы сделать процесс более корневым каналом.
Чтобы максимально использовать производительность EventStore, вам действительно нужно подумать о своей архитектуре. Выходы EventStore на плоские файлы и данные событий могут расти довольно быстро. Каков уровень отказов на дисках, в котором вы сохраняете свои данные. Как вещи сжаты? архивировать? и т.д. У вас много контроля, и элемент управления предназначен для хранения ваших данных в качестве событий. Тем не менее, хотя я уверен, что сам Грег Янг мог бы процитировать меня в моих могилах, которые оптимизируют и сохраняют ваши диски в долгосрочной перспективе, я, скорее всего, найду зрелого сообщества Монго, у которого был опыт работы в подобных случаях.

И профи...

RESTful - это AtomPub. Является ли ваш поток недостаточно конкретным? Создайте еще и сделайте http до вашего сердца. Обеспокоенные маршрутизацией делают http forward. Обеспокоенный безопасностью поставил перед собой прокси-сервер http. Простой!
У вас есть хороший набор инструментов и пользовательский интерфейс для тестирования и построения ваших прогнозов, когда ваши события начинают генерировать новые данные (например, используйте Chrome-браузер как способ отладки ваших прогнозов... ya они написаны с помощью java script)
Прочитайте производительность. Поскольку приложение выводится в плоский файл, вы можете получить кеширование уровня ядра и выставить его через http в капле шляпы. Кроме того, индексы находятся в ваших потоках для запроса прогнозов против больших наборов данных (но я действительно получаю, что индексная производительность индекса будет ползать на вас со временем).

Я лично не буду использовать это для основного/критически важного/растущего приложения! Однако, если у вас есть боковая шкала для сохранения интересной среды событий, я бы ее отпустил! Я лично должен придерживаться Монго на данный момент.