Banco de dados gráfico - Graph database

Na computação , um banco de dados gráfico ( GDB ) é um banco de dados que usa estruturas de gráfico para consultas semânticas com nós , arestas e propriedades para representar e armazenar dados. Um conceito chave do sistema é o gráfico (ou borda ou relacionamento ). O gráfico relaciona os itens de dados na loja a uma coleção de nós e arestas, as arestas representando as relações entre os nós. Os relacionamentos permitem que os dados na loja sejam vinculados diretamente e, em muitos casos, recuperados com uma operação. Os bancos de dados gráficos mantêm os relacionamentos entre os dados como uma prioridade. Consultar relacionamentos é rápido porque eles são armazenados perpetuamente no banco de dados. Os relacionamentos podem ser visualizados intuitivamente usando bancos de dados gráficos, tornando-os úteis para dados fortemente interconectados.

Os bancos de dados gráficos são comumente chamados de banco de dados NoSQL - o que implica que a abordagem para armazenar, consultar e descrever essas estruturas de dados difere significativamente de um banco de dados relacional tradicional . Enquanto o modelo gráfico apresenta explicitamente as dependências entre os nós de dados, o modelo relacional e outros modelos de banco de dados NoSQL vinculam os dados por conexões implícitas. Em outras palavras, os relacionamentos são cidadãos de primeira classe em um banco de dados gráfico e podem ser rotulados, direcionados e receber propriedades. Isso é comparado a abordagens relacionais em que esses relacionamentos estão implícitos e devem ser reificados em tempo de execução. Os bancos de dados de gráficos são semelhantes aos bancos de dados de modelos de rede da década de 1970, pois ambos representam gráficos gerais, mas os bancos de dados de modelos de rede operam em um nível inferior de abstração e carecem de fácil passagem por uma cadeia de arestas.

O mecanismo de armazenamento subjacente dos bancos de dados gráficos pode variar. Alguns dependem de um motor relacional e "armazenam" os dados do gráfico em uma tabela (embora uma tabela seja um elemento lógico, portanto, esta abordagem impõe outro nível de abstração entre o banco de dados de gráficos, o sistema de gerenciamento de banco de dados de gráficos e os dispositivos físicos onde os dados está realmente armazenado). Outros usam um armazenamento de valor-chave ou banco de dados orientado a documentos para armazenamento, tornando-os estruturas inerentemente NoSQL.

Em 2021, nenhuma linguagem de consulta de gráfico universal foi adotada da mesma forma que o SQL foi para bancos de dados relacionais, e há uma grande variedade de sistemas, na maioria das vezes fortemente vinculados a um produto. Alguns esforços iniciais de padronização levaram a linguagens de consulta de vários fornecedores, como Gremlin , SPARQL e Cypher . Em setembro de 2019, uma proposta de projeto para criar uma nova linguagem de consulta gráfica padrão (ISO / IEC 39075 Tecnologia da Informação - Linguagens de Banco de Dados - GQL) foi aprovada pelos membros do ISO / IEC Joint Technical Committee 1 (ISO / IEC JTC 1). GQL se destina a ser uma linguagem de consulta de banco de dados declarativa, como SQL. Além de ter interfaces de linguagem de consulta, alguns bancos de dados gráficos são acessados ​​por meio de interfaces de programação de aplicativos (APIs).

Os bancos de dados gráficos diferem dos mecanismos de computação gráfica. Bancos de dados gráficos são tecnologias que são traduções dos bancos de dados de processamento de transações online relacionais (OLTP). Por outro lado, os motores de computação gráfica são usados ​​no processamento analítico online (OLAP) para análise em massa. Os bancos de dados gráficos atraíram considerável atenção na década de 2000, devido ao sucesso de grandes corporações de tecnologia no uso de bancos de dados gráficos proprietários, junto com a introdução de bancos de dados gráficos de código aberto .

Um estudo concluiu que um RDBMS era "comparável" em desempenho aos mecanismos de análise de gráfico existentes na execução de consultas de gráfico.

História

Em meados da década de 1960, bancos de dados de navegação , como o IMS da IBM , suportavam estruturas semelhantes a árvores em seu modelo hierárquico , mas a estrita estrutura de árvore podia ser contornada com registros virtuais.

Estruturas de grafos podiam ser representadas em bancos de dados de modelos de rede do final dos anos 1960. CODASYL , que definiu o COBOL em 1959, definiu a linguagem de banco de dados de rede em 1969.

Os gráficos rotulados podiam ser representados em bancos de dados de gráficos a partir de meados da década de 1980, como o Modelo de Dados Lógicos.

Bancos de dados de objetos comerciais (ODBMSs) surgiram no início dos anos 1990. Em 2000, o Object Data Management Group publicou uma linguagem padrão para definir estruturas de objeto e relacionamento (gráfico) em sua publicação ODMG'93.

Várias melhorias nos bancos de dados de gráficos surgiram no início da década de 1990, acelerando no final da década de 1990, com esforços para indexar páginas da web.

De meados ao final dos anos 2000, bancos de dados gráficos comerciais com garantias ACID , como Neo4j e Oracle Spatial and Graph, tornaram-se disponíveis.

Na década de 2010, bancos de dados de gráficos ACID comerciais que podiam ser escalados horizontalmente tornaram-se disponíveis. Além disso, o SAP HANA trouxe tecnologias in-memory e colunares para gráficos de bancos de dados. Também na década de 2010, bancos de dados de modelos múltiplos que suportavam modelos gráficos (e outros modelos, como banco de dados relacional ou banco de dados orientado a documentos ) tornaram-se disponíveis, como OrientDB , ArangoDB e MarkLogic (começando com sua versão 7.0). Durante esse tempo, bancos de dados de gráficos de vários tipos se tornaram especialmente populares com a análise de redes sociais com o advento das empresas de mídia social.

Fundo

Bancos de dados gráficos empregam nós, propriedades e arestas.

Os bancos de dados gráficos retratam os dados conforme são visualizados conceitualmente. Isso é feito transferindo os dados para os nós e seus relacionamentos para as bordas.

Um banco de dados de gráficos é um banco de dados baseado na teoria dos grafos . Ele consiste em um conjunto de objetos, que podem ser um nó ou uma aresta.

• Os nós representam entidades ou instâncias, como pessoas, negócios, contas ou qualquer outro item a ser rastreado. Eles são aproximadamente o equivalente a um registro, relação ou linha em um banco de dados relacional ou um documento em um banco de dados de armazenamento de documentos.
• As arestas , também chamadas de gráficos ou relacionamentos , são as linhas que conectam os nós a outros nós; representando a relação entre eles. Padrões significativos surgem ao examinar as conexões e interconexões de nós, propriedades e arestas. As bordas podem ser direcionadas ou não. Em um grafo não direcionado, uma aresta conectando dois nós tem um único significado. Em um grafo direcionado, as arestas que conectam dois nós diferentes têm significados diferentes, dependendo de sua direção. Bordas são o conceito-chave em bancos de dados de gráficos, representando uma abstração que não é implementada diretamente em um modelo relacional ou modelo de armazenamento de documentos .
• Propriedades são informações associadas aos nós. Por exemplo, se a Wikipedia fosse um dos nós, ela poderia estar ligada a propriedades como site , material de referência ou palavras que começam com a letra w , dependendo de quais aspectos da Wikipedia são pertinentes a um determinado banco de dados.

Modelos de gráfico

Gráfico de propriedades rotuladas

Um modelo de gráfico de propriedade rotulada é representado por um conjunto de nós, relacionamentos, propriedades e rótulos. Ambos os nós de dados e seus relacionamentos são nomeados e podem armazenar propriedades representadas por pares de valor-chave . Os nós podem ser identificados para serem agrupados. As arestas que representam os relacionamentos têm duas qualidades: elas sempre têm um nó inicial e um nó final, e são direcionadas; tornando o gráfico um gráfico direcionado . Os relacionamentos também podem ter propriedades. Isso é útil para fornecer metadados e semânticas adicionais aos relacionamentos dos nós. O armazenamento direto de relacionamentos permite uma travessia em tempo constante .

Resource Description Framework (RDF)

Um exemplo de gráfico RDF

Em um modelo de gráfico RDF , a adição de informações é cada uma representada com um nó separado. Por exemplo, imagine um cenário em que um usuário precisa adicionar uma propriedade de nome para uma pessoa representada como um nó distinto no gráfico. Em um modelo de gráfico de propriedade rotulada, isso seria feito com a adição de uma propriedade de nome no nó da pessoa. No entanto, em um RDF, o usuário deve adicionar um nó separado chamado hasNameconectando-o ao nó pessoal original. Especificamente, um modelo de gráfico RDF é composto de nós e arcos. Uma notação de gráfico RDF ou uma declaração é representada por: um nó para o sujeito, um nó para o objeto e um arco para o predicado. Um nó pode ser deixado em branco, um literal e / ou ser identificado por um URI . Um arco também pode ser identificado por um URI. Um literal para um nó pode ser de dois tipos: simples (não tipado) e digitado. Um literal simples tem uma forma lexical e, opcionalmente, uma tag de idioma. Um literal digitado é composto de uma string com um URI que identifica um tipo de dados específico. Um nó em branco pode ser usado para ilustrar com precisão o estado dos dados quando os dados não têm um URI .

Propriedades

Os bancos de dados gráficos são uma ferramenta poderosa para consultas semelhantes a gráficos. Por exemplo, computar o caminho mais curto entre dois nós no gráfico. Outras consultas semelhantes a gráficos podem ser realizadas em um banco de dados de gráficos de maneira natural (por exemplo, cálculos de diâmetro de gráfico ou detecção de comunidade).

Os gráficos são flexíveis, o que significa que permitem ao usuário inserir novos dados no gráfico existente sem perda de funcionalidade do aplicativo. Não há necessidade de o designer do banco de dados planejar muitos detalhes dos casos de uso futuros do banco de dados.

Armazenar

O mecanismo de armazenamento subjacente dos bancos de dados gráficos pode variar. Alguns dependem de um motor relacional e "armazenam" os dados do gráfico em uma tabela (embora uma tabela seja um elemento lógico, portanto, esta abordagem impõe outro nível de abstração entre o banco de dados de gráficos, o sistema de gerenciamento de banco de dados de gráficos e os dispositivos físicos onde os dados está realmente armazenado). Outros usam um armazenamento de valor-chave ou banco de dados orientado a documentos para armazenamento, tornando-os estruturas inerentemente NoSQL . Um nó seria representado como qualquer outro armazenamento de documento, mas as arestas que ligam dois nós diferentes contêm atributos especiais dentro de seu documento; a _from e _to atributos.

Proximidade livre de índice

O desempenho da consulta de dados depende da velocidade de acesso de um nó específico para outro. Como a adjacência livre de índice força os nós a ter endereços físicos de RAM diretos e a apontar fisicamente para outros nós adjacentes, ela resulta em uma recuperação rápida. Um sistema de gráfico nativo com adjacência livre de índice não precisa se mover por nenhum outro tipo de estrutura de dados para encontrar links entre os nós. Nós diretamente relacionados em um gráfico são armazenados no cache assim que um dos nós é recuperado, tornando a pesquisa de dados ainda mais rápida do que na primeira vez que um usuário busca um nó. No entanto, essa vantagem tem um custo. A adjacência sem índice sacrifica a eficiência das consultas que não usam travessias de grafos . Os bancos de dados gráficos nativos usam adjacência livre de índice para processar operações CRUD nos dados armazenados.

Tipos de gráfico

Existem vários tipos de gráficos que podem ser categorizados. O Gartner sugere as cinco grandes categorias de gráficos:

• Gráfico social : trata das conexões entre as pessoas; exemplos incluem Facebook , Twitter e a ideia de seis graus de separação
• Gráfico de intenção: trata do raciocínio e da motivação.
• Gráfico de consumo: também conhecido como "gráfico de pagamento", o gráfico de consumo é bastante utilizado no varejo. Empresas de comércio eletrônico como Amazon, eBay e Walmart usam gráficos de consumo para rastrear o consumo de clientes individuais.
• Gráfico de interesse : mapeia os interesses de uma pessoa e geralmente é complementado por um gráfico social. Ele tem o potencial de acompanhar a revolução anterior da organização da web, mapeando a web por interesse, em vez de indexar páginas da web.
• Gráfico móvel: construído a partir de dados móveis. Os dados móveis no futuro podem incluir dados da web, aplicativos, carteiras digitais, GPS e dispositivos da Internet das Coisas (IoT).

Comparação com bancos de dados relacionais

Desde o artigo de Edgar F. Codd de 1970 sobre o modelo relacional , os bancos de dados relacionais têm sido o padrão de fato da indústria para sistemas de armazenamento de dados em grande escala. Os modelos relacionais requerem um esquema estrito e normalização de dados que separa os dados em muitas tabelas e remove quaisquer dados duplicados no banco de dados. Os dados são normalizados para preservar a consistência dos dados e oferecer suporte a transações ACID . No entanto, isso impõe limitações sobre como os relacionamentos podem ser consultados.

Uma das motivações de design do modelo relacional era conseguir um acesso rápido linha por linha. Os problemas surgem quando há necessidade de formar relacionamentos complexos entre os dados armazenados. Embora os relacionamentos possam ser analisados ​​com o modelo relacional, são necessárias consultas complexas que executam muitas operações de junção em muitos atributos diferentes em várias tabelas. Ao trabalhar com modelos relacionais, as restrições de chave estrangeira também devem ser consideradas ao recuperar relacionamentos, causando sobrecarga adicional.

Em comparação com os bancos de dados relacionais , os bancos de dados gráficos são geralmente mais rápidos para conjuntos de dados associativos e mapeiam mais diretamente para a estrutura de aplicativos orientados a objetos . Eles podem escalar mais naturalmente para grandes conjuntos de dados, pois normalmente não precisam de operações de junção , que muitas vezes podem ser caras. Como dependem menos de um esquema rígido, são comercializados como mais adequados para gerenciar dados ad hoc e variáveis ​​com esquemas em evolução.

Por outro lado, os sistemas de gerenciamento de banco de dados relacional são normalmente mais rápidos na execução da mesma operação em um grande número de elementos de dados, permitindo a manipulação dos dados em sua estrutura natural. Apesar das vantagens dos bancos de dados de gráficos e da popularidade recente sobre os bancos de dados relacionais, é recomendável que o modelo de gráfico em si não seja o único motivo para substituir um banco de dados relacional existente. Um banco de dados gráfico pode se tornar relevante se houver uma evidência de melhoria de desempenho em ordens de magnitude e menor latência.

Exemplos

O modelo relacional reúne dados usando informações nos dados. Por exemplo, pode-se procurar todos os "usuários" cujo número de telefone contém o código de área "311". Isso seria feito pesquisando os armazenamentos de dados selecionados, ou tabelas , procurando nos campos de número de telefone selecionados pela string "311". Este pode ser um processo demorado em tabelas grandes, portanto, os bancos de dados relacionais oferecem índices , que permitem que os dados sejam armazenados em uma subtabela menor, contendo apenas os dados selecionados e uma chave exclusiva (ou chave primária) do registro. Se os números de telefone forem indexados, a mesma pesquisa ocorreria na tabela de índice menor, reunindo as chaves dos registros correspondentes e, em seguida, procurando na tabela de dados principal os registros com essas chaves. Normalmente, uma tabela é armazenada de uma maneira que permite que uma pesquisa por meio de uma chave seja muito rápida.

Os bancos de dados relacionais não contêm inerentemente a ideia de relacionamentos fixos entre os registros. Em vez disso, os dados relacionados são vinculados entre si, armazenando a chave exclusiva de um registro nos dados de outro registro. Por exemplo, uma tabela contendo endereços de e-mail para usuários pode conter um item de dados chamado userpk, que contém a chave primária do registro do usuário ao qual está associado. Para vincular usuários e seus endereços de e-mail, o sistema primeiro procura as chaves primárias dos registros do usuário selecionados, procura essas chaves na userpkcoluna da tabela de e-mail (ou, mais provavelmente, um índice delas), extrai os dados do e-mail, e vincula os registros do usuário e do e-mail para criar registros compostos contendo todos os dados selecionados. Essa operação, chamada de junção , pode ser cara em termos computacionais. Dependendo da complexidade da consulta, do número de junções e da indexação de várias chaves, o sistema pode ter que pesquisar várias tabelas e índices e, em seguida, classificar tudo para combiná-los.

Em contraste, os bancos de dados gráficos armazenam diretamente os relacionamentos entre os registros. Em vez de um endereço de e-mail ser encontrado procurando a chave de seu usuário na userpkcoluna, o registro do usuário contém um ponteiro que se refere diretamente ao registro do endereço de e-mail. Ou seja, tendo selecionado um usuário, o ponteiro pode ser seguido diretamente para os registros de e-mail, não há necessidade de pesquisar a tabela de e-mail para encontrar os registros correspondentes. Isso pode eliminar as caras operações de junção. Por exemplo, se alguém pesquisar todos os endereços de e-mail de usuários no código de área "311", o mecanismo primeiro executará uma pesquisa convencional para encontrar os usuários em "311", mas depois recuperará os endereços de e-mail seguindo os links encontrados em esses registros. Um banco de dados relacional primeiro encontraria todos os usuários em "311", extrairia uma lista das chaves primárias, realizaria outra pesquisa por quaisquer registros na tabela de e-mail com essas chaves primárias e vincularia os registros correspondentes. Para esses tipos de operações comuns, os bancos de dados gráficos seriam teoricamente mais rápidos.

O verdadeiro valor da abordagem do gráfico torna-se evidente quando se realiza pesquisas com mais de um nível de profundidade. Por exemplo, considere uma pesquisa por usuários que possuem "assinantes" (uma tabela que vincula usuários a outros usuários) no código de área "311". Nesse caso, um banco de dados relacional deve primeiro pesquisar todos os usuários com um código de área em "311", depois pesquisar na tabela de assinantes qualquer um desses usuários e, finalmente, pesquisar na tabela de usuários para recuperar os usuários correspondentes. Em contraste, um banco de dados de gráficos procuraria todos os usuários em "311" e, em seguida, seguiria os backlinks através do relacionamento do assinante para encontrar os usuários assinantes. Isso evita várias pesquisas, consultas e o uso de memória envolvido na retenção de todos os dados temporários de vários registros necessários para construir a saída. Em termos de notação grande O , essa consulta seria o tempo - ou seja, proporcional ao logaritmo do tamanho dos dados. Em contraste, a versão relacional seria várias pesquisas, mais o tempo necessário para unir todos os registros de dados. ${\ displaystyle O (\ log n) + O (1)}$${\ displaystyle O (\ log n)}$

A vantagem relativa da recuperação de gráfico aumenta com a complexidade de uma consulta. Por exemplo, alguém pode querer saber "aquele filme sobre submarinos com o ator que estava naquele filme com aquele outro ator que interpretou o papel principal em E o Vento Levou ". Isso requer primeiro que o sistema encontre os atores de E o Vento Levou , encontre todos os filmes em que eles participaram, encontre todos os atores de todos os filmes que não foram o protagonista de E o Vento Levou e, em seguida, encontre todos os filmes eles estavam, finalmente filtrando essa lista para aqueles com descrições contendo "submarino". Em um banco de dados relacional, isso exigiria várias pesquisas separadas nos filmes e tabelas de atores, fazer outra pesquisa em filmes submarinos, encontrar todos os atores nesses filmes e, em seguida, comparar os (grandes) resultados coletados. Em contraste, o banco de dados de gráficos iria de E o Vento Levou a Clark Gable , reuniria os links para os filmes em que ele esteve, reuniria os links desses filmes para outros atores e, em seguida, seguiria os links desses atores de volta para a lista de filmes. A lista de filmes resultante pode então ser pesquisada por "submarino". Tudo isso pode ser feito por meio de uma pesquisa.

As propriedades adicionam outra camada de abstração a essa estrutura, o que também melhora muitas consultas comuns. As propriedades são essencialmente rótulos que podem ser aplicados a qualquer registro ou, em alguns casos, também às bordas. Por exemplo, pode-se rotular Clark Gable como "ator", o que permitiria ao sistema localizar rapidamente todos os registros que são atores, em oposição ao diretor ou operador de câmera. Se rótulos nas bordas forem permitidos, também se pode rotular a relação entre E o Vento Levou e Clark Gable como "principal", e realizando uma pesquisa sobre as pessoas que são "atores" "principais" no filme E o Vento Levou , o O banco de dados produziria Vivien Leigh , Olivia de Havilland e Clark Gable. A consulta SQL equivalente teria que contar com dados adicionados na tabela que vincula pessoas e filmes, adicionando mais complexidade à sintaxe da consulta. Esses tipos de rótulos podem melhorar o desempenho da pesquisa em certas circunstâncias, mas geralmente são mais úteis para fornecer dados semânticos adicionais para os usuários finais.

Os bancos de dados relacionais são muito adequados para layouts de dados simples, onde os relacionamentos entre os dados têm um ou dois níveis de profundidade. Por exemplo, um banco de dados de contabilidade pode precisar pesquisar todos os itens de linha de todas as faturas de um determinado cliente, uma consulta de três junções. Os bancos de dados gráficos são direcionados a conjuntos de dados que contêm muitos mais links. Eles são especialmente adequados para sistemas de rede social , onde o relacionamento de "amigos" é essencialmente ilimitado. Essas propriedades tornam os bancos de dados gráficos naturalmente adequados para tipos de pesquisas que são cada vez mais comuns em sistemas online e em ambientes de big data . Por esse motivo, os bancos de dados gráficos estão se tornando muito populares para grandes sistemas online como Facebook , Google , Twitter e sistemas semelhantes com links profundos entre registros.

Para ilustrar ainda mais, imaginar um modelo relacional com duas tabelas: uma peoplemesa (que tem um person_ide person_namecoluna) e uma friendmesa (com friend_ide person_id, o que é uma chave estrangeira da peopletabela). Nesse caso, pesquisar todos os amigos de Jack resultaria na seguinte consulta SQL.

SELECT p2.person_name 
FROM people p1 
JOIN friend ON (p1.person_id = friend.person_id)
JOIN people p2 ON (p2.person_id = friend.friend_id)
WHERE p1.person_name = 'Jack';

A mesma consulta pode ser traduzida em -

• Cypher , uma linguagem de consulta de banco de dados de gráficos

  MATCH (p1:person {name: 'Jack'})-[:FRIEND_WITH]-(p2:person)
  RETURN p2.name
  

• SPARQL , uma linguagem de consulta de banco de dados de gráfico RDF padronizada pelo W3C e usada em várias lojas RDF Triple e Quad
  • Forma longa

    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    
    SELECT ?name
    WHERE { ?s a          foaf:Person . 
            ?s foaf:name  "Jack" . 
            ?s foaf:knows ?o . 
            ?o foaf:name  ?name . 
          }
    

  • Forma curta

    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    
    SELECT ?name
    WHERE { ?s foaf:name     "Jack" ;
               foaf:knows    ?o .
               ?o foaf:name  ?name .
          }
    

• SPASQL, uma linguagem de consulta de banco de dados híbrido, que estende SQL com SPARQL

  SELECT people.name
  FROM (
         SPARQL PREFIX foaf: <http://xmlns.com/foaf/0.1/>
                SELECT ?name
                WHERE { ?s foaf:name  "Jack" ; 
                           foaf:knows ?o .
                        ?o foaf:name  ?name .
                      }
      ) AS people ;
  

Os exemplos acima são uma ilustração simples de uma consulta básica de relacionamento. Eles condensam a ideia da complexidade da consulta dos modelos relacionais que aumenta com a quantidade total de dados. Em comparação, uma consulta de banco de dados de gráfico é facilmente capaz de classificar o gráfico de relacionamento para apresentar os resultados.

Também há resultados que indicam que consultas simples, condensadas e declarativas dos bancos de dados de gráficos não necessariamente fornecem bom desempenho em comparação com os bancos de dados relacionais. Enquanto os bancos de dados gráficos oferecem uma representação intuitiva dos dados, os bancos de dados relacionais oferecem melhores resultados quando as operações de conjunto são necessárias.

Lista de bancos de dados gráficos

A seguir está uma lista de bancos de dados de gráficos notáveis :

Linguagens de programação de consulta gráfica

• AQL (ArangoDB Query Language) : uma linguagem de consulta semelhante a SQL usada em ArangoDB para documentos e gráficos
• Cypher Query Language (Cypher): uma linguagem declarativa de consulta de gráfico para Neo4j que permite acesso ad hoc e programático (semelhante a SQL) ao gráfico.
• GQL : linguagem de consulta gráfica padrão ISO proposta
• GSQL : uma linguagem Turing completa de consulta de gráfico semelhante a SQL projetada e oferecida pela TigerGraph
• GraphQL : uma consulta de dados de código aberto e linguagem de manipulação para APIs. Dgraph implementa linguagem GraphQL modificada chamada DQL (anteriormente GraphQL + -)
• Gremlin : uma linguagem de programação de gráfico que faz parte do projeto de código aberto Apache TinkerPop
• SPARQL : uma linguagem de consulta para bancos de dados RDF que podem recuperar e manipular dados armazenados no formato RDF

Veja também

• Transformação de gráfico
• Modelo de banco de dados hierárquico
• Registro de dados
• Banco de dados de objetos
• Banco de dados RDF
• Armazenamento estruturado
• Gráfico de texto

Referências