Una mejor manera de almacenar datos conectados
Valor clave, orientado a documentos, familia de columnas, gráfico, relacional… Hoy en día parece que tenemos tantos tipos de bases de datos como tipos de datos. Si bien esto puede dificultar la elección de una base de datos, facilita la elección de la base de datos correcta. Por supuesto, eso requiere hacer su tarea. Debe conocer sus bases de datos.
Uno de los tipos de bases de datos menos conocidos es la base de datos gráfica. Diseñada para trabajar con datos muy interconectados. Una base de datos gráfica podría describirse como más “relacional” que una base de datos relacional. Las bases de datos gráficas brillan cuando el objetivo es capturar relaciones complejas en vastas redes de información.
A continuación, se detalla qué son las bases de datos gráficas, por qué son diferentes a otras bases de datos y qué tipos de problemas de datos están diseñadas a resolver.
Base de datos gráfica versus base de datos relacional
En una base de datos relacional o SQL tradicional, los datos están organizados en tablas. Cada tabla registra los datos en un formato específico con un número fijo de columnas, cada columna con su propio tipo de datos (entero, hora/fecha, texto libre, etc.).
Este modelo funciona mejor cuando se trata principalmente de datos de cualquier tabla. Tampoco funciona demasiado mal cuando se le agregan datos almacenados en varias tablas. Pero ese comportamiento tiene algunos límites notables.
Considere una base de datos de música, con álbumes, bandas, etiquetas y artistas. Si desea reportar todos los artistas que aparecieron en este álbum por esa banda lanzada en estas etiquetas -cuatro tablas diferentes- tiene que describir explícitamente esas relaciones. Con una base de datos relacional, puede lograr esto a través de nuevas columnas de datos (para relaciones de uno a uno o de uno a muchos) o nuevas tablas (para relaciones de varios a muchos).
Esto es práctico siempre y cuando administre un número modesto de relaciones. Si se trata de millones o incluso miles de millones de relaciones -amigos de amigos de amigos, por ejemplo- esas consultas no crecen bien.
En resumen, si las relaciones entre los datos, no los datos en sí, son su principal preocupación, entonces un tipo diferente de base de datos -una base de datos gráfica- es lo recomendable.
Funciones de la base de datos gráfica
El término “gráfico” proviene del uso de la palabra en matemáticas. Allí se usa para describir una colección de nodos (o vértices), cada uno con información (propiedades) y con relaciones etiquetadas (o bordes) entre los nodos.
Una red social es un buen ejemplo de un gráfico. Las personas en la red serían los nodos, los atributos de cada persona (como nombre, edad, etc.) serían propiedades y las líneas que conectarían a las personas (con etiquetas como “amigo” o “madre” o ” supervisor “) indicarían su relación.
En una base de datos convencional, las consultas sobre relaciones pueden tardar mucho tiempo en procesarse. Esto se debe a que las relaciones se implementan con claves externas y se consultan al unir tablas. Como puede decirle cualquier SQL DBA, realizar uniones es costoso, especialmente cuando debe clasificar grandes cantidades de objetos -o, lo que es peor, cuando debe unir varias tablas para realizar consultas indirectas (por ejemplo, “amigo de un amigo”) que es donde destacan las bases de datos gráficas.
Las bases de datos gráficas funcionan almacenando las relaciones junto con los datos. Debido a que los nodos relacionados están físicamente vinculados en la base de datos, el acceso a esas relaciones es tan inmediato como el acceso a los datos en sí. En otras palabras, en lugar de calcular la relación como lo deben hacer las bases de datos relacionales, las bases de datos gráficas simplemente leen la relación desde el almacenamiento. Las consultas satisfactorias son una simple cuestión de caminar o “atravesar” el gráfico.
Una base de datos gráfica no solo almacena las relaciones entre los objetos de forma nativa, lo que hace que las consultas sobre relaciones sean rápidas y fáciles, sino que le permite incluir diferentes tipos de objetos y diferentes tipos de relaciones en el gráfico. Al igual que otras bases de datos NoSQL, una base de datos gráfica no tiene esquemas. Por lo tanto, en términos de rendimiento y flexibilidad, las bases de datos gráficas se acercan más a las bases de datos de documentos o almacenes de valores clave, que a las bases de datos relacionales u orientados a tablas.
Casos de uso de la base de datos gráficas
Las bases de datos gráficas funcionan mejor cuando los datos con los que está trabajando están muy conectados y deberían estar representados por cómo se vinculan o se refieren a otros datos, generalmente a través de relaciones de muchos a muchos.
Nuevamente, una red social es un ejemplo útil. Las bases de datos gráficas reducen la cantidad de trabajo necesario para construir y mostrar las vistas de datos encontradas en las redes sociales, como las fuentes de actividad; o determinar si usted puede conocer a una persona determinada por su proximidad a otros amigos que tiene en la red.
Otra aplicación para bases de datos gráficas es encontrar patrones de conexión en datos de gráficos que serían difíciles de detectar a través de otras representaciones de datos. Los sistemas de detección de fraudes utilizan bases de datos gráficas para poner de manifiesto relaciones entre entidades que de otra manera podrían haber sido difíciles de detectar.
Del mismo modo, las bases de datos gráficas son una opción natural para las aplicaciones que administran las relaciones o interdependencias entre entidades. A menudo encontrará bases de datos gráficas detrás de los motores de recomendación, los sistemas de administración de contenidos y activos, los sistemas de administración de identidad y acceso, y las soluciones de cumplimiento regulatorio y de gestión de riesgos.
Consultas de base de datos gráfica
Las bases de datos gráficas -como otras bases de datos NoSQL- generalmente usan su propia metodología de consulta personalizada en lugar de SQL.
Un lenguaje de consulta de gráficos comúnmente utilizado es Cypher, desarrollado originalmente para la base de datos gráfica Neo4j. Desde finales del 2015, Cypher se ha desarrollado como un proyecto de código abierto separado, y otros proveedores lo han adoptado como un sistema de consulta para sus productos (por ejemplo, SAP HANA).
Aquí hay un ejemplo de una consulta de Cypher que devuelve un resultado de búsqueda para todos los que son amigos de Scott:
MATCH (a:Person {name:’Scott’})-[:FRIENDOF]->(b)
RETURN b
El símbolo de flecha (->) se usa en las consultas Cypher para representar una relación dirigida en el gráfico.
Otro lenguaje común de consulta de gráficos, Gremlin, fue diseñado para el marco de trabajo de cómputo gráfico, Apache TinkerPop. La sintaxis de Gremlin es similar a la utilizada por las bibliotecas de acceso a bases de datos ORM de algunos lenguajes.
Aquí hay un ejemplo de una consulta de “amigos de Scott” en Gremlin:
g.V().has(“name”,”Scott”).out(“friendof”)
Muchas bases de datos gráficas tienen soporte para GREMLIN a través de una biblioteca, ya sea incorporada o de terceros.
Sin embargo, otro lenguaje de consulta es SPARQL. Originalmente fue desarrollado por el W3C para consultar los datos almacenados en el formato del Resource Description Framework (RDF) para los metadatos. En otras palabras, SPARQL no se diseñó para búsquedas en bases de datos gráficas, pero se puede usar para ellas. En general, Cypher y GREMLIN han sido adoptados más ampliamente.
Las consultas de SPARQL tiene algunos elementos que se asemejan a SQL, principalmente las cláusulas SELECT y WHERE, pero el resto de la sintaxis es radicalmente diferente. No piense en SPARQL como algo relacionado con SQL, tampoco para otros lenguajes de consulta de gráficos.
Las bases de datos gráficas más utilizadas
Debido a que las bases de datos gráficas sirven para un caso de uso que es relativamente un nicho, no existen tantas como en el caso de las bases de datos relacionales. El aspecto positivo de esto es que hace que los productos destacados sean más fáciles de identificar y discutir.
Neo4j: Neo4j es con seguridad la base de datos gráfica más madura (once años y contando) y la más conocida para el uso general. A diferencia de los productos de bases de datos gráficas anteriores, no usa un back-end SQL. Neo4j es una base de datos gráfica nativa que se diseñó de adentro hacia afuera para brindar soporte a estructuras de gráficos grandes, como en consultas que devuelven cientos de miles de relaciones y más.
Neo4j viene en ediciones empresariales gratuitas de código abierto y de pago, y esta última no tiene restricciones sobre el tamaño de un conjunto de datos (entre otras funciones). También puede experimentar con Neo4j en línea a través de su Sandbox, que incluye algunos conjuntos de datos de muestra para practicar.
Microsoft Azure Cosmos DB: La base de datos de nube, Azure Cosmos DB es un proyecto ambicioso. Su objetivo es emular múltiples tipos de bases de datos -tablas convencionales, orientadas a documentos, familias de columnas y gráficos- todo a través de un único servicio unificado con un conjunto consistente de API.
Para ello, una base de datos gráfica es solo uno de los diversos modos en los que puede operar Cosmos DB. Utiliza el lenguaje de consulta de Gremlin y la API para consultas de tipo gráfico, y admite la consola de Gremlin creada para Apache TinkerPop como otra interfaz.
Otro gran atractivo comercial de Cosmos DB es que la indexación, la escala y la georeplicación se manejan automáticamente en la nube de Azure, sin ningún tipo de manipulación de su parte. Todavía no está claro cómo la arquitectura ‘todo en uno’ de Microsoft se compara con las bases de datos gráficas nativas en términos de rendimiento, pero Cosmos DB ciertamente ofrece una combinación útil de flexibilidad y escalabilidad.
JanusGraph: JanusGraph se escindió del Proyecto TitanDB, y ahora está bajo la gobernanza de la Fundación Linux. Utiliza cualquiera de una serie de back-ends (Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB) para almacenar datos gráficos, brinda soporte al lenguaje de consulta de Gremlin (así como otros elementos del stack de Apache TinkerPop), y también puede incorporar la búsqueda de texto completo a través de los proyectos Apache Solr, Apache Lucene o Elasticsearch.
IBM, uno de los partidarios del proyecto JanusGraph, ofrece una versión alojada de JanusGraph en IBM Cloud, llamada Compose for JanusGraph. Al igual que Azure Cosmos DB, Compose for JanusGraph proporciona autoescalabilidad y alta disponibilidad, con precios basados en el uso de recursos.
-Serdar Yegulalp, InfoWorld.com
