Modèle de concurrence: Erlang vs Clojure
Nous allons écrire un programme simultané en utilisant Clojure, qui va extraire des mots-clés d'une énorme quantité de courrier entrant qui sera recoupé avec une base de données.
Un de mes coéquipiers a suggéré d'utiliser Erlang pour écrire ce programme.
Ici, je veux noter quelque chose que je suis nouveau dans la programmation fonctionnelle, je suis donc dans un petit doute si clojure est un bon choix pour écrire ce programme, ou Erlang est plus approprié.
Les deux langues et les exécutions adoptent des approches différentes de la concurrence:
Erlang structure les programmes comme autant de processus légers communiquant entre eux. Dans ce cas, vous disposerez probablement d'un processus maître envoyant des travaux et des données à de nombreux travailleurs et d'autres processus pour gérer les données résultantes.
Clojure privilégie une conception où plusieurs threads partagent des données et des états à l'aide de structures de données communes. Cela semble particulièrement adapté aux cas où de nombreux threads accèdent aux mêmes données (en lecture seule) et partagent peu d'état mutable.
Vous devez analyser votre application pour déterminer le modèle qui vous convient le mieux. Cela peut également dépendre des outils externes que vous utilisez - par exemple, la capacité de la base de données à gérer les demandes simultanées.
Une autre considération pratique est que clojure fonctionne sur la JVM où de nombreuses bibliothèques open source sont disponibles.
Voulez-vous vraiment dire simultané ou distribué?
Si vous voulez dire simultané (multi-thread, multi-core, etc.), je dirais que Clojure est la solution naturelle.
- Le modèle STM de Clojure est parfaitement conçu pour la concurrence multicœur car il est très efficace pour stocker et gérer l'état partagé entre les threads. Si vous voulez en savoir plus, cela vaut la peine de regarder cette excellente vidéo .
- Clojure STM permet une mutation sûre des données par des threads simultanés. Erlang contourne ce problème en rendant tout immuable, ce qui est bien en soi mais n'aide pas lorsque vous avez vraiment besoin d'un état mutable partagé. Si vous voulez un état mutable partagé dans Erlang, vous devez l'implémenter avec un ensemble d'interactions de messages qui n'est ni efficace ni pratique (c'est le prix d'un modèle rien partagé ....)
- Vous obtiendrez intrinsèquement de meilleures performances avec Clojure si vous êtes dans un paramètre simultané sur une grande machine, car Clojure ne repose pas sur le passage de messages et donc la communication entre les threads peut être beaucoup plus efficace.
Si vous voulez dire distribué (c'est-à-dire que de nombreuses machines différentes partagent le travail sur un réseau qui fonctionnent efficacement en tant que processus isolés), je dirais qu'Erlang est la solution la plus naturelle:
- Le style de passage de messages immuable et sans partage d'Erlang vous oblige à écrire du code d'une manière qui peut être distribuée. Ainsi, Erlang idiomatique automatiquement peut être distribué sur plusieurs machines et exécuté dans un cadre distribué et tolérant aux pannes.
- Erlang est donc très bien optimisé pour ce cas d'utilisation, ce serait donc le choix naturel et serait certainement le plus rapide à travailler.
- Clojure pourrait également le faire, mais vous devrez faire beaucoup plus de travail vous-même (c'est-à-dire que vous auriez besoin d'implémenter ou de choisir une forme de cadre informatique distribué) - Clojure ne propose pas actuellement un tel cadre par défaut.
À long terme, j'espère que Clojure développera un cadre informatique distribué qui correspond à Erlang - alors vous pourrez avoir le meilleur des deux mondes!
Clojure fonctionne LISP sur la JVM Java. Erlang est conçu dès le départ pour être hautement tolérant aux pannes et simultané.
Je crois que la tâche est réalisable avec l'une ou l'autre de ces langues et bien d'autres encore. Votre expérience dépendra de votre compréhension du problème et de votre connaissance de la langue. Si vous êtes nouveau dans les deux, je dirais que le problème sera difficile, peu importe celui que vous choisissez.
Avez-vous pensé à quelque chose comme Lucene/Solr? C'est un excellent logiciel pour indexer et rechercher des documents. Je ne sais pas ce que le "recoupement" signifie pour votre contexte, mais cela pourrait être une bonne solution à considérer.
Mon approche serait d'écrire un test simple dans chaque langue et de tester les performances de chacune. Les deux langages sont quelque peu différents des langages de style C et si vous n'y êtes pas habitué (et que vous n'avez pas d'équipe habituée), vous risquez de vous retrouver avec un cauchemar de maintenance.
Je chercherais également à utiliser quelque chose comme Groovy 1.8. Groovy inclut désormais des GPars pour permettre le calcul parallèle. La manipulation de chaînes et de fichiers dans Groovy est en effet très facile.