Quand dois-je utiliser Datomic ?

Question

Je suis intrigué par le service de base de données Datomic, mais je ne suis pas sûr qu'il réponde aux besoins des projets sur lesquels je travaille. Quand Datomic est-il un bon choix, et quand doit-il être évité ?

Answer 1

Avec la condition que je n'ai pas utilisé Datomic dans la production, j'ai pensé vous donner une réponse.

Avantages

1. Datalog requêtes sont puissant (plus que les non-récursive SQL) et très experssive.
2. Les requêtes peuvent être écrites avec Clojure structures de données, et ce n'est PAS une faiblesse de la DSL à l'instar de nombreux SQL bibliothèques qui vous permettent de requête avec des structures de données.
3. Il est immuable, de sorte que vous obtenez les avantages de l'immutabilité vous donne en Clojure/d'autres langues ainsi un. Cela vous permet également de stocker, tout en économisant sur les structures, tous les derniers faits dans votre base de données-ce qui est TRÈS utile pour l'audit & plus

Inconvénients

1. Il peut être lente, comme Datalog est juste va être plus lent que l'équivalent de SQL (en supposant un équivalent SQL peut être écrit).
2. Si vous écrivez BEAUCOUP, vous pourriez peut-être besoin de s'inquiéter à propos de la seule transactor dépassé par les événements. Cela semble peu probable pour la plupart des cas, mais c'est quelque chose à penser (vous pourriez faire une sorte d'éclat, mais, et probablement sauver de vous-même; mais ce n'est pas un DB pour, par exemple, l'entreposage des données de tiques).
3. C'est un peu difficile à prendre en main, et c'est cher, et l'octroi de licences et de prix rend difficile l'utilisation d'une instance hébergée avec elle: vous aurez besoin de traiter avec sysadminning vous-même au lieu d'utiliser quelque chose comme Postgres sur Heroku ou Mongo à MongoHQ

Je suis sûr que je suis pas certains de chaque côté, et bien que j'ai 3 répertoriées sous les inconvénients, je pense que les avantages l'emportent sur les circonstances où les inconvénients de ne pas empêcher son utilisation. Le prix est sans doute celle qui permettra d'éviter qu'elle soit utilisée dans la plupart des petits projets (que vous pouvez vous attendre à survivre à l'1 an d'essai gratuit).

c.f. ce court post décrivant Datomic simplement pour plus d'information.

L'expressivité (c.f. Datalog) et l'immuabilité sont impressionnantes. C'est TELLEMENT amusant de travailler avec Dataomic à cet égard, et vous pouvez dire, c'est puissant, simplement en utilisant un peu.

Answer 2

Pour compléter les réponses ci-dessus, j'aimerais souligner que l'immuabilité et la capacité de se souvenir du passé ne sont pas des "caractéristiques magiques" adaptées à quelques cas particuliers comme l'audit. Il s'agit d'une approche qui présente plusieurs avantages profonds par rapport aux bases de données à "cellules mutables" (qui représentent 99 % des bases de données actuelles). Stuart Halloway en fait une belle démonstration dans cette vidéo : la disparité d'impédance est de notre faute. .

À mon avis, cette approche est fondamentalement plus saine d'un point de vue conceptuel. Après l'avoir utilisé pendant plusieurs mois, je ne considère pas que Datomic possède des pouvoirs magiques sophistiqués, mais plutôt un paradigme plus naturel sans certains des gros problèmes que les autres ont.

Voici quelques caractéristiques de Datomic que je trouve intéressantes, dont la plupart sont rendues possibles par l'immuabilité :

1. Comme la lecture n'est pas à distance, vous n'avez pas à concevoir vos requêtes comme une expédition sur le fil. En particulier, vous pouvez séparer les préoccupations en plusieurs requêtes (par exemple, trouver les entités qui sont l'entrée de ma requête - répondre à une question commerciale sur ces entités - récupérer les données associées pour présenter le résultat).
2. le schéma est très flexible, sans sacrifier la puissance d'interrogation
3. il est confortable d'avoir vos requêtes intégrées dans le langage de programmation de votre application
4. l'API Entity vous apporte les bons côtés des ORMs
5. le langage de requête est programmable et dispose de primitives d'abstraction et de réutilisation (règles, prédicats, fonctions de base de données)
6. performances : les auteurs ne gênent que les autres auteurs, et personne ne gêne les lecteurs. De plus, il y a beaucoup de mise en cache.
7. ... et oui, quelques superpouvoirs comme le voyage dans le passé, l'écriture spéculative ou le branchement de la réalité.

Concernant le moment où no d'utiliser Datomic, voici les contraintes et limitations actuelles que je vois :

1. vous devez être sur la JVM (il existe également une API REST, mais vous perdez la plupart des avantages IMO)
2. ne convient pas à l'échelle d'écriture, ni aux gros volumes de données
3. ne seront pas spécialement intégrés dans les frameworks, par exemple, vous ne trouverez pas actuellement de bibliothèque qui génère des points de terminaison CRUD REST à partir d'un schéma Datomic.
4. il s'agit d'une base de données commerciale
5. La lecture s'effectuant dans le processus d'application (le "pair"), vous devez vous assurer que le pair dispose de suffisamment de mémoire pour contenir toutes les données qu'il doit parcourir dans une requête.

Donc ma réponse très vague et informelle serait que Datomic est une bonne solution pour la plupart des applications non triviales pour lesquelles la charge d'écriture est raisonnable et pour lesquelles la licence et le fait d'être sur la JVM ne posent pas de problème. .

Par analogie, vous pouvez vous poser la même question pour Git par rapport aux autres systèmes de contrôle de version qui ne sont pas basés sur l'immuabilité.

Answer 3

Il est important, lorsque vous vous demandez si Datomic convient à votre application, de réfléchir à la forme des données que vous allez stocker et interroger. Comme les faits Datomic sont en fait très similaires aux triples RDF (+ notion de temps de première classe), ils se prêtent très bien à la modélisation de relations complexes (données graphiques liées), ce qui est souvent fastidieux avec les bases de données SQL traditionnelles. J'ai trouvé que cet aspect était l'un des plus attrayants et importants pour moi, il fonctionnait vraiment bien, même si ce n'est bien sûr pas quelque chose d'exclusif à Datomic, car il existe de nombreuses autres offres de haute qualité pour les bases de données de graphes, il faut mentionner Neo4J quand on parle de solutions basées sur la JVM.
En ce qui concerne le schéma Datomic, je pense qu'il constitue un juste équilibre entre flexibilité et stabilité.

Answer 4

Juste pour ajouter provisoirement aux autres réponses :

Il est probablement juste de dire que datomic présente le meilleur cadre conceptuel pour un magasin de données interrogeable parmi toutes les autres options actuelles, tout en étant partiellement extensible et pas exceptionnellement performant.

Je dis seulement partiellement extensible, car les requêtes doivent tenir dans la RAM du pair ou échouer. Et pas exceptionnellement performant, car les moteurs SQL de premier ordre peuvent optimiser les requêtes pour qu'elles tiennent dans la mémoire grâce à des plans d'exécution sophistiqués, ce que je n'ai pas encore vu mentionné comme une caractéristique de Datomic ; le découplage de Datomic entre les transactions et les requêtes pourrait, dans l'ensemble, compenser cette caractéristique.

Cependant, contrairement à de nombreux moteurs NoSQL, les transactions sont un citoyen de première classe, ce qui le place au même niveau que les systèmes SGBDR à cet égard essentiel.

Pour les applications où les données sont lues plus souvent qu'elles ne sont écrites, où des transactions sont nécessaires, où les requêtes tiennent toujours dans la mémoire ou où la mémoire est très bon marché, et où la taille globale des données accumulées n'est pas trop grand En revanche, il pourrait s'agir d'une victoire lorsqu'un produit exclusivement commercial peut être offert à ceux qui sont prêts à adopter le nouveau cadre conceptuel impliqué dans l'API.