Quels sont les facteurs à considérer lors du choix d'un SGBD multimodèle? (OrientDB vs ArangoDB)

Avertissement: Je ne recommande plus OrientDB, voir mes commentaires ci-dessous.

je peux fournir une opinion légèrement moins biaisée, ayant utilisé à la fois ArangoDB et OrientDB. C'est toujours biaisé car je suis l'auteur du noeud D'OrientDB.js pilote - oriento mais je n'ai pas d'intérêt direct dans l'entreprise ou le produit, J'ai juste nécessairement utilisé OrientDB plus.

ArangoDB et OrientDB sont le ciblage d'un marché analogue et ont beaucoup de similitudes:

1. les deux sont multi-modèles, vous pouvez les utiliser pour stocker des documents, des graphiques et des clés / valeurs simples.
2. les deux ont un soutien pour Gremlin, mais il est fermement un citoyen de deuxième classe par rapport à leurs propres langues d'interrogation préférées.
3. les deux prennent en charge les "procédures stockées" côté serveur en JavaScript. Dans les deux systèmes, cela se fait via une API JavaScript légèrement moins idiomatique., mais celui D'ArangoDB est bien meilleur. Ceci est en train d'être corrigé dans une prochaine version D'OrientDB.
4. tous deux offrent des API REST, tous deux visent à être utilisables en tant que "serveur API" via les gestionnaires de requêtes JavaScript. C'est beaucoup plus pratique à ArangoDB qu'à OrientDB.
5. les deux sont distribués sous une licence permissive.
6. les deux sont acides et ont un support de transaction, mais dans les deux les transactions sont des opérations Côté Serveur - elles sont plus comme des lots atomiques de commandes plutôt que les types de transactions auxquels vous pourriez être habitué dans un SGBDR traditionnel.

Cependant, il y a beaucoup de différences:

1. ArangoDB n'a pas de concept de "liens", qui sont une fonctionnalité très utile dans OrientDB. Ils permettent des relations unidirectionnelles (comme un hyperlien sur le web), sans passer par les bords.
2. ArangoDB est écrit en C++ (et JavaScript), alors que L'OrientDB est écrit en Java. Tous les deux ont leur avantage:
   • être écrit en C++ signifie Qu'ArangoDB utilise V8, le même moteur JavaScript haute performance qui alimente le noeud.js et Google Chrome. Alors qu'être écrit en Java signifie que OrientDB utilise Nashorn, qui est encore rapide mais pas le plus rapide. Cela signifie Qu'ArangoDB peut offrir un plus grand niveau de compatibilité avec le noeud.js de l'écosystème par rapport à OrientDB.
   • être écrit en Java signifie que L'OrientDB tourne sur d'autres plateformes, y compris par exemple Raspberry PI. Il a également cela signifie Qu'OrientDB peut tirer parti d'un grand nombre d'autres technologies écrites en Java, par exemple OrientDB a un superbe support de recherche Texte intégral / géospatial via Lucene, qui n'est pas disponible pour ArangoDB.
3. OrientDB utilise un dialecte de SQL comme langage de requête, alors Qu'ArangoDB utilise son propre langage personnalisé appelé AQL. En théorie, AQL est mieux parce qu'il est conçu explicitement pour le problème, dans la pratique, bien qu'il se sent tout à fait similaire à SQL, mais avec des mots-clés différents, et est encore un autre langage à apprendre alors que L'implémentation D'OrientDB se sent beaucoup plus à l'aise si vous êtes habitué au SQL. SQL est déclaratif alors QU'AQL est impératif-YMMV ici.
4. ArangoDB est une base de données" principalement mémoire", qui fonctionne le mieux lorsque la plupart de vos données correspondent à la mémoire vive. Cela peut ou non convenir à vos besoins. OrientDB n'a pas cette restriction (mais aime aussi la RAM).
5. OrientDB est entièrement orienté objet - il supporte les classes avec les propriétés et l'héritage. Cela est exceptionnellement utile car cela signifie que votre structure de base de données peut mapper 1-1 à votre structure d'application, sans avoir besoin de hacks laids comme ActiveRecord. ArangoDB supporte quelque chose d'assez similaire via les modèles dans Foxx, mais c'est plus comme un addon optionnel plutôt qu'une partie centrale du fonctionnement de la base de données.
6. ArangoDB offre beaucoup de flexibilité via Foxx, mais il n'a pas été conçu par des personnes ayant des arrière-plans js côté serveur forts et réinvente le roue de beaucoup de temps. Plutôt que de tirer parti de cadres comme express pour leur traitement des requêtes, ils ont créé leur propre clone de Sinatra, ce qui, bien sûr, le rend presque identique à express (express est aussi un clone Sinatra), mais subtilement différent, et signifie qu'aucun middleware ou plugin d'express ne peut être réutilisé. De même, ils intègrent V8, mais pas libuv, ce qui signifie qu'ils n'offrent pas les mêmes API non bloquantes que le noeud.js et donc les utilisateurs ne peuvent pas être vous êtes sûr qu'un module de la NGP fonctionnera là-bas. Cela signifie que les applications non triviales ne peuvent pas utiliser ArangoDB comme un remplacement pour le backend, ce qui nie une grande partie de l'utilité potentielle de Foxx.
7. OrientDB supporte le niveau de propriété de première classe et les indices de niveau de base de données. Vous pouvez interroger et insérer dans des index spécifiques directement pour une efficacité maximale. Je n'ai pas vu de soutien pour ça à ArangoDB.
8. OrientDB est l'option la plus établie, avec de nombreux le profil de l'utilisateur. ArangoDB est plus récent, moins connu, mais en croissance rapide.
9. la documentation D'ArangoDB est excellente, et ils offrent des pilotes officiels pour de nombreux langages de programmation différents. La documentation d'OrientDB n'est pas tout à fait aussi bonne, et bien qu'il y ait des pilotes pour la plupart des plateformes, ils sont alimentés par la communauté et ne sont donc pas toujours à jour avec les fonctionnalités d'OrientDB.
10. si vous utilisez Java( ou un pont Java), vous pouvez intégrer OrientDB directement dans votre application, en tant que Bibliothèque. Ce cas d'utilisation n'est pas possible à ArangoDB.
11. OrientDB a le concept d'utilisateurs et de rôles, ainsi que Enregistrer Le Niveau De Sécurité. C'est peut-être un truc de tueur pour toi, c'est pour moi. Il prend également en charge l'authentification par token, de sorte qu'il est possible d'utiliser OrientDB comme principal moyen d'autoriser/authentifier les utilisateurs. OrientDB intègre également LDAP. En revanche, ArangoDB ne supporte qu'un très simple auth option.

Les deux systèmes ont leurs propres avantages, donc choisir entre eux revient à votre propre situation:

• si vous construisez une petite application, et que vous êtes un développeur web optimisant pour la productivité du développeur, il sera probablement plus facile de démarrer rapidement avec ArangoDB.

• si vous construisez une application plus grande, qui pourrait potentiellement stocker de nombreux gigaoctets ou téraoctets de données, ou avoir plusieurs milliers d'utilisateurs concurrents, ou ont des cas d'utilisation "enterprise", ou ont besoin de contrôles de sécurité précis, OrientDB est celui qui vous convient.

• si vous stockez des données RDF ou des données liées structurées de manière similaire, choisissez OrientDB.

• si vous utilisez Java, choisissez OrientDB.

Remarque: C'est (mon avis) à l'état de jouer aujourd'hui, les choses changent rapidement et je ne voudrais pas sous-estimez l'impitoyable efficacité de L'équipe géniale derrière ArangoDB, je pense juste que ce n'est pas tout à fait là!--11-->encore:)

Charles pic (en codemix.com)