yang db
1.0.0
https://www.yangdb.org/
wiki
Informações da versão
Notas de lançamento
Lior Perry
Roman Margolis
Moti Cohen
Elad Wies
Shimon Benoshti
Uma postagem apresentando nossa nova iniciativa de código aberto para construir um banco de dados gráfico distribuído escalável em pesquisa aberta https://www.linkedin.com/pulse/making-db-lior-perry/
Outro uso do Opensearch como banco de dados gráfico https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622
O mundo das bases de dados gráficas teve um impacto tremendo durante os últimos anos, em particular no que diz respeito às redes sociais e ao seu efeito na nossa atividade quotidiana.
O outrora poderoso (e solitário) RDBMS é agora obrigado a abrir espaço para um parceiro emergente e cada vez mais importante no data center: o banco de dados gráfico.
O Twitter está usando, o Facebook está usando, até mesmo sites de namoro online estão usando; eles estão usando gráficos de relacionamento. Afinal, social é social e, em última análise, trata-se de relacionamentos.
Existem dois elementos principais que distinguem a tecnologia gráfica: armazenamento e processamento.
O armazenamento gráfico geralmente se refere à estrutura do banco de dados que contém dados gráficos.
Esse armazenamento de gráficos é otimizado para gráficos em muitos aspectos, garantindo que os dados sejam armazenados de forma eficiente, mantendo nós e relacionamentos próximos uns dos outros na camada física real.
O armazenamento gráfico é classificado como não nativo quando o armazenamento vem de uma fonte externa, como um banco de dados relacional, colunar ou qualquer outro tipo (na maioria dos casos, um armazenamento NoSQL é preferível)
Bancos de dados gráficos não nativos geralmente compreendem armazenamentos relacionais, de documentos e de valores-chave existentes, adaptados para os cenários de consulta do modelo de dados gráficos.
O processamento de gráfico inclui acessar o gráfico, percorrer os vértices e arestas e coletar os resultados.
Uma travessia é como você consulta um gráfico, navegando dos nós iniciais até os nós relacionados, seguindo relacionamentos de acordo com algumas regras.
encontrar respostas para perguntas como "que música meus amigos gostam e que eu ainda não possuo?"
Um dos modelos mais populares para representar um gráfico é o Modelo de Propriedades.
Este modelo contém entidades conectadas (os nós) que podem conter qualquer número de atributos (pares chave-valor).
Os nós têm um ID exclusivo e uma lista de atributos que representa seus recursos e conteúdo.
Os nós podem ser marcados com rótulos que representam suas diferentes funções no seu domínio. Além das propriedades de relacionamento, os rótulos também podem servir metadados em elementos gráficos.
Os nós são frequentemente usados para representar entidades, mas dependendo dos relacionamentos de domínio também podem ser usados para esse propósito.
O relacionamento é representado pelo nó de origem e de destino que eles estão conectando e no caso de múltiplas conexões entre os mesmos vértices – rótulo adicional de propriedade para distinguir (tipo de relacionamento)
Os relacionamentos organizam os nós em estruturas arbitrárias, permitindo que um gráfico se assemelhe a uma lista, uma árvore, um mapa ou uma entidade composta – qualquer um dos quais pode ser combinado em estruturas ainda mais complexas.
Muito parecido com as chaves estrangeiras entre tabelas no modelo de banco de dados relacional, no modelo de gráfico o relacionamento descreve as relações entre os vértices.
Uma grande diferença neste modelo (em comparação com o esquema relacional estrito) é que esta estrutura sem esquema permite adicionar/remover relacionamento entre vértices sem quaisquer restrições.
O modelo gráfico adicional é o modelo Resource Description Framework (RDF).
Nosso caso de uso está no domínio das redes sociais. Um gráfico social muito grande que deve ser atualizado com frequência e estar disponível para ambos:
pesquisa simples (principalmente textual)
consultas baseadas em gráficos.
Todas as leituras e gravações são feitas simultaneamente, com tempo de resposta razoável e rendimento cada vez maior.
O primeiro requisito foi atendido usando o Opensearch – um mecanismo de pesquisa e armazenamento de documentos NoSql bem conhecido e estabelecido, capaz de conter um volume muito grande de dados.
Para o segundo requisito , decidimos que nossa melhor solução seria usar Opensearch como camada de armazenamento de banco de dados gráfico não nativo .
Conforme mencionado anteriormente, uma camada de armazenamento de banco de dados gráfico pode ser implementada usando um armazenamento não nativo, como armazenamento NoSql.
Em discussões futuras, entrarei em detalhes por que a alternativa mais popular da comunidade para Graph-DB – Neo4J, não atendeu às nossas necessidades.
A primeira questão em nosso prato é projetar o modelo de dados que representa o gráfico, como um conjunto de vértices e arestas.
Com o Opensearch, podemos utilizar seus poderosos recursos de pesquisa para buscar com eficiência documentos de nós e relacionamentos de acordo com os filtros de consulta.
No Opensearch cada índice pode ser descrito como uma tabela para um esquema específico, o próprio índice é particionado em compartilhado que permite escala e redundância (com réplicas) em todo o cluster.
Um documento é roteado para um fragmento específico em um índice usando a seguinte fórmula:
shard_num = hash(_routing)% num_primary_shards
Cada índice possui um esquema (chamado de tipo no Opensearch) que define a estrutura dos documentos (chamado de mapeamento no Opensearch). Cada índice pode conter apenas um único tipo de mapeamento (desde Opensearch 6)
O índice de vértices conterá os documentos de vértices com as propriedades, o índice de arestas conterá os documentos de arestas com suas propriedades.
A maneira como descrevemos como percorrer o gráfico (fonte de dados)
Existem poucas linguagens de consulta orientadas a gráficos:
Cypher é uma linguagem de consulta para o banco de dados gráfico Neo4j (consulte a iniciativa openCypher)
Gremlin é uma linguagem de passagem gráfica da Apache Software Foundation para sistemas gráficos OLTP e OLAP.
SPARQL é uma linguagem de consulta para gráficos RDF.
Algumas das linguagens são mais baseadas em padrões e declarativas, outras são mais imperativas – todas descrevem a maneira lógica de percorrer os dados.
Vamos considerar Cypher - uma linguagem declarativa inspirada em SQL para descrever padrões em gráficos visualmente usando uma sintaxe de arte ascii.
Ele nos permite declarar o que queremos selecionar, inserir, atualizar ou excluir de nossos dados gráficos sem exigir que descrevamos exatamente como fazê-lo.
Uma vez fornecida uma consulta lógica, precisamos traduzi-la para a camada física de armazenamento de dados que é o Opensearch.
Opensearch possui uma consulta DSL focada em pesquisa e agregações – não em travessia, precisamos de uma fase de tradução adicional que levará em consideração a estrutura esquemática do gráfico (e os índices subjacentes).
A tradução de consultas lógicas para físicas é um processo que envolve algumas etapas:
validando a consulta em relação ao esquema
traduzindo os rótulos em entidades de esquema reais (índices)
criando a consulta física do Opensearch
Esse é o processo de uma revisão de alto nível, na prática – haverá mais etapas que otimizam a consulta lógica; em alguns casos é possível criar múltiplos planos físicos (planos de execução) e classificá-los de acordo com alguma estratégia de eficiência (custo), como contagem de elementos necessários para buscar...
Começamos discutindo a finalidade dos gráficos de banco de dados nos casos de uso de negócios atuais e revisamos diferentes modelos para representar um gráfico. Compreender os blocos de construção lógicos fundamentais que um potencial banco de dados gráfico deve consistir e discutir um candidato NoSql existente para atender aos requisitos da camada de armazenamento.
Depois de selecionar Opensearch como camada de armazenamento, pegamos o modelo gráfico LDBC Social Network Benchmark e o simplificamos para ser otimizado naquele armazenamento específico. Discutimos o esquema de armazenamento real com as propriedades redundantes e revisamos a linguagem cifrada para consultar o armazenamento em uma linguagem de padrão gráfico semelhante a sql.
Continuamos a ver a transformação real da consulta cifrada em uma consulta de execução física que será executada pelo Opensearch.
Na última seção, pegamos uma consulta gráfica simples e detalhamos as estratégias de execução e o mecanismo de aumento.
Tutorial de instalação:
Tutorial de criação de esquema:
Tutorial de carregamento de dados:
Consulte o tutorial do gráfico:
Tutorial de materialização e contagem de projeção:
