mongodb - open - java projects github

EventStore vs. MongoDb

Question

Me gustaría saber qué ventajas tiene utilizar EventStore ( http://geteventstore.com ) sobre la implementación de eventos en un MongoDb.

La razón por la que pregunto es que nuestra compañía tiene una cantidad de personas que trabajan con MongoDb diariamente. Sin embargo, no funcionan con Event Sourcing. Si bien no están completamente en la oscuridad sobre el tema, tampoco están dispuestos a comenzar a implementarlo en ninguna parte.

Estoy a punto de comenzar un proyecto, que es perfectamente adecuado para la contratación de eventos. Hay alrededor de 16 eventos muy bien definidos y alrededor de 7 proyecciones bien definidas. Digo "acerca de" porque sé que habrá demanda para más proyecciones y eventos una vez que vean el producto en uso.

El enfoque será API primero, con una API REST que otras partes de nuestra organización consumirán.

Si bien he leído mucho sobre el Abastecimiento de eventos de la manera que lo define Greg Young, nunca implementé una solución de Abastecimiento de eventos.

Este es un proyecto de campo verde. No hay restricciones tecnológicas ya que vamos a exponer todo como una interfaz REST. Entonces, si alguien tiene experiencia laboral con EvenStore o Event Sourcing con MongoDb, por favor, ilumíneme.

También una pregunta casi totalmente no relacionada con la fuente de eventos: ¿Alguna vez consulta directamente el almacén de eventos? ¿O siempre crearía nuevas proyecciones y eventos de repetición para completar esas proyecciones?

Answer 1

Al ver que las otras respuestas no hablan sobre las herramientas o los beneficios en EventStore, solo se refieren a los beneficios de MongoDB en los que intervengo. Pero tenga en cuenta que mi experiencia es limitada.

Voy a empezar con los contras ...

• Hay una gran cantidad de controles que pueden llevar a decidir qué versión se va a apoyar activamente. Si bien el equipo ha estado solidificando sus lanzamientos, el hecho de que hayan llegado a la versión 3 apenas 18 meses después de su lanzamiento debería ser un indicador de que debe recuperar la versión que está soportando para otra versión más reciente (que también puede afectar a la plataforma elige desplegar a).
• No va a funcionar fácilmente en todas las plataformas (especialmente si está tratando de moverse a un entorno de nube o un contenedor lxc basado en docker). Algo de esto se debe a la comunidad que rodea a otros DB como Mongo. Pero el equipo parece haber estado trabajando a tope en el rendimiento de lectura / escritura manteniendo la estabilidad multiplataforma. A medida que el tiempo avanza, he descubierto que no desea desviarse demasiado de una implementación de sistema operativo simple que este día en la antigüedad no es atractivo.
• Utiliza una versión especial de Mono. Encontrar soporte para versiones anteriores de Mono solo sirve para hacer que el proceso sea más un canal de raíz.
• Para aprovechar al máximo el rendimiento de EventStore, realmente necesita pensar en su arquitectura. Las salidas de EventStore a archivos planos y datos de eventos pueden crecer bastante rápidamente. ¿Cuál es la tasa de fallos de los discos en los que persiste sus datos? ¿Cómo se comprimen las cosas? archivado? Tienes mucho control y el control está orientado a almacenar tus datos como eventos. Sin embargo, aunque estoy seguro de que el mismo Greg Young podría citarme a mi tumba las características que optimizan y guardan sus discos a largo plazo, lo más probable es que encuentre una comunidad madura de Mongo que tenga experiencia en casos similares.

Y los pros ...

• RESTful - Es AtomPub. ¿Tu flujo no es lo suficientemente específico? Crea otro y haz http hasta que tus corazones estén contentos. Preocupado por el enrutamiento hacer un http hacia adelante. Preocupado por la seguridad poner un proxy http en frente. ¡Sencillo!
• Tienes un buen conjunto de herramientas e IU para probar y construir tus proyecciones a medida que tus eventos comienzan a generar nuevos datos (por ejemplo, utiliza el navegador Chrome como una forma de depurar tus proyecciones ... ya están escritas con un script Java)
• Rendimiento de lectura: desde la salida de la aplicación a un archivo plano, puede obtener el almacenamiento en caché a nivel de kernel y exponerlos a través de http en un abrir y cerrar de ojos. También hay índices en sus flujos para consultar proyecciones contra conjuntos de datos más grandes (pero realmente tengo la sensación de que el rendimiento del índice aumentará en usted con el tiempo).

¡Yo personalmente no usaría esto para una aplicación central / de misión crítica / o en crecimiento! Sin embargo, si tienes un caso paralelo para mantener interesante tu entorno de eventos, ¡lo dejaría pasar! Personalmente tengo que seguir con Mongo por ahora.

Answer 2

Descargo de responsabilidad Soy Greg Young (si no puedes leer mi nombre :))

Voy a responder a esta pregunta, aunque creo que probablemente se eliminará de todos modos. Esta pregunta solo para mí es un poco rara, pero las respuestas son bastante extrañas. No me tomaré tiempo para responder cada respuesta individualmente, sino que pondré todos mis comentarios en esta respuesta.

1) Hay un comentario que solo ejecutamos en una versión personalizada de mono que es un detalle pero ... Este no es el caso (y no lo ha sido por más de un año). Estábamos esperando los parches críticos que hicimos en mono (como ejemplo threadpool.c para golpear a su maestro). Esto ha sucedido.

2) EventStore tiene licencia BSD de 3 cláusulas. No estoy seguro de cómo puedes reclamar que no somos Open Source. También tenemos una empresa detrás de ella y brindamos apoyo comercial.

3) Alguien nos mencionó que pasamos a la versión 3 en septiembre. La versión 1 se lanzó hace 2 años. La versión 2 agregó la agrupación en clústeres (obviamente, algunos cambios importantes frente a un solo nodo). La versión 3 está agregando un montón de cosas, incluida la capacidad de tener consumidores que compiten. Muy poco ha cambiado en términos del protocolo del cliente real durante este tiempo (especialmente para aquellos que usan la API HTTP).

Lo que realmente me molesta en las recomendaciones, sin embargo, es que no parecen entender lo que están comparando. Sería más o menos el equivalente a que yo dijera "¿Cuál debería usar neo4j o leveldb?". Podrías construirte una base de datos gráfica en la parte superior de leveldb pero eso sería bastante trabajo.

En este caso, Mongo sería un motor de almacenamiento en la tienda de eventos que el OP tendría que escribir él mismo. Escribir un almacén de eventos de calidad de producción es un ejercicio no trivial sobre un motor de almacenamiento si desea tener incluso las operaciones más básicas.

Escribí esto en respuesta a la lista de correo equivalente a esta pregunta :

¿Cómo harás lo siguiente con Mongo ?:

Escriba y lea eventos a / desde flujos con orden / concurrencia optimista / etc

Entonces:

Sus proyecciones no desean leer las secuencias de la misma forma en que se escribieron, las proyecciones normalmente están interesadas en los tipos de eventos y desean todos los eventos de tipo T, independientemente de las secuencias escritas y en el orden correcto.

Probablemente también desee, por ejemplo, la posibilidad de cambiar en vivo de las notificaciones de eventos enviadas a manejar información extraída (por ejemplo, sondeo), etc.

Tendría más sentido si se compararan Kafka, datomic y Event Store.