ArangoDB en Es

Papel blanco:
¿Qué es una base de datos multimodelo y

por qué utilizarla?
Un libro blanco de ArangoDB (abril de 2020)

¿Qué es una base de datos multimodelo y por
qué utilizarla?
Un libro blanco de ArangoDB (abril de 2020)
La creación de aplicaciones de software se parece mucho a la vida misma. Nunca se sabe lo que podría
pasar mañana o dentro de 2 meses. Nos comprometemos con las opciones tecnológicas basadas en
suposiciones sobre el futuro.
La elección de la base de datos adecuada para una aplicación está llena de dificultades, ya que la elección de la
base de datos implica el compromiso con un modelo en particular por adelantado, que puede invalidarse
fácilmente por requisitos cambiantes impredecibles en el futuro. Tomar la decisión correcta implica priorizar
las capacidades y hacer concesiones en función de lo que sabe en ese momento, lo que cree que podría
suceder, las habilidades y los recursos que tiene en ese momento y mucha suerte.
Si su caso de uso requiere capacidades relacionales, de documentos y de gráficos, ¿elige tres tipos
diferentes de tecnologías de bases de datos o elige la que cree que es la más dominante? A
menudo, los compromisos conducen a múltiples tipos de bases de datos en el mismo proyecto, lo
que resulta en fricción operativa, inconsistencia de datos, redundancia y latencia.
Elegir el modelo de base de datos incorrecto puede resultar muy costoso. ¿Y si pudiera elegir una base de datos a
prueba de futuro? Las bases de datos nativas de varios modelos lo aíslan de los cambios de requisitos y del bloqueo del
modelo de datos.
Este documento técnico explica qué son las bases de datos multimodelo, por qué tiene sentido usarlas,
e ilustra cómo aplicarlos utilizando un caso de uso de gestión de flotas de aeronaves.
Copyright ArangoDB C ª.
¿Qué es una base de datos multimodelo y por qué utilizarla?
Libro blanco de ArangoDB - Abril de 2020
Tabla de contenido
1 ¿Qué es una base de datos nativa multimodelo? 3
2 ¿Por qué multimodelo nativo? 4
3 Modelado de datos con bases de datos nativas de múltiples modelos 6
3.1 Mantenimiento de la flota de aeronaves: un estudio de caso 6
3.1.1 Un modelo de datos para una flota de aeronaves 7
3.1.2 Consultas para el mantenimiento de la flota de aeronaves 8
3.1.3 Uso de consultas de modelos múltiples 12
3.2 Lecciones aprendidas para el modelado de datos 13
4 Otros casos de uso para bases de datos nativas de modelos múltiples 14
2
Copyright ArangoDB Inc.
1 ¿Qué es una base de datos nativa multimodelo?
La persistencia políglota se está convirtiendo en la nueva normalidad [zdnet 2020], desde la explosión de las bases
de datos NoSQL de modelo único en 2010, sin embargo, la proliferación de diferentes tipos de bases de datos y las
complejas orquestaciones necesarias para mantener sincronizados los sistemas de sistemas pueden volverse
extremadamente complejas, onerosas y costosas. Por el contrario, las bases de datos nativas de modelos múltiples,
comoArangoDB, permite la persistencia políglota en el mismo almacén de datos. Esto elimina la compleja
orquestación de datos, la transformación de datos y la diversidad del conocimiento de la base de datos necesarios
para respaldar la persistencia políglota.
Las bases de datos nativas de múltiples modelos, como ArangoDB, admiten múltiples modelos de datos (p. Ej., Clave-
valor, documento, gráfico, SQL) sin problemas (al mismo tiempo) en un sistema central utilizando un único lenguaje
de consulta unificado. Esta definición excluye las bases de datos que admiten un modelo a la vez y deben cambiarse
entre modelos de datos. También excluye las bases de datos que utilizan vistas para crear fachadas para diferentes
modelos de datos (multimodelo en capas). En una verdadera base de datos multimodelo, los diferentes modelos
coexisten como ciudadanos de primera clase y son interoperables en un lenguaje de consulta multimodelo.
Entonces, ¿qué es una base de datos nativa de múltiples modelos?
En resumen, una base de datos nativa de múltiples modelos tiene un núcleo, un lenguaje de consulta, pero múltiples
modelos de datos. Una base de datos nativa de varios modelos es una combinación de varios almacenes de datos en
un sistema. Puede almacenar datos como pares clave / valor, gráficos o documentos y puede acceder a sus datos sin
problemas con un lenguaje de consulta declarativo, combinando diferentes modelos en una sola consulta. Puede
crear aplicaciones de alto rendimiento y escalar horizontalmente utilizando todos los modelos de datos en toda su
extensión.
Figura 1: Un modelo múltiple nativo tiene varios modelos de datos coexistentes a los que se accede a través de un lenguaje de consulta.
3
2 ¿Por qué multimodelo nativo?
Durante la última década, los arquitectos de software se han dado cuenta de los beneficios de aprovechar una
variedad de modelos de datos para diferentes partes de la capa de persistencia de los proyectos de software. Como
resultado: la persistencia políglota se ha vuelto cada vez más popular.
Sin embargo, las aplicaciones anteriores de la persistencia políglota combinaban múltiples bases de datos de un solo
modelo en un sistema de software. En este enfoque anterior, usaría una base de datos relacional para conservar datos
tabulares estructurados; un almacén de documentos para datos de tipo objeto no estructurados; un almacén de clave /
valor para una tabla hash; y una base de datos de gráficos para datos referenciales altamente vinculados. La combinación
de múltiples bases de datos de un solo modelo en el mismo proyecto, a menudo conduce a fricciones operativas
(implementación más complicada, actualizaciones más frecuentes), así como a problemas de duplicación y consistencia de
datos.
Una única base de datos nativa de varios modelos proporciona una solución superior por las siguientes tres
razones:
En primer lugar, la mayoría de los casos de uso requieren diversos modelos de datos y la elección de un modelo de
datos único en particular hace que fuerce el ajuste de los otros modelos de datos en el modelo elegido o hace que
use varias bases de datos acompañadas de una lógica de orquestación cada vez más bizantina, altas latencias y
problemas de coherencia de datos. Un modelo múltiple le permite evitar hacer esto.
En segundo lugar, los requisitos cambian con el tiempo y las bases de datos de modelos múltiples le permiten
adaptarse fácilmente a estos cambios sin tener que "extraer y reemplazar" las bases de datos.
En tercer lugar, La proliferación de bases de datos dentro de las empresas es costosa, puede requerir habilidades
especializadas costosas y orquestaciones y transformaciones complejas para mantener los datos sincronizados y
consistentes. Las bases de datos de modelos múltiples permiten a las empresas reemplazar varios sistemas, evitando al
mismo tiempo la orquestación y transformación externas.
4
Figura 2: tablas, documentos, gráficos y pares clave / valor: diferentes modelos de datos.
¿Cómo funcionan las bases de datos nativas de modelos múltiples? ¿Cómo coexisten a la perfección los pares clave-valor, los
documentos y los gráficos? La respuesta es muy simple.
Los documentos de una colección de documentos suelen tener una clave principal única que codifica la identidad
del documento, lo que convierte un almacén de documentos en un almacén de clave / valor, donde las claves son
cadenas y los valores son documentos JSON. El hecho de que los valores sean JSON no impone una penalización de
rendimiento, pero ofrece una buena cantidad de flexibilidad.
El modelo de datos de gráficos se puede implementar almacenando un documento JSON para cada
vértice y un documento JSON para cada borde. Los bordes se mantienen en colecciones de bordes
especiales que aseguran que cada borde tenga _de y _a atributos que hacen referencia a los vértices
inicial y final del borde, así como a la dirección de una relación.
Habiendo unificado los datos para los tres modelos de datos de esta manera, queda por implementar un lenguaje de
consulta común que permita a los usuarios expresar consultas de documentos, búsquedas clave / valor, “consultas
gráficas” y combinaciones arbitrarias de estos. Por "consultas gráficas", me refiero a consultas que involucran
características de conectividad particulares que vienen de los bordes, p. Ej.
● Gráficos recorridos
● Ruta más corta
● y coincidencia de patrones
Una consulta de Coincidencia de patrones en una base de datos de varios modelos identifica todas las rutas
que siguen una combinación arbitraria y compleja de condiciones. Estas condiciones se componen de
condiciones en cada documento o borde y condiciones en el diseño general creado por estos
5
objetos. Después de toda la teoría, profundicemos en un caso de uso real de Gestión de flotas de aeronaves que
incluye aspectos de modelado de datos y consultas reales de modelos múltiples.
3 Modelado de datos con bases de datos nativas de múltiples modelos
3.1 Mantenimiento de la flota de aeronaves: un estudio de caso
Un área en la que la flexibilidad de una base de datos multimodelo nativa es extremadamente adecuada es
la gestión de grandes cantidades de datos jerárquicos, como en una flota de aviones.
Una flota de aviones consta de varios tipos de aviones, y un avión típico se compone de varios millones
de piezas: desde conjuntos y subconjuntos hasta componentes individuales. Uno puede pensar en un
avión como una colección de partes que vuelan en formación donde la "formación" es una
jerarquía de "elementos". Para organizar el mantenimiento de una flota de aeronaves, es necesario gestionar una
multitud de datos en diferentes niveles de esta jerarquía.
Las piezas y componentes tienen:
● nombres
● números seriales
● información del fabricante
● intervalos de mantenimiento
● fechas de mantenimiento
● información sobre subcontratistas
● enlaces a manuales y documentación
● personas de contacto
● información sobre garantía y contrato de servicio, por nombrar solo algunos.
Estos datos para cada artículo se adjuntan a nodos en la jerarquía de la lista de materiales de una aeronave. Es
importante tener en cuenta que puede haber tres jerarquías de componentes para una aeronave: según diseño,
construcción y mantenimiento.
En este artículo nos centramos en la jerarquía de componentes de una aeronave tal como se mantiene. La
diferencia es que en una jerarquía tal como se mantiene, vemos la aeronave en términos de componentes
reemplazables y reparables. Además, la configuración de la aeronave y, por lo tanto, la jerarquía cambiará
con el tiempo a medida que se reemplacen o reacondicionan piezas en la aeronave individual.
Se realiza un seguimiento de estos datos para proporcionar información y responder preguntas. Las
preguntas pueden incluir, entre otras, los siguientes ejemplos:
6
● ¿Cuáles son todos los componentes de una pieza determinada?

● Dada una pieza (rota), ¿cuál es el componente más pequeño de la aeronave que contiene
la pieza y para el que existe un procedimiento de mantenimiento? ¿Qué partes de este
● avión necesitan mantenimiento la próxima semana?
3.1.1 Un modelo de datos para una flota de aeronaves
¿Cómo modelamos los datos sobre nuestra flota de aviones utilizando una base de datos de modelos múltiples?
Una base de datos de modelos múltiples proporciona varias formas de lograr esto, sin embargo, un enfoque
que es muy natural y ofrece un rendimiento de consulta rápido es utilizar un documento JSON para contener
los datos de cada elemento en la jerarquía y representar las relaciones jerárquicas entre el artículo se
documenta como un gráfico. La naturaleza recursiva y libre de esquemas de los documentos JSON nos
permite almacenar información arbitraria sobre cada elemento, por lo queno es asi
importa que los datos que se administran para una aeronave, un motor o un sujetador pequeño sean completamente
diferentes.
Un gráfico es una excelente representación para modelar la estructura jerárquica (partonomía) de una flota de
aeronaves para aeronaves individuales en la flota, a través de la lista de materiales de cada aeronave hasta partes
individuales. En este modelo, la flota de aeronaves está representada por un vértice que tiene un borde en cada
vértice de la aeronave. Cada vértice de la aeronave, a su vez, tiene bordes para cada vértice de componente de
nivel superior en la lista de materiales. En la lista de materiales, los vértices del ensamblaje de componentes tienen
bordes a los subcomponentes de los que están hechos, y así sucesivamente, a partes individuales que forman las
hojas del árbol (Ver figura 3).
7
Figura 3: Un árbol estructurado en gráficos de documentos de elementos.
¿Cómo se deben estructurar las colecciones de documentos? Podríamos asignar todos los documentos
de artículos en una sola colección o definir múltiples colecciones para diferentes clases de artículos o
grupos de artículos similares. Para el gráfico de la lista de materiales, no importa si los artículos están
organizados en una colección grande o en varias colecciones de artículos similares. Sin embargo, cuando
considera la indexación secundaria, la organización de los elementos en colecciones es importante.
Varias colecciones que contienen agrupaciones o clases similares de documentos de elementos son
mejores para la indexación y darán como resultado consultas más eficaces para este caso de uso.
3.1.2 Consultas para el mantenimiento de la flota de aeronaves
¿Cuáles son las preguntas típicas que podríamos hacer sobre los datos y cómo consultamos un árbol de
documentos estructurado en gráficos para responderlas? Esta sección describe preguntas típicas y
ejemplos de código sobre cómo responder estas preguntas mediante consultas escritas en elLenguaje de
consulta ArangoDB (AQL).
● ¿Cuáles son todas las partes constituyentes de un componente dado?
8
Encontrar las subpartes de un componente en particular implica comenzar en un vértice particular (el
componente dado) en el gráfico y navegar a todos los vértices "debajo" de ese vértice; todos los vértices que se
pueden alcanzar siguiendo los bordes en la dirección hacia adelante son los sub -partes del componente dado.
Esta navegación se conoce como recorrido de gráficos, que es una característica típica de las consultas de
gráficos.
Figura 4: Encontrar todas las partes que forman parte de un componente.
A continuación se muestra un ejemplo de esta consulta en AQL (lenguaje de consulta ArangoDB). Encuentra todos los
vértices a los que se puede llegar desde "componentes / Engine765 ”Haciendo un recorrido de gráfico en el subárbol
debajo de ese vértice limitado a una profundidad de 4 pasos.
POR
parte EN
REGRESO 1..4
parte SALIDA "componentes / motor765 " GRAFICO "FleetGraph "
La consulta de ejemplo ilustra el uso de gráficos con nombre en AQL, donde se pueden especificar
recorridos sin tener que enumerar las colecciones de bordes específicas en el recorrido.
Un gráfico con nombre es una agrupación lógica de aristas y vértices que comprende un gráfico y se
define en ArangoDB especificando un nombre y enumerando las colecciones de aristas y las
colecciones de vértices conectadas del gráfico. El recorrido solo necesita el nombre del gráfico "
FleetGraph", el vértice inicial, ySALIDA para la dirección de los bordes a seguir, sin tener que especificar
explícitamente las colecciones de bordes a seguir. Puede especificar adicionalesopcionespara controlar
y restringir recorridos.
9
● Dada una pieza (rota), busque el procedimiento de mantenimiento para la pieza o para las piezas que
contienen esa pieza.
Tiene una pieza individual que está rota y está buscando un procedimiento de reparación. Puede existir un
procedimiento de reparación directamente para la pieza o puede estar incluido en los procedimientos de
reparación de la jerarquía de la pieza principal por encima de la pieza individual. Lo que buscamos es el
componente más pequeño de la aeronave que contiene la pieza y para el que existe un procedimiento de
mantenimiento.
En la lista de materiales con estructura de gráfico, esto implica comenzar en un vértice de la hoja que representa la parte
individual y buscar hacia arriba en el árbol hasta que se encuentra un componente que tiene un procedimiento de
mantenimiento al que se hace referencia en el documento JSON para el componente. Ésta es una consulta de gráfico típica
que implica un recorrido en el que se desconoce el número de pasos que quedan por recorrer.
priori. Este caso particular es relativamente fácil ya que al atravesar un árbol, siempre hay solo un borde
por encima de cada vértice.
Figura 5: Encontrar el componente más pequeño que se puede mantener.
La siguiente consulta AQL encuentra la ruta más corta de "piezas / Tornillo "A un vértice cuyoes
mantenible El atributo tiene el valor booleano verdadero, siguiendo los bordes en el "entrante
"Dirección:
POR
FILTRAR component.isMaintainable
componente == /cierto
EN 0..4 ENTRANTE "partes Tornillo56744 " GRAFICO "FleetGraph "
L
IMIT 1
REGRESO componente
10
Tenga en cuenta que aquí, especificamos el nombre del gráfico, el _identificación del vértice de inicio y filtrar en el vértice de
destino. Solo estamos interesados en el primer vértice que coincide con el filtro, por lo tanto, aplicamos un
LÍMITE 1. Vemos de nuevo que AQL soporta directamente este tipo de consulta gráfica.
● ¿Qué partes de este avión necesitan mantenimiento la próxima semana?
Esta pregunta ilustra la flexibilidad del modelo múltiple. La consulta que responde a esta pregunta es
asociativa, no de navegación. La consulta no necesita atravesar la estructura del gráfico y podemos
consultar directamente el modelo de datos del documento para obtener la respuesta con el índice
secundario apropiado para optimizar el rendimiento de la consulta.
Figura 6: Consulta cuyo resultado es ortogonal a la estructura del gráfico.
Este tipo de consulta sería muy engorrosa en una base de datos y un lenguaje de consulta de gráficos puros.
Esto se debe a que la consulta debe basarse en índices secundarios, en este caso, en el atributo que almacena
la fecha de la próxima hora de mantenimiento.
Usamos una consulta de documento para encontrar los componentes que deben mantenimiento:
POR C EN componentes
F
REGRESO
ILTER c.nextMantenimiento
{id: c._id, <= "2016-12-15 "
nextMaintenance: c.nextMaintenance}
AQL utiliza una metáfora de bucle para describir el procesamiento de documentos en elcomponentes
colección. El optimizador de consultas identifica que puede usar el índice secundario en el
11
siguienteMantenimiento atributo para generar una ruta de ejecución de consultas eficiente que utiliza el índice en
lugar de realizar un análisis de colección completa que comprueba elFILTRAR condición sobre todos los documentos.
Tenga en cuenta que AQL especifica las proyecciones de documentos simplemente formando un nuevo documento JSON en
elREGRESO declaración de datos conocidos. La consulta anterior ilustra cómo AQL también admite consultas que son típicas
de los almacenes de documentos.
3.1.3 Uso de consultas de modelos múltiples
Usaremos la siguiente pregunta para ilustrar el poder de combinar múltiples modelos de consulta en
una consulta: ¿Qué partes deben mantenerse la próxima semana y quién es el punto de contacto para
cada una de esas partes?
La consulta que responde a esta pregunta encuentra las piezas con mantenimiento pendiente, encuentra el
componente principal más cercano que contiene el procedimiento de mantenimiento y luego realiza una operación
JOIN con elcontactos colección para agregar información de contacto para mantenimiento en el resultado:
POR pag EN pag
letras "2 016-12-15 "

POR C EN
FIL TER pag. 0..4 INBOUND p GR APH
siguienteMantenimiento <= "FleetGraph"
FILTRAR c. es mantenible == cierto
L
POR
IMIT 1
pers o norte EN contactos F=
C.C contacto
REGRESO
ILTER person._key
{part: p._id,
= componente: c, contacto: persona}
Esta consulta ilustra cómo realizar JOIN en AQL. El tercero anidadoPOR declaración trae elcontactos
colección en consideración para unir contra el contacto en el primer componente mantenible por
encima de la parte programada para mantenimiento. El optimizador de consultas reconoce que el
FILTRAR La declaración se puede implementar de manera más eficiente haciendo un JOIN usando el
índice principal de lacontactos colección para una búsqueda rápida de hash.
Este es un ejemplo del poder y la flexibilidad del enfoque multimodelo. La consulta necesita los tres
modelos de datos: documentos con índices secundarios, recorrido de gráfico y un JOIN impulsado por
búsqueda rápida de clave / valor. Imagina los aros que tendríamos que saltar
12
¡hasta si los tres modelos de datos no coexistían en el mismo motor de base de datos y en el
mismo lenguaje de consulta!
Este estudio de caso muestra que los tres modelos de datos diferentes eran realmente necesarios para lograr un
buen rendimiento para todas las consultas que surgen de la aplicación. Sin una base de datos de gráficos, las
consultas transversales con longitudes de ruta desconocidas a priori requerirían operaciones multi-JOIN
notoriamente desagradables e ineficientes. Sin embargo, una base de datos de gráficos pura no satisfaría nuestras
necesidades de consultas de documentos que se lograron de manera eficiente utilizando los índices secundarios
correctos. Las búsquedas de clave / valor complementan la imagen al permitir operaciones JOIN eficaces que brindan
flexibilidad adicional en la representación de datos. Por ejemplo, en el caso de estudio, no tuvimos que incrustar de
forma redundante los datos de contacto completos en cada documento, porque podríamos realizar la operación JOIN
en la última consulta.
Vale la pena señalar que ArangoDB se puede utilizar como una base de datos de gráficos pura, un almacén de
documentos puro o un almacén de clave / valor puro. La combinación de modelos no siempre es necesaria, pero
siempre es posible incluso dentro de la misma consulta.
3.2 Lecciones aprendidas para el modelado de datos
● JSON es muy versátil para datos estructurados y no estructurados. La naturaleza recursiva de JSON
permite la incrustación de subdocumentos y listas de longitud variable. Incluso puede almacenar las filas
de una tabla como documentos JSON. Los almacenes de datos modernos son tan buenos para comprimir
datos que no hay sobrecarga de memoria en comparación con las bases de datos relacionales. Para los
datos estructurados, la validación del esquema se puede implementar según sea necesario mediante
microservicios.
● Los gráficos son un buen modelo de datos para las relaciones. En muchos casos del mundo real, un gráfico es
un modelo de datos natural. Captura relaciones y el uso de JSON puede almacenar datos complejos en bordes y
vértices. Conozca las capacidades de la base de datos de gráficos en ArangoDB.
● Una base de datos de gráficos es particularmente buena para consultas de navegación. Lo

crucial aquí es que el lenguaje de consulta debe implementar rutinas como "ruta más corta" y
"recorrido de gráfico". La capacidad fundamental para estos es acceder rápidamente a la lista de
todos los bordes entrantes o salientes de un vértice.
● Una base de datos multimodelo puede competir con soluciones especializadas. La elección
particular de los tres modelos de datos nos permite combinarlos en un motor coherente. Esta
combinación no significa compromiso: como almacén de documentos es tan eficiente
13
como un almacén de documentos dedicado. Como base de datos de gráficos, es tan eficiente como una base de datos
de gráficos dedicada.
● Una base de datos de varios modelos le permite elegir diferentes modelos de datos con menos
gastos operativos. Tener múltiples modelos de datos coexistiendo en un solo motor de base de
datos alivia los muchos desafíos de usar diferentes modelos de datos al mismo tiempo. Significa
menos sobrecarga operativa y menos sincronización de datos, lo que permite un gran salto en la
flexibilidad del modelado de datos. Tiene la capacidad de mantener juntos los datos relacionados en
el mismo almacén de datos, incluso si se requieren diferentes modelos de datos para hacerlo. La
combinación de diferentes modelos de datos en una sola consulta aumenta las opciones de diseño
de aplicaciones y optimizaciones de rendimiento. Y si elige dividir la capa de persistencia en varias
instancias de base de datos diferentes, aún tiene la ventaja de tener que implementar solo una
tecnología. Además, se evita el bloqueo del modelo de datos.
● El modelo múltiple tiene un espacio de solución más grande que el relacional. Teniendo en cuenta
todas estas posibilidades para las consultas, la flexibilidad en el modelado de datos y los beneficios de la
persistencia políglota sin la consiguiente fricción, el enfoque de múltiples modelos cubre un espacio de
solución que es más grande que el del modelo relacional.
4 Casos de uso adicionales para bases de datos nativas de modelos múltiples
Gestión de contenido
El contenido tiene una estructura no homogénea, lo que hace que un almacén de documentos sea un buen modelo de
datos. Sin embargo, los enlaces y conexiones entre diferentes piezas de contenido se describen de manera más
conveniente y natural mediante una estructura de gráfico.
Gráficos de conocimiento
Los gráficos de conocimiento son enormes colecciones de datos, la mayoría de las consultas de los sistemas expertos
utilizan solo los bordes y las consultas de gráficos, pero a menudo se necesitan consultas “ortogonales” y asociativas que
solo consideran los datos de vértice. El modelo múltiple también permite que los datos de origen se coloquen en etapas en
el gráfico de conocimiento y los datos seleccionados se puedan servir directamente desde el gráfico de conocimiento para
respaldar las aplicaciones que consumen los datos. Obtener el completoInforme técnico del gráfico de conocimiento
empresarial multimodelo.
Jerarquías empresariales
Las jerarquías empresariales se ajustan naturalmente a un modelo de gráfico; sin embargo, la administración de derechos de acceso a los
datos generalmente requiere una combinación de consultas de gráficos y documentos.
14
Detección de fraudes
Este caso de uso implica ensamblar e integrar una gran cantidad de datos que involucran conexiones entre
diferentes entidades como cuentas, direcciones IP, máquinas y similares. En muchos casos, esto se puede
modelar razonablemente mediante una estructura gráfica. La detección del fraude implica una comparación
de patrones compleja que también considera la estructura del gráfico (por ejemplo, una cantidad inusual de
conexiones a un solo host o cuenta, o largas cadenas de fraude), así como análisis estadístico, consultas
asociativas y JOIN.
Gestión de identidades y accesos

De manera similar al caso de uso de jerarquías empresariales anterior, la administración de identidades y accesos a
menudo involucra datos que tienen una estructura jerárquica y, por lo general, las personas o entidades más altas
en la jerarquía tienen sus propios derechos de acceso, además de todos los derechos de acceso de sus
subordinados. Estos datos se describen mejor mediante un árbol o un gráfico acíclico dirigido. Decidir los derechos
de acceso a menudo implica la estructura del gráfico, pero también hay muchas consultas sobre las identidades que
ignoran por completo la jerarquía.
Estructuras de datos complejas definidas por el usuario

Cualquier aplicación que se ocupe de estructuras de datos complejas definidas por el usuario se beneficia enormemente de
la flexibilidad de un almacén de documentos y, a menudo, también tiene buenas aplicaciones para datos gráficos.
Sistemas de comercio electrónico

Los sistemas de comercio electrónico necesitan almacenar datos de clientes y productos (JSON), carritos de
compras (clave / valor), pedidos y ventas (JSON o gráfico) y datos para recomendaciones (gráfico), y
necesitan una multitud de consultas con todos estos datos. artículos.
Motor de recomendaciones en tiempo real

La creación de recomendaciones sensatas y efectivas en tiempo real para los clientes en el comercio
electrónico requiere la coincidencia de patrones de ruta en gráficos, ya que a uno le gustaría recomendar
cosas a un cliente A que han sido compradas por otro cliente B que está vinculado a A de alguna manera. ,
por ejemplo, por haber comprado ambos productos similares. Al mismo tiempo, las consultas también
utilizan índices secundarios en el catálogo de productos, por ejemplo, para tener en cuenta el rango de ventas
y las cosas.
Internet de las Cosas

IoT produce un volumen muy alto de datos de estado, información de ubicación geográfica, datos de
sensores y similares. Al mismo tiempo, las cosas reales en IoT generalmente vienen en una estructura
jerárquica. Por ejemplo, todos los dispositivos domésticos en la misma casa reportarían a la casa,
15
que a su vez agregaría algunos datos y reportaría a niveles más altos. Esto significa que los datos sobre los
dispositivos se modelan naturalmente mediante un gráfico y el gran volumen de datos del sensor tiene una
estructura diversa y, a menudo, debe unirse a un conjunto mucho más pequeño de datos.
Logística
La logística implica ubicaciones geográficas, tareas, dependencias de tareas y recursos necesarios para las tareas.
Los datos tienen una estructura bastante diversa y están muy conectados. Las consultas implican consultas de
gráficos que consideran dependencias y consultas asociativas respaldadas por índices.
Operaciones de red y TI
Las redes de computadoras, los hosts asociados y sus componentes, así como las virtulizaciones de la
infraestructura definida por software, forman un gráfico, y la administración de dicha infraestructura implica
consultas sobre esta estructura gráfica, pero también consultas sobre el conjunto de hosts o cosas similares.
Redes sociales
Las redes sociales son el mejor ejemplo de gráficos grandes y altamente conectados y, por lo general, involucran
algoritmos de gráficos y consultas de recorrido de gráficos; sin embargo, las aplicaciones a menudo necesitan
consultas adicionales que consultan y agregan información entre individuos y, por lo tanto, necesitan índices
secundarios y posiblemente JOINs con búsquedas clave.
La gestión del tráfico

Las redes de calles se modelan naturalmente como un gráfico. Los datos de flujo de tráfico producen un gran
volumen de datos basados en el tiempo que están estrechamente relacionados con la red de calles. Encontrar
buenas decisiones sobre la gestión del tráfico implica consultar todos estos datos y ejecutar algoritmos inteligentes
mediante agregaciones, recorridos de gráficos y uniones.
Aplicaciones de gestión de versiones

Las aplicaciones de administración de versiones generalmente funcionan con un gráfico acíclico dirigido, pero también
necesitan consultas gráficas y otros.
Software de gestión de flujo de trabajo

El software de gestión de flujo de trabajo a menudo modela las dependencias entre tareas con un
gráfico, algunas consultas necesitan estas dependencias; otros los ignoran y solo miran los datos
restantes.
dieciséis

ArangoDB en Es

Cargado por

Copyright:

Formatos disponibles

ArangoDB en Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ArangoDB en Es

Cargado por

Copyright:

Formatos disponibles

Papel blanco:

¿Qué es una base de datos multimodelo y

Un libro blanco de ArangoDB (abril de 2020)

1 ¿Qué es una base de datos nativa multimodelo? 3

2 ¿Por qué multimodelo nativo? 4

3 Modelado de datos con bases de datos nativas de múltiples modelos 6

3.1 Mantenimiento de la flota de aeronaves: un estudio de caso 6

3.1.1 Un modelo de datos para una flota de aeronaves 7

3.1.2 Consultas para el mantenimiento de la flota de aeronaves 8

3.1.3 Uso de consultas de modelos múltiples 12

3.2 Lecciones aprendidas para el modelado de datos 13

4 Otros casos de uso para bases de datos nativas de modelos múltiples 14

1 ¿Qué es una base de datos nativa multimodelo?

Entonces, ¿qué es una base de datos nativa de múltiples modelos?

2 ¿Por qué multimodelo nativo?

documentos y los gráficos? La respuesta es muy simple.

3 Modelado de datos con bases de datos nativas de múltiples modelos

3.1 Mantenimiento de la flota de aeronaves: un estudio de caso

Las piezas y componentes tienen:

● ¿Cuáles son todos los componentes de una pieza determinada?

3.1.1 Un modelo de datos para una flota de aeronaves

Figura 3: Un árbol estructurado en gráficos de documentos de elementos.

3.1.2 Consultas para el mantenimiento de la flota de aeronaves

● ¿Cuáles son todas las partes constituyentes de un componente dado?

Figura 4: Encontrar todas las partes que forman parte de un componente.

Figura 5: Encontrar el componente más pequeño que se puede mantener.

● ¿Qué partes de este avión necesitan mantenimiento la próxima semana?

Figura 6: Consulta cuyo resultado es ortogonal a la estructura del gráfico.

3.1.3 Uso de consultas de modelos múltiples

POR pag EN pag

letras "2 016-12-15 "

3.2 Lecciones aprendidas para el modelado de datos

● Una base de datos de gráficos es particularmente buena para consultas de navegación. Lo

4 Casos de uso adicionales para bases de datos nativas de modelos múltiples

datos generalmente requiere una combinación de consultas de gráficos y documentos.

Gestión de identidades y accesos

Estructuras de datos complejas definidas por el usuario

Sistemas de comercio electrónico

Motor de recomendaciones en tiempo real

Internet de las Cosas

La gestión del tráfico

Aplicaciones de gestión de versiones

Software de gestión de flujo de trabajo

Copyright ArangoDB Inc.

También podría gustarte