database orientdb arangodb foundationdb multi-model-database

database - ¿Qué factores a considerar al elegir un DBMS multimodelo?(OrientDB vs ArangoDB)



foundationdb multi-model-database (1)

Busco sumergir mis manos en el mundo de los DBMS multimodelos, no tengo ningún caso de uso en particular, solo quiero comenzar a aprender.

Encuentro que hay dos prominentes: OrientDB vs ArangoDB , pero no fue capaz de encontrar ninguna comparación meaningful , sin unopinionated entre ellos. ¿Alguien puede arrojar algo de luz sobre la diferencia en las características entre las dos, y cualquier advertencia al usar una sobre la otra? Si aprendo uno, ¿podré pasar fácilmente al otro?

(También etiqueté FoundationDB , pero es propiedad y probablemente no lo considere)

Esta pregunta solicita una comparación general entre OrientDB y ArangoDB para alguien que busca aprender sobre el DBMS multimodelo, y no una respuesta valorada sobre cuál es mejor.

Descargo de responsabilidad: ya no recomendaría OrientDB, vea mis comentarios a continuación.

Puedo proporcionar una opinión ligeramente menos sesgada, ya que he utilizado tanto ArangoDB como OrientDB. Sigue siendo parcial ya que soy el autor del controlador node.js de oriento pero no tengo un gran interés en ninguna de las compañías o productos, simplemente he utilizado OrientDB más .

ArangoDB y OrientDB apuntan a un mercado similar y tienen muchas similitudes:

  1. Ambos son multimodelos, puede usarlos para almacenar documentos, gráficos y claves / valores simples.
  2. Ambos tienen soporte para Gremlin , pero es firmemente un ciudadano de segunda clase en comparación con sus propios lenguajes de consulta preferidos.
  3. Ambos soportan "procedimientos almacenados" del lado del servidor en JavaScript. En ambos sistemas, esto viene a través de una API de JavaScript un poco menos que idiomática, aunque ArangoDB es mucho mejor. Esto se está arreglando en una próxima versión de OrientDB.
  4. Ambos ofrecen API de REST, y ambos pretenden ser utilizables como un "Servidor de API" a través de los controladores de solicitud de JavaScript. Esto es mucho más práctico en ArangoDB que en OrientDB.
  5. Ambos se distribuyen bajo una licencia permisiva.
  6. Ambos son ACID y tienen soporte para transacciones, pero en ambas transacciones son operaciones del lado del servidor, son más como lotes atómicos de comandos en lugar de los tipos de transacciones a las que podría estar acostumbrado en un RDBMS tradicional.

Sin embargo, hay muchas diferencias:

  1. ArangoDB no tiene el concepto de "enlaces", que son una característica muy útil en OrientDB. Permiten relaciones unidireccionales (como un hipervínculo en la web), sin la sobrecarga de bordes.
  2. ArangoDB está escrito en C ++ (y JavaScript), mientras que OrientDB está escrito en Java. Ambos tienen sus ventajas:
    • Estar escrito en C ++ significa que ArangoDB usa V8, el mismo motor de JavaScript de alto rendimiento que alimenta a node.js y Google Chrome. Mientras que estar escrito en Java significa que OrientDB usa Nashorn, que sigue siendo rápido pero no el más rápido. Esto significa que ArangoDB puede ofrecer un mayor nivel de compatibilidad con el ecosistema node.js en comparación con OrientDB.
    • Al estar escrito en Java, significa que OrientDB se ejecuta en más plataformas, incluyendo, por ejemplo, Raspberry PI. También significa que OrientDB puede aprovechar muchas otras tecnologías escritas en Java, por ejemplo, OrientDB tiene un excelente soporte de búsqueda de texto / geoespacial a través de Lucene, que no está disponible para ArangoDB.
  3. OrientDB usa un dialecto de SQL como su lenguaje de consulta, mientras que ArangoDB usa su propio lenguaje personalizado llamado AQL. En teoría, AQL es mejor porque está diseñado explícitamente para el problema, en la práctica, aunque se parece bastante a SQL pero con diferentes palabras clave, es otro idioma que aprender, mientras que la implementación de OrientDB se siente mucho más cómoda si está acostumbrado a SQL . SQL es declarativo, mientras que AQL es imperativo - YMMV aquí.
  4. ArangoDB es una base de datos "en su mayoría de memoria", funciona mejor cuando la mayoría de sus datos caben en la RAM. Esto puede o no ser adecuado para sus necesidades. OrientDB no tiene esta restricción (pero también ama a la RAM).
  5. OrientDB está totalmente orientado a objetos: admite clases con propiedades y herencia. Esto es excepcionalmente útil porque significa que la estructura de su base de datos puede mapear 1-1 a la estructura de su aplicación, sin necesidad de trucos feos como ActiveRecord. ArangoDB admite algo bastante similar a través de modelos en Foxx, pero es más como un complemento opcional en lugar de una parte central de cómo funciona la base de datos.
  6. ArangoDB ofrece mucha flexibilidad a través de Foxx , pero no ha sido diseñado por personas con sólidos fondos JS del lado del servidor y reinventa la rueda la mayor parte del tiempo. En lugar de utilizar frameworks como express para el manejo de sus solicitudes, crearon su propio clon de Sinatra , que por supuesto lo hace casi igual que express (express también es un clon de Sinatra), pero sutilmente diferente, y significa que ninguno de middleware de Express o Los complementos pueden ser reutilizados. Del mismo modo, incorporan V8, pero no libuv, lo que significa que no ofrecen las mismas API de no bloqueo que node.js y, por lo tanto, los usuarios no pueden estar seguros de si un módulo npm determinado funcionará allí. Esto significa que las aplicaciones no triviales no pueden usar ArangoDB como un reemplazo para el backend, lo que niega gran parte de la utilidad potencial de Foxx.
  7. OrientDB admite índices de nivel de base de datos y nivel de propiedad de primera clase. Puede consultar e insertar directamente en índices específicos para obtener la máxima eficiencia. No he visto soporte para esto en ArangoDB.
  8. OrientDB es la opción más establecida, con muchos usuarios de alto perfil. ArangoDB es más nuevo, menos conocido, pero está creciendo rápidamente.
  9. La documentación de ArangoDB es excelente y ofrecen controladores oficiales para muchos lenguajes de programación diferentes. La documentación de OrientDB no es tan buena, y si bien hay controladores para la mayoría de las plataformas, son compatibles con la comunidad y, por lo tanto, no siempre se mantienen actualizados con las funciones de vanguardia de OrientDB.
  10. Si está utilizando Java (o un puente de Java), puede incrustar OrientDB directamente en su aplicación, como una biblioteca. Este caso de uso no es posible en ArangoDB.
  11. OrientDB tiene el concepto de usuarios y roles, así como la seguridad de nivel de registro . Esto puede ser una característica asesina para ti, es para mí. También es compatible con la autenticación basada en token, por lo que es posible usar OrientDB como su medio principal para autorizar / autenticar a los usuarios. OrientDB también tiene integración LDAP. En contraste, ArangoDB solo admite una opción de autenticación muy simple.

Ambos sistemas tienen sus propias ventajas, por lo que elegir entre ellos se reduce a su propia situación:

  • Si está creando una aplicación pequeña y es un desarrollador web que optimiza la productividad del desarrollador, probablemente será más fácil ponerse en marcha rápidamente con ArangoDB.

  • Si está creando una aplicación más grande, que potencialmente podría almacenar muchos gigabytes o terabytes de datos, o tener muchos miles de usuarios concurrentes, o tener casos de uso "empresariales", o necesitar controles de seguridad detallados, OrientDB es el indicado para usted.

  • Si está almacenando RDF o datos vinculados estructurados de manera similar, elija OrientDB.

  • Si está utilizando Java, simplemente elija OrientDB.

Nota: Esta es ( mi opinión de ) el estado de juego de hoy , las cosas cambian rápidamente y no subestimaría la despiadada eficiencia del increíble equipo detrás de ArangoDB. Creo que todavía no está del todo :)

Charles Pick (codemix.com)