yang db
1.0.0
https://www.yangdb.org/
wiki
Información de versión
Notas de la versión
Lior Perry
Margolis romana
Moti Cohen
Elad Wies
Shimon Benoshti
Una publicación que presenta nuestra nueva iniciativa de código abierto para crear una base de datos de gráficos distribuidos escalable a través de Opensearch https://www.linkedin.com/pulse/making-db-lior-perry/
Otro uso de Opensearch como base de datos gráfica https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622
El mundo de las bases de datos gráficas ha tenido un tremendo impacto durante los últimos años, en particular en relación con las redes sociales y su efecto en nuestra actividad diaria.
El alguna vez poderoso (y solitario) RDBMS ahora se ve obligado a dejar espacio para un socio emergente y cada vez más importante en el centro de datos: la base de datos de gráficos.
Twitter lo está usando, Facebook lo está usando, incluso los sitios de citas en línea lo están usando; Están usando gráficos de relaciones. Después de todo, lo social es social y, en última instancia, se trata de relaciones.
Hay dos elementos principales que distinguen la tecnología de gráficos: almacenamiento y procesamiento.
El almacenamiento de gráficos comúnmente se refiere a la estructura de la base de datos que contiene datos de gráficos.
Dicho almacenamiento de gráficos está optimizado para gráficos en muchos aspectos, lo que garantiza que los datos se almacenen de manera eficiente y mantenga los nodos y las relaciones cerca entre sí en la capa física real.
El almacenamiento de gráficos se clasifica como no nativo cuando el almacenamiento proviene de una fuente externa, como una base de datos relacional, en columnas o de cualquier otro tipo (en la mayoría de los casos es preferible un almacén NoSQL).
Las bases de datos de gráficos no nativas generalmente constan de almacenes relacionales, de documentos y de valores clave existentes, adaptados para los escenarios de consulta del modelo de datos de gráficos.
El procesamiento de gráficos incluye acceder al gráfico, atravesar los vértices y aristas y recopilar los resultados.
Un recorrido es la forma en que se consulta un gráfico, navegando desde los nodos iniciales a los nodos relacionados, siguiendo las relaciones de acuerdo con algunas reglas.
encontrar respuestas a preguntas como "¿qué música les gusta a mis amigos y que yo aún no tengo?"
Uno de los modelos más populares para representar un gráfico es el modelo de propiedades.
Este modelo contiene entidades conectadas (los nodos) que pueden contener cualquier número de atributos (pares clave-valor).
Los nodos tienen una identificación única y una lista de atributos representan sus características y contenido.
Los nodos se pueden marcar con etiquetas que representan sus diferentes roles en su dominio. Además de las propiedades de relación, las etiquetas también pueden proporcionar metadatos sobre elementos del gráfico.
Los nodos se utilizan a menudo para representar entidades pero, dependiendo de las relaciones de dominio, también se pueden utilizar para ese fin.
La relación está representada por el nodo de origen y de destino que están conectando y, en caso de múltiples conexiones entre los mismos vértices, etiqueta adicional de propiedad para distinguir (tipo de relación).
Las relaciones organizan los nodos en estructuras arbitrarias, lo que permite que un gráfico se parezca a una lista, un árbol, un mapa o una entidad compuesta, cualquiera de los cuales puede combinarse en estructuras aún más complejas.
Al igual que las claves externas entre tablas en el modelo de base de datos relacional, en el modelo de gráfico, la relación describe las relaciones entre los vértices.
Una diferencia importante en este modelo (en comparación con el esquema relacional estricto) es que esta estructura sin esquema permite agregar o eliminar relaciones entre vértices sin ninguna restricción.
Un modelo de gráfico adicional es el modelo Marco de descripción de recursos (RDF).
Nuestro caso de uso está en el dominio de las redes sociales. Un gráfico social muy grande que debe actualizarse frecuentemente y estar disponible tanto para:
búsqueda simple (principalmente textual)
consultas basadas en gráficos.
Todas las operaciones de lectura y escritura se realizan simultáneamente con un tiempo de respuesta razonable y un rendimiento cada vez mayor.
El primer requisito se cumplió utilizando Opensearch, un conocido y establecido motor de almacenamiento y búsqueda de documentos NoSql capaz de contener un gran volumen de datos.
Para el segundo requisito , decidimos que nuestra mejor solución sería utilizar Opensearch como capa de almacenamiento de base de datos gráfica no nativa .
Como se mencionó anteriormente, se puede implementar una capa de almacenamiento de base de datos gráfica utilizando un almacenamiento no nativo como el almacenamiento NoSql.
En futuras discusiones entraré en detalles de por qué la alternativa comunitaria más popular para Graph-DB, Neo4J, no podría satisfacer nuestras necesidades.
El primer problema en nuestro plato es diseñar el modelo de datos que representa el gráfico, como un conjunto de vértices y aristas.
Con Opensearch podemos utilizar sus poderosas capacidades de búsqueda para buscar de manera eficiente documentos de nodos y relaciones de acuerdo con los filtros de consulta.
En Opensearch, cada índice se puede describir como una tabla para un esquema específico; el índice en sí está dividido en compartidos, lo que permite la escala y la redundancia (con réplicas) en todo el clúster.
Un documento se enruta a un fragmento particular en un índice usando la siguiente fórmula:
shard_num = hash(_routing) % num_primary_shards
Cada índice tiene un esquema (llamado tipo en Opensearch) que define la estructura de los documentos (llamado mapeo en Opensearch). Cada índice puede contener solo un tipo de mapeo (desde Opensearch 6)
El índice de vértices contendrá los documentos de vértices con las propiedades, el índice de aristas contendrá los documentos de aristas con sus propiedades.
La forma en que describimos cómo recorrer el gráfico (fuente de datos)
Hay pocos lenguajes de consulta orientados a gráficos:
Cypher es un lenguaje de consulta para la base de datos de gráficos Neo4j (consulte la iniciativa openCypher)
Gremlin es un lenguaje transversal de gráficos de Apache Software Foundation para sistemas de gráficos OLTP y OLAP.
SPARQL es un lenguaje de consulta para gráficos RDF.
Algunos de los lenguajes se basan más en patrones y son declarativos, otros son más imperativos: todos describen la forma lógica de atravesar los datos.
Consideremos Cypher, un lenguaje declarativo inspirado en SQL para describir patrones en gráficos visualmente utilizando una sintaxis ascii-art.
Nos permite indicar qué queremos seleccionar, insertar, actualizar o eliminar de los datos de nuestro gráfico sin requerir que describamos exactamente cómo hacerlo.
Una vez que se proporciona una consulta lógica, debemos traducirla a la capa física del almacenamiento de datos, que es Opensearch.
Opensearch tiene una consulta DSL que se centra en la búsqueda y las agregaciones; no en el recorrido, necesitamos una fase de traducción adicional que tendrá en cuenta la estructura esquemática del gráfico (y los índices subyacentes).
La traducción de consultas lógicas a físicas es un proceso que implica algunos pasos:
validar la consulta contra el esquema
traducir las etiquetas en entidades de esquema reales (índices)
creando la consulta física de Opensearch
Este es el proceso en una revisión de alto nivel; en la práctica, habrá más etapas para optimizar la consulta lógica; en algunos casos es posible crear múltiples planes físicos (planes de ejecución) y clasificarlos de acuerdo con alguna estrategia de eficiencia (costo), como el recuento de elementos necesarios para recuperar...
Comenzamos discutiendo el propósito de la base de datos de gráficos en los casos de uso empresarial actuales y revisamos diferentes modelos para representar un gráfico. Comprender los componentes lógicos fundamentales en los que debe consistir una base de datos gráfica potencial y analizar un candidato NoSql existente para cumplir con los requisitos de la capa de almacenamiento.
Una vez que seleccionamos Opensearch como capa de almacenamiento, tomamos el modelo gráfico de LDBC Social Network Benchmark y lo simplificamos para optimizarlo en ese almacenamiento específico. Discutimos el esquema de almacenamiento real con las propiedades redundantes y revisamos el lenguaje de cifrado para consultar el almacenamiento en un lenguaje de patrón gráfico similar a SQL.
Continuamos viendo la transformación real de la consulta cifrada en una consulta de ejecución física que ejecutará Opensearch.
En la última sección tomamos una consulta gráfica simple y profundizamos en los detalles de las estrategias de ejecución y el mecanismo de agrupación.
Tutorial de instalación:
Tutorial de creación de esquemas:
Tutorial de carga de datos:
Consulta el tutorial de Graph:
Tutorial de materialización y conteo de proyecciones:
