Il existe de nombreux magasins de données écrits à Erlang, par exemple Riak, Dynomite, Couchdb, Scalaris, ai-je manqué?
Je sais que Java et C / C ++ ont également été utilisés pour écrire des données de données (Cassandra, Hypertable, etc.), mais ont été écrits de banque de données dans toutes les autres langues fonctionnelles telles que F #, Scala, Haskell, Clojure, etc.? La raison pour laquelle je pose cette question (et de nombreuses autres questions de programmation fonctionnelle et d'erlang) est d'évaluer la faisabilité des langages de programmation fonctionnelle pour des projets réels mondiaux.
En tant que note latérale, il m'a été signalé que je veux dire le langage de mise en œuvre réel du DataStore lui-même, et non la langue du client d'accéder à la banque de données (c.-à-d. VIA ODBC).
4 Réponses :
Votre question me puzzle un peu. Vous posez des questions sur DataStores écrites dans une variété de langues. En règle générale, lorsque je programmez, je cherche une bibliothèque ou une API pour obtenir et mettre des données de et vers le magasin de données dans la langue choisie. Ce que le magasin de données sous-jacent est écrit dans (s'il est écrit dans n'importe quoi, certains DataStores ne sont plus que des dispositions de fichier) Je m'en fiche.
Et sur cette base, un peu de googling augmentera les bibliothèques Haskell-To-ODBC, et j'imagine que les autres langues auront des installations similaires. Je n'ai aucune connaissance de celles-ci, alors ne commenterez pas leur aptitude à des projets.
Oui, vous avez raison, je ne l'ai pas expliqué aussi clairement. Je voulais dire que le magasin de données "sous-jacent" comme vous l'avez souligné.
En outre, un point intéressant que vous avez fait, quels datastores ne sont que des dispositions de fichier, comme je voudrais les évaluer?
Ah bon? Êtes-vous sûr que ce stockage de données d'application qui ne copie pas de données entre les processus d'application et la base de données n'a pas d'avantages? Performance? Dans ce cas, le magasin de données dans une langue spécifique a beaucoup de sens. L'ordinal intégré dB n'est pas une solution ici car la nécessité de la plaque de chaudière. Par exemple, c'est pourquoi la Mnésique à Erlang a un sens important dans certains cas, en particulier avec des "procédures stockées" indigènes et des transactions (distribution impliquée).
Brillant, je vais regarder dans ceux-ci. Merci
J'ai eu un bref reguage à ceux-ci. Spark semble être le plus gentil, mais a le pire site Web :) Faites-vous d'entre eux dans des paramètres en cluster?
@Zubair Merci pour le commentaire favorable sur Spark. C'est mon LISP personnel! À propos du site Web, ne disposez pas de suffisamment de ressources (tout le temps, de l'argent et du personnel) pour en créer un meilleur.
Dans un sens, vous avez déjà répondu à votre propre question. Les systèmes que vous mentionnez, et d'autres des commentaires,
À la première partie: oui. La Mnésique vient avec Erlang ;-)
Je mentionnerai simplement que Scala, par opposition aux autres langues que vous mentionnez, c'est principalement une langue orientée objet, qui s'intégrerait les caractéristiques linguistiques fonctionnelles. C'est Créateur l'a récemment appelé "post-fonctionnel".
Ok, alors je devrais probablement supprimer Scala de la liste si c'est surtout OO?
Dépend si vous demandez si SCALA peut construire un bon magasin de données où vous pouvez tirer parti de ses fonctions fonctionnelles (réponse = oui) ou s'il est pratique d'utiliser une approche fonctionnelle purement pour construire un magasin de données ( Réponse = Tu n'aurais probablement pas fonctionnel à 100% avec Scala; d'autres langues comme Haskell sont de meilleurs cas de test).