concurrency - Modelo de concurrencia: Erlang vs Clojure

(5)

Vamos a escribir un programa concurrente utilizando Clojure, que extraerá palabras clave de una gran cantidad de correo entrante que se verificará en una base de datos.

Uno de mis compañeros de equipo ha sugerido usar Erlang para escribir este programa.

Aquí quiero señalar algo que soy nuevo en la programación funcional, así que tengo una pequeña duda de si clojure es una buena opción para escribir este programa, o Erlang es más adecuado.

Depende de lo que quieras decir con enorme
Las cuerdas en erlang son dolorosas ..

pero:

Si enorme significa decenas de máquinas distribuidas, vaya con erlang y escriba a los trabajadores en lenguajes amigables con texto (python, perl?). Tendrá una capa distribuida en la parte superior con trabajadores locales altamente concurrentes. Cada trabajador estaría representado por el proceso erlang. Si necesita más rendimiento, vuelva a escribir a su trabajador en C. En Erlang es muy fácil hablar en otros idiomas.

Si enorme todavía significa que una máquina fuerte va con JVM. No es enorme entonces.

Si enorme es cientos de máquinas, creo que necesitará algo más fuerte como google (bigtable, map / reduce) probablemente en la pila de C ++. Erlang todavía está bien, sin embargo necesitarás buenos desarrolladores para codificarlo.

¿De verdad quieres decir concurrente o distribuido?

Si te refieres a concurrente (multi-hilo, multi-core, etc.), entonces diría que Clojure es la solución natural.

El modelo STM de Clojure está perfectamente diseñado para la concurrencia de múltiples núcleos, ya que es muy eficiente para almacenar y administrar el estado compartido entre subprocesos. Si quieres entender más, vale la pena mirar este excelente video .
Clojure STM permite la mutación segura de datos por subprocesos concurrentes. Erlang evita este problema al hacer que todo sea inmutable, lo cual está bien en sí mismo pero no ayuda cuando realmente necesitas un estado mutable compartido. Si desea un estado mutable compartido en Erlang, debe implementarlo con un conjunto de interacciones de mensajes que no sea ni eficiente ni conveniente (ese es el precio de un modelo de nada compartido ...)
Obtendrá un mejor rendimiento inherente con Clojure si se encuentra en una configuración concurrente en una máquina grande, ya que Clojure no depende del paso de mensajes y, por lo tanto, la comunicación entre subprocesos puede ser mucho más eficiente.

Si quiere decir distribuido (es decir, muchas máquinas diferentes que comparten trabajo en una red que se ejecutan efectivamente como procesos aislados), diría que Erlang es la solución más natural:

El estilo inmutable de paso de mensajes de Erlang le obliga a escribir código de una manera que pueda distribuirse. Por lo tanto, Erlang idiomático se puede distribuir automáticamente en múltiples máquinas y ejecutarse en un entorno distribuido y tolerante a fallos.
Por lo tanto, Erlang está muy bien optimizado para este caso de uso, por lo que sería la elección natural y, sin duda, sería la más rápida para trabajar.
Clojure también podría hacerlo, pero tendrá que hacer mucho más trabajo usted mismo (es decir, deberá implementar o elegir alguna forma de marco de computación distribuida). Clojure no viene con dicho marco de forma predeterminada.

A largo plazo, espero que Clojure desarrolle un marco de cómputo distribuido que coincida con Erlang. ¡Entonces podrá tener lo mejor de ambos mundos!

Clojure es Lisp que se ejecuta en la JVM de Java. Erlang está diseñado desde cero para ser altamente tolerante a fallas y concurrente.

Creo que la tarea es factible con cualquiera de estos idiomas y muchos otros también. Su experiencia dependerá de lo bien que entienda el problema y de lo bien que sepa el idioma. Si eres nuevo en ambos, diría que el problema será difícil, sin importar cuál elijas.

¿Has pensado en algo como Lucene / Solr? Es un gran software para indexar y buscar documentos. No sé qué significa "comprobación cruzada" para su contexto, pero esta podría ser una buena solución a considerar.

Los dos idiomas y tiempos de ejecución adoptan diferentes enfoques para la concurrencia:

Erlang estructura los programas como muchos procesos ligeros que se comunican entre sí. En este caso, es probable que tenga un proceso maestro que envíe trabajos y datos a muchos trabajadores y más procesos para manejar los datos resultantes.
Clojure favorece un diseño donde varios subprocesos comparten datos y estados usando estructuras de datos comunes. Suena especialmente adecuado para los casos en los que muchos subprocesos acceden a los mismos datos (solo lectura) y comparten poco estado mutable.

Necesita analizar su aplicación para determinar qué modelo se adapta mejor a usted. Esto también puede depender de las herramientas externas que use, por ejemplo, la capacidad de la base de datos para manejar solicitudes concurrentes.

Otra consideración práctica es que clojure se ejecuta en la JVM donde hay muchas bibliotecas de código abierto disponibles.

Mi enfoque sería escribir una prueba simple en cada idioma y probar el rendimiento de cada uno. Ambos idiomas son algo diferentes a los lenguajes de estilo C y si no estás acostumbrado a ellos (y no tienes un equipo que esté acostumbrado a ellos) puedes terminar con una pesadilla de mantenimiento.

También me gustaría usar algo como Groovy 1.8. Groovy ahora incluye GPars para habilitar la computación paralela. La manipulación de cadenas y archivos en Groovy es muy sencilla.