Advertisement
O que você precisa saber para modelar bancos de dados NoSQL - Dani Monteiro
Report
iMastersFollow
jornalista, web editor, web writer, tradutora (en-pt/pt-en) at iMastersMay. 21, 2019•0 likes•1,363 views
1 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Check these out next
![M20_Azure SQL Database 最新アップデートをまとめてキャッチアップ [Microsoft Japan Digital Days]](https://cdn.slidesharecdn.com/ss_thumbnails/m20azuresqldatabase-211027133338-thumbnail.jpg?width=600&height=600&fit=bounds)
O que você precisa saber para modelar bancos de dados NoSQL - Dani Monteiro
May. 21, 2019•0 likes•1,363 views
1 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Technology
Banco de dados sem schema não precisa de modelo de dados!” Se você acredita nisso, seu projeto começou a falhar antes de começar! Vamos conversar sobre como modelar seu banco de dados NoSQL sem perder a flexibilidade e sem perder o controle sobre seus dados.
iMastersFollow
jornalista, web editor, web writer, tradutora (en-pt/pt-en) at iMastersAdvertisement
Advertisement
Advertisement
Recommended
Azure Blueprints - 企業で期待される背景と特徴、活用方法Toru Makabe
新機能によるデータベースシステムの改善ポイントオラクルエンジニア通信
Introdução a Bancos de DadosRicardo Flores Zago, PMP, MSc
Oracle GoldenGate DB2 to Oracle11gR2 Configurationgrigorianvlad
IT エンジニアのための 流し読み Windows 10 - Microsoft Defender ウイルス対策TAKUYA OHTA
Zero Data Loss Recovery Applianceによるデータベース保護のアーキテクチャオラクルエンジニア通信
O que você precisa saber para modelar bancos de dados NoSQL - Dani Monteiro
- O que você precisa saber para modelar bancos de dados NoSQL
- Danielle Monteiro DB4Beginners.com/e-book twitter.com/danimonteirodba facebook.com/DB4Beginners www.linkedin.com/in/danimonteirodba WBSoft.com.br 2
- Contatos /DB4Beginners /DaniMonteiroDBA /DaniMonteiroDBA http://bit.ly/db-sp http://bit.ly/danimonteirodba www.linkedin.com/in/danimonteirodba/
- Sites × Portfólio: www.DaniMonteiroDBA.com × Blog: DB4Beginners.com × Consultoria: www.WDB.Consulting × Meetup: https://www.meetup.com/pt- BR/Databases-SP/ × Projeto: www.WoMakersCode.org
- O que é Modelagem? 5
- 6
- 7 1. Key Value REmote DIctionary Server
- REDIS 8 × Muito rápido; × O key-value mais usado; × Dados em memória; × Entenda como serão as pesquisas;
- Tipo de dados 9 × string × list (acesso nas pontas mais rápido) × set (coleção de strings) × sorted set (coleção de strings ordenadas) × hash (chaves e conteúdos string)
- 10
- Quais as melhores chaves? 11
- Dicas 12 × Lembre-se que a pesquisa é feita pela chave × É a base de dados principal? (sim, é possível!) × Cuidado com a redundância × list -> filas × sorted set -> notícias, tweets… ordem temporal. × hash -> dados genéricos de forma compactada
- 2. Orientado a Documentos MongoDB, o difícil é que é fácil! 13
- MongoDB × Consolidado; × Multi-model? × Muitos recursos; × Documentos tem o formato JSON; × Dados podem ser normalizados; × Dados podem ser desnormalizados; 14
- Tipos de Dados × Documento armazenado em formato BSON × Data, string, ObjectID, NumberLong, NumberInt, NumberDecimal, Object, Array… × Tuning começa com o data type correto. 16
- Embeding (Desnormalizado) X Referencing (Normalizado)? 17
- 18
- Quando usar documentos Embeded? • Relacionamentos 1:1 • Relacionamentos 1:n • Entre uma entidade fraca e uma entidade forte • Coleções que contém um número grande de documentos pequenos • Dados que são lidos sempre juntos • Mais leituras 19
- 20
- Quando usar documentos Referencing? • Quando uma parte do documento é frequentemente lida/ atualizada e a outra parte não. • O tamanho do documento excede 16MB. • Quando os dados não devem ser duplicados! • Quando um objeto é referenciado em muitos outros • Mais escritas 21
- Informações importantes • Possui linguagem própria • Suporte a vários tipos de índice • Governança facilitada com a validação de schemas nativa • Lembre da LGPD!!! • Podemos ter grafos no MongoDB 22
- 23 3. Orientado a colunas Cassandra!!!
- Cassandra 24 × Desnormalizado; × Distribuído; × Tolerante a falhas; × Abordagem orientada a consultas; × Schema é muito importante; × Design anel; × master/ master; × Escalabilidade linear
- Conceitos importantes × Keyspace × Onde definimos o fator de replicação × Família de Colunas × Contém colunas × Contém linhas × Separação lógica de dados semelhantes × Colunas × Estrutura básica × nome, valor e timestamp. 25
- 26
- CQL (Cassandra Query Language) × Baseada na SQL; × 21 datatypes nativos; × Alguns interessantes: counter, inet, uuid 28
- Índices × Melhores em tabelas grandes; × Índices secundários: × Podem destruir o desempenho da sua query; × Complexos; × Criados em background (default), sem bloquear leituras ou gravações; 29
- Primary Key × Identifica uma coluna × Primeiro elemento é a chave da partição × Determina a localização dos dados × Colunas depois da chave de partição são chamadas de clustering columns × As clustering columns especifica a ordem em que os dados são organizados dentro da partição. 30
- 31 1 2 3 4 5 6 7 8 CREATE TABLE user_videos ( userid uuid, added_date timestamp, videoid uuid, name text, preview_image_location text, PRIMARY KEY (userid, added_date, videoid) ); Mostre-me todos os vídeos associados a um determinado usuário
- 32
- Qual é a query? 33
- 4. Orientado a Grafos Neo4J, poderoso nos relacionamentos! 35
- Neo4J × Projetado para tratar as relações entre os dados; × Pesquisas em grandes quantidades de dados; × Ideal para consultas complexas; × Desempenho muito bom; × Compatível com ACID; × Cypher 36
- Conceitos Importantes × Nodes = entidades × Relacionamentos = eventos ou conceitos que relacionam nós × os relacionamentos são especificados na inclusão, não tem JOIN 37
- Índices • Encontrar o ponto de partida para consultas • Busca mais eficiente • Escritas mais lentas 39
- Como as informações estão conectadas? 40
- 41
- 42
- Casos de Uso • Sistemas de Recomendação • Detecção de fraudes • Operações de redes • Mecanismos de busca • Machine learning 43
- DB4Beginners.com 44
Editor's Notes
- A modelagem de dados é um processo de abstração. Você começa com suas necessidades de negócios (ou seja, o que você deseja que seu aplicativo faça). Então, no processo de modelagem, você mapeia essas necessidades em uma estrutura para armazenar e organizar seus dados A modelagem de dados é um processo que envolve a identificação de entidades (itens a serem armazenados) e as relações entre entidades. Para criar seu modelo de dados, identifique os padrões usados para acessar os dados e os tipos de consultas a serem realizadas. O primeiro passo é sempre entender o seu dado Desenhe rabisque, veja as relações, use um diagrama UML ou E-R para ver as desnormalizações, disponibilize os diagramas para a sua equipe, documente… Os dados devem manter-se consistentes Avalie as operações e as queries Entenda o cenário de negócio Considere o aumento da complexidade da infra estrutura (há casos onde a infra é um fator importante para o seu modelo)
- A modelagem de dados é um processo de abstração. Você começa com suas necessidades de negócios (ou seja, o que você deseja que seu aplicativo faça). Então, no processo de modelagem, você mapeia essas necessidades em uma estrutura para armazenar e organizar seus dados A modelagem de dados é um processo que envolve a identificação de entidades (itens a serem armazenados) e as relações entre entidades. Para criar seu modelo de dados, identifique os padrões usados para acessar os dados e os tipos de consultas a serem realizadas. O primeiro passo é sempre entender o seu dado Desenhe rabisque, veja as relações, use um diagrama UML ou E-R para ver as desnormalizações, disponibilize os diagramas para a sua equipe, documente… Os dados devem manter-se consistentes Avalie as operações e as queries Entenda o cenário de negócio Considere o aumento da complexidade da infra estrutura (há casos onde a infra é um fator importante para o seu modelo)
- Os valores não sao pesquisados quando optamos por usar o redis, por isso a grande decisão de modelagem envolve escolher quais são as chaves adequadas para as nossas pesquisas Depois de decidir quais são as chaves, é preciso escolher o retorno mais adequado para as consultas
- modelagem de dados é uma das áreas mais complexas de uso da Cassandra e tem muitas considerações. Para um negócio, é essencial investir recursos na modelagem de dados desde os primeiros estágios dos projetos de Cassandra; Ao contrário das configurações operacionais que podem ser ajustadas, um modelo de dados Cassandra é muito caro para consertar. Sem entender a arquitetura subjacente, você arrisca fazer com que um dos erros comuns de Cassandra seja abordado em uma publicação separada. Avaliar um modelo de dados aparentemente válido e direto para possíveis armadilhas exige um nível de especialização em aplicações internas de Cassandra, o formato de armazenamento em particular. Ao projetar um modelo de dados Cassandra para um aplicativo, primeiro considere as entidades comerciais que você está armazenando e as relações entre eles. Seu objetivo final será armazenar respostas pré computadas a questões de negócios que a aplicação pergunte sobre os dados armazenados, uma compreensão de sua estrutura e significado é uma condição prévia para modelar essas respostas.
- 1. Cassandra Performance Cassandra suporta um rendimento muito alto. Em particular, o de gravação de Cassandra permite gravações robustas e de alto desempenho. 2. Elasticidade Cassandra é horizontalmente escalável. O desempenho e a capacidade de leitura / gravação são lineares conforme o novo hardware é adicionado. Adicionar novo hardware não requer tempo de inatividade ou interrupção para os consumidores. 3. Tolerância a falhas A Cassandra não possui um único ponto de falha. Cada nó no cluster é idêntico e pode ser executado em hardware de mercadorias. Não existe um servidor mestre. 4. Os Dados de Resiliência são replicados automaticamente para múltiplos nós - que podem ser cross-rack (ou zona de disponibilidade de nuvem) e cross-datacenter. Isso pode ser usado para garantir alta disponibilidade em regiões geográficas. 5. Flexibilidade Cassandra usa colunas para armazenar dados dentro de linhas, pois as linhas podem ser de comprimento diferente, ou seja, têm diferentes números de colunas por linha, isso leva a linhas tão amplas como os dados nelas e os usuários têm a capacidade de alterar o esquema em tempo de execução . Com consistência ajustável em uma operação de gravação por leitura , a replicação e as garantias de consistência de gravação de leitura podem ser ajustadas para velocidade ou confiabilidade para cada consulta. 6. Familiarizado SQL-como linguagem de consulta CQL a Cassandra Query Language é sintaticamente semelhante ao SQL, simplificando o de integração dos desenvolvedores de SQL. O Apache Cassandra ™, um projeto Apache de nível superior, nascido no Facebook e construído no Dynamo da Amazon e no BigTable do Google , é um banco de dados distribuído para gerenciar grandes quantidades de dados estruturados em vários servidores de commodities, ao mesmo tempo em que oferece um serviço altamente disponível e nenhum ponto de falha. O Apache Cassandra ™ oferece recursos que os bancos de dados relacionais e outros bancos de dados NoSQL simplesmente não podem corresponder, tais como: disponibilidade contínua, desempenho de escala linear, simplicidade operacional e fácil distribuição de dados em vários centros de dados e zonas de disponibilidade de nuvem. A arquitetura do Apache Cassandra ™ é responsável por sua capacidade de dimensionar, executar e oferecer tempo de atividade contínuo. Ao invés de usar um mestre-escravo legado ou uma arquitetura cortada manual e difícil de manter, o Apache Cassandra ™ possui um design de "anel" sem mestre que é elegante, fácil de configurar e fácil de manter. No Apache Cassandra ™, todos os nós desempenham um papel idêntico; não existe um conceito de nó mestre, com todos os nós comunicados uns com os outros igualmente. A arquitetura construída para escala da Apache Cassandra ™ significa que é capaz de lidar com grandes quantidades de dados e milhares de usuários simultâneos ou operações por segundo, mesmo em vários centros de dados, tão facilmente quanto pode gerenciar quantidades muito menores de dados e tráfego do usuário. A arquitetura do Apache Cassandra ™ também significa que, ao contrário de outros sistemas mestre-escravos ou trançados, não possui um único ponto de falha e, portanto, é capaz de oferecer uma verdadeira disponibilidade contínua e tempo de atividade - simplesmente adicione novos nós a um cluster existente sem ter que levar para baixo. Muitas empresas implementaram e se beneficiaram com o Apache Cassandra ™, incluindo algumas grandes empresas, como: Apple , Comcast , eBay , Instagram , Spotify , Uber , Netflix e muito mais. Os ambientes de produção maiores possuem PB's de dados em clusters de mais de 75.000 nós. O Apache Cassandra ™ está disponível sob a licença Apache 2.0. A modelagem de dados em Cassandra usa uma abordagem orientada por consulta, na qual consultas específicas são a chave para organizar os dados. O projeto de banco de dados da Cassandra baseia-se no requisito de leituras e gravações rápidas, por isso, quanto melhor for o design do esquema, os dados mais rápidos são escritos e recuperados.
- Modelo de dados O modelo de dados de Cassandra é diferente do de um SGBD relacional. Cassandra não suporta associações ou subconsultas para as quais há suporte em um RDBMS. Em vez disso, Cassandra enfatiza a desnormalização através de recursos como coleções. Cassandra é basicamente um banco de dados de valor-chave e uma coluna (ou tabular). As fileiras são organizadas em tabelas; O primeiro componente da chave primária de uma tabela é a chave de partição, e dentro de uma partição, as linhas são agrupadas pelas restantes colunas da chave. Outras colunas podem ser indexadas separadamente da chave primária. O modelo de dados Cassandra consiste em espaço de chaves, famílias de colunas, colunas e linhas. Keyspace:O espaço de chaves é o recipiente mais externo para os dados do seu aplicativo. É semelhante ao esquema em um banco de dados relacional. O espaço de teclas pode incluir elementos operacionais, como o fator de replicação e a conscientização do centro de dados. É um grupo de muitas famílias de colunas. Família de colunas: uma família de colunas é um recipiente para uma coleção ordenada de linhas, cada uma das quais é uma coleção de colunas ordenada. Uma família de colunas é semelhante a uma tabela no RDBMS e é uma separação lógica de dados semelhantes. Coluna: é uma estrutura básica de dados de Cassandra com três valores - nome, valor e timestamp. Super coluna: uma super coluna armazena um mapa de sub-colunas. Row: Esta é uma coleção de colunas rotuladas com um nome.
- 1. Visão Geral Cassandra é um banco de dados NoSQL que oferece alta disponibilidade e escalabilidade horizontal sem comprometer o desempenho. Para obter o melhor desempenho de Cassandra, precisamos desenhar cuidadosamente o esquema em torno de padrões de consulta específicos para o problema comercial em mãos. Neste artigo, analisaremos alguns dos conceitos-chave sobre como abordar o modelamento de dados em Cassandra . Antes de prosseguir, você pode passar pelo nosso artigo Cassandra com Javapara entender os conceitos básicos e como se conectar a Cassandra usando o Java. 2. Tecla de partição Cassandra é um banco de dados distribuído em que os dados são particionados e armazenados em vários nós dentro de um cluster. A chave de partição é composta por um ou mais campos de dados e é usada pelo particionador para gerar um token via hash para distribuir os dados uniformemente em um cluster . 3. Clustering Key Uma chave de agrupamento é composta por um ou mais campos e ajuda a agrupar ou agrupar linhas com a mesma chave de partição e armazená-las em ordem ordenada. Digamos que estamos armazenando dados da série temporal em Cassandra e queremos recuperar os dados em ordem cronológica. Uma chave de cluster que inclua campos de dados da série temporal será muito útil para uma recuperação eficiente de dados para este caso de uso. Nota: A combinação de chave de partição e chave de cluster compõe a chave primária e identifica de forma exclusiva qualquer registro no cluster Cassandra. 4. Diretrizes em torno de padrões de consulta Antes de começar com a modelagem de dados em Cassandra, devemos identificar os padrões de consulta e garantir que eles aderem às seguintes diretrizes: . Cada consulta deve buscar dados de uma única partição . Devemos acompanhar a quantidade de dados que está sendo armazenado em uma partição, já que Cassandra tem limites em torno do número de colunas que podem ser armazenadas em uma única partição . É bom desnormalizar e duplicar os dados para suportar diferentes tipos de padrões de consulta ao longo dos mesmos dados Com base nas diretrizes acima, vejamos alguns casos de uso do mundo real e como modelaremos os modelos de dados da Cassandra para eles.
- counter - integer - Coluna do contador (valor assinado de 64 bits). Veja Contadores para detalhes inet - string - Um endereço IP, IPv4 (4 bytes de comprimento) ou IPv6 (16 bytes de comprimento). Observe que não háinetconstante, o endereço IP deve ser inserido como cordas uuid - uuid - A UUID (de qualquer versão) UUID = Um identificador universalmente exclusivo ( UUID ) é um número de 128 bits usado para identificar informações em sistemas de computador. O termo identificador exclusivo global ( GUID ) também é usa
- Usando o CQL, você pode criar um índice em uma coluna depois de definir uma tabela. Você também pode indexar uma coluna de coleção . Os índices secundários são usados para consultar uma tabela usando uma coluna que normalmente não é questionável. Os índices secundários são difíceis de usar e podem afetar o desempenho de forma muito significativa. A tabela de índice é armazenada em cada nó em um cluster, de modo que uma consulta envolvendo um índice secundário pode tornar-se rapidamente um pesadelo de desempenho se forem acessados múltiplos nós. Uma regra geral é indexar uma coluna com baixa cardinalidade de poucos valores. Antes de criar um índice, esteja ciente de quando e quando não criar um índice . Quando usar um índice Os índices internos do Apache Cassandra ™ são melhores em uma tabela com muitas linhas que contêm o valor indexado. Os valores mais exclusivos que existem em uma coluna específica, quanto mais gastos gerais você terá, em média, para consultar e manter o índice. Por exemplo, suponha que você tivesse uma lista de listas de reprodução com um bilhão de músicas e queria procurar músicas pelo artista. Muitas músicas vão compartilhar o mesmo valor de coluna para o artista. A coluna do artista é um bom candidato para um índice. Quando não usar um índice Não use um índice nessas situações: • Em colunas de cardinalidade alta porque você consulta um enorme volume de registros por um pequeno número de resultados. Consulte Problemas usando um índice de coluna de alta cardinalidade abaixo. • Em tabelas que usam uma coluna contadora • Em uma coluna freqüentemente atualizada ou excluída. Consulte Problemas usando um índice em uma coluna freqüentemente atualizada ou excluída abaixo. • Para procurar uma linha em uma partição grande, a menos que seja consultada. Consulte Problemas usando um índice para procurar uma linha em uma partição grande, a menos que seja consultado de forma restrita abaixo.
- O primeiro elemento da nossa PRIMARY KEY é o que chamamos de chave de partição. A chave de partição tem um uso especial no Apache Cassandra além de mostrar a singularidade da gravação no banco de dados. O outro propósito, e aquele que é muito crítico em sistemas distribuídos, é determinar a localidade de dados. Quando os dados são inseridos no cluster, o primeiro passo é aplicar uma função hash à chave de partição. O resultado é usado para determinar o nó (e as réplicas) que receberão os dados. O algoritmo usado por Apache Cassandra utiliza Murmur3, que terá uma entrada arbitrária e criará um valor token consistente. Esse valor token estará dentro do alcance de tokens de um único nó. Em termos mais simples, uma chave de partição sempre pertencerá a um nó e os dados dessa partição sempre serão encontrados nesse nó. Por que isso é importante? Se não houvesse uma localização absoluta dos dados de uma partição, seria necessário pesquisar todos os nós no cluster para seus dados. Em um pequeno cluster, isso pode completar rapidamente, mas em um cluster muito maior, seria dolorosamente lento. Queremos o que é mostrado abaixo.
- Nesta tabela, estamos satisfazendo a consulta "mostre-me todos os vídeos associados a um usuário específico". Como você pode ver, a PRIMARY KEY agora tem mais do que a chave de partição, agora adicionamos mais elementos. Todas as colunas listadas após a chave de partição são chamadas de colunas de agrupamento. Aqui é onde nós tomamos uma grande ruptura com bancos de dados relacionais. Onde a chave de partição é importante para localidade de dados, a coluna de agrupamento especifica a ordem em que os dados são organizados dentro da partição. A maneira como lemos isso é da esquerda para a direita: O item um é a chave de partição O item dois é uma coluna de agrupamento. Adicionado_date é um timestamp para que a ordem de classificação seja cronológica, ascendente. O item três é uma coluna de agrupamento. Como o videoid é um UUID, nós estámos incluindo, simplesmente, a maioria dos quais é parte de um registro exclusivo. Após uma inserção de dados, você deve esperar que o SELECIONE os dados em ordem ascendente do add_date para uma única partição em ordem crescente.
- A modelagem de dados em Cassandra usa uma abordagem orientada por consulta, na qual consultas específicas são a chave para organizar os dados. As consultas são o resultado da seleção de dados de uma tabela; esquema é a definição de como os dados na tabela são organizados. O projeto de banco de dados da Cassandra baseia-se no requisito de leituras e gravações rápidas, por isso, quanto melhor for o design do esquema, os dados mais rápidos são escritos e recuperados. O modelo de dados de Cassandra é um armazenamento de filas particionado com consistência ajustável. A consistência ajustável significa para qualquer operação de leitura ou gravação dada, o aplicativo cliente decide a consistência dos dados solicitados. As fileiras são organizadas em tabelas; Como Cassandra é um banco de dados distribuído, a eficiência é obtida para lê e grava quando os dados são agrupados em nós por partição. Menos partições que devem ser consultadas para obter uma resposta a uma pergunta, mais rápida é a resposta. Ajustar o nível de consistência é outro fator em latência, Você criou um modelo conceitual das entidades e seus relacionamentos. Do modelo conceitual, você usou as consultas esperadas para criar um esquema de tabela. A última etapa no modelo de dados envolve a conclusão de uma análise do design lógico para descobrir modificações que podem ser necessárias. Essas modificações podem surgir da compreensão das limitações do tamanho da partição, do custo da consistência dos dados e dos custos de desempenho devido a uma série de opções de design ainda a serem feitas. A redundância de dados também deve ser considerada. Duas redundâncias que são uma conseqüência do design distribuído de Cassandra são dados duplicados em tabelas e repetições de partições múltiplas. Os dados geralmente são duplicados em várias tabelas, resultando em latência de desempenho durante as gravações e requer mais espaço em disco. Você deve repensar o esquema da tabela para um melhor design, mantendo a consulta em primeiro lugar. Não tem join no cassandra Objetivos básicos da modelagem com o Cassandra: 1. Distribua dados uniformemente em torno do cluster 2. Minimize o número de partições lidas O segredo é alcançar o equilíbrio entre os 2 objetivos
- Vivemos em um mundo conectado! Não há informações isoladas, mas ricos, domínios conectados ao nosso redor. Apenas um banco de dados que abraça nativamente relacionamentos é capaz de armazenar, processar e consultar conexões de forma eficiente. Enquanto outros bancos de dados calculam os relacionamentos no horário de consulta através de operações JOIN caras, um banco de dados gráfico armazena conexões como cidadãos de primeira classe. Independente do tamanho total do seu conjunto de dados, os bancos de dados do gráfico são excelentes no gerenciamento de dados altamente conectados e consultas complexas. Armados apenas com um padrão e um conjunto de pontos de partida, os bancos de dados de gráficos exploram o bairro maior em torno dos pontos de partida iniciais - coletando e agregando informações de milhões de nós e relacionamentos - deixando intocados os bilhões fora do perímetro de pesquisa. O Neo4j é um banco de dados nativo do NoSQL de código aberto que fornece um backend transacional compatível com ACID para seus aplicativos. Com o desenvolvimento a partir de 2003, está disponível publicamente desde 2007. O código-fonte, escrito em Java e Scala, está disponível no GitHub , com uma comunidade próspera no Neo4j Slack e StackOverflow . Neo4j é referido como um banco de dados de gráfico nativo porque implementa o Property Graph Model eficientemente até o nível de armazenamento. Em oposição ao processamento de gráficos ou bibliotecas na memória, o Neo4j fornece características completas de banco de dados, incluindo conformidade de transações ACID, suporte de cluster e failover de tempo de execução, tornando-o adequado para usar dados de gráficos em cenários de produção . Cypher , uma linguagem de consulta declarativa semelhante ao SQL, mas otimizada para gráficos. Agora usado por outros bancos de dados, como o gráfico SAP HANA Graph e Redis, através do projeto openCypher . ◦ Percursos de tempo constante em grandes gráficos tanto em profundidade quanto em amplitude devido à representação eficiente de nós e relacionamentos. Permite escalar até bilhões de nós em hardware moderado. ◦ Esquema de gráfico de propriedade flexível que pode se adaptar ao longo do tempo, permitindo materializar e usar novos relacionamentos mais tarde para "atalho" e acelerar os dados de domínio quando a empresa precisa mudar. ◦ Drivers para linguagens de programação populares, incluindo Java, JavaScript, .NET e Python. Livre e de código aberto do Neo4j Comunidade edição é um alto desempenho, totalmente banco de dados ACID-transacional. A edição da Comunidade inclui (mas não está limitado a) toda a funcionalidade descrita anteriormente nesta seção. As edições corporativas do Neo4j oferecem todas as funcionalidades da edição da Comunidade, além de agrupamentos escaláveis, fail-over, alta disponibilidade, backups em tempo real e monitoramento abrangente O conceito bem conhecido e testado de transações agrupa um conjunto de atualizações de nós e relacionamentos em uma operação atômica, consistente, isolada e durável (ACID). Os bancos de dados gráficos como o Neo4j suportam totalmente os conceitos transacionais, incluindo logs de gravação contínua e recuperação após término anormal. Então você nunca perde seus dados que tenham sido cumpridos com o banco de dados.
- Os nós são as entidades no gráfico. Eles podem conter qualquer número de atributos (chave-valor-pares) chamados de propriedades . Os nós podem ser marcados com rótulos que representam suas diferentes funções em seu domínio. Além de contextualizar as propriedades do nó e do relacionamento, os rótulos também podem servir para anexar informações de índice de metadados ou restrições a certos nós. Os relacionamentos fornecem conexões direcionadas, nomeadas, semanticamente relevantes entre duas entidades de nó (por exemplo, Employee WORKS_FOR Company). Um relacionamento sempre tem uma direção, um tipo, um nó de início e um nó final . Como nós, os relacionamentos também podem ter propriedades. Na maioria dos casos, os relacionamentos possuem propriedades quantitativas, como pesos, custos, distâncias, classificações, intervalos de tempo ou pontos fortes. Como os relacionamentos são armazenados de forma eficiente, dois nós podem compartilhar qualquer número ou tipo de relacionamentos sem sacrificar o desempenho. Observe que, embora sejam direcionados, os relacionamentos sempre podem ser navegados de forma eficiente em qualquer direção. Existe uma regra consistente no núcleo em um banco de dados gráfico: "Sem links quebrados". Uma vez que um relacionamento sempre tem um nó de início e fim, você não pode excluir um nó sem também excluir seus relacionamentos associados. Você também pode sempre assumir que um relacionamento existente nunca irá apontar para um ponto final não existente. Cada nó (entidade ou atributo) no modelo de banco de dados de gráficos contém, de forma direta e física, uma lista de registros de relacionamento que representam suas relações com outros nós. Esses registros de relacionamento são organizados por tipo e direção e podem conter atributos adicionais. Sempre que você executa o equivalente a uma operação JOIN , o banco de dados apenas usa essa lista e tem acesso direto aos nós conectados, eliminando a necessidade de uma computação de pesquisa / correspondência cara. Você mais ou menos mantém os dados como está no mundo real: entidades pequenas, normalizadas, mas ricamente conectadas. Isso permite que você consulte e visualize seus dados de qualquer ponto de interesse imaginável, suportando muitos casos de uso diferentes.
- Um índice de banco de dados é uma cópia redundante de informações no banco de dados com o objetivo de tornar a recuperação desses dados mais eficiente. Isso ocorre à custa do espaço de armazenamento adicional e das escritas mais lentas, de modo a decidir o que indexar e o que não indexar é uma tarefa importante e muitas vezes não trivial. O Cypher habilita a criação de índices em uma ou mais propriedades para todos os nós que possuem um determinado rótulo: • Um índice que é criado em uma única propriedade para qualquer rótulo específico é chamado de índice de propriedade única . • Um índice que é criado em mais de uma propriedade para qualquer rótulo específico é chamado de índice composto. As diferenças nos padrões de uso entre os índices composto e de propriedade única são detalhadas nos exemplos abaixo. 3.2.1.2. Tipos estruturais ✓ Pode ser retornado das consultas Cypher ❏ Não pode ser utilizado como parâmetros ❏ Não pode ser armazenado como propriedades ❏ Não pode ser construído com literais Cypher Os tipos estruturais compreendem: • Nodos, compreendendo: ◦ Identidade ◦ Etiqueta (s) ◦ Mapa (de propriedades) • • Relacionamentos, compreendendo: ◦ Identidade ◦ Tipo ◦ Mapa (de propriedades) ◦ Identificação dos nós de início e fim • • Caminhos ◦ Uma seqüência alternada de nós e relacionamentos • 3.2.1.3. Tipos compostos ✓ Pode ser retornado das consultas Cypher ✓ Pode ser usado como parâmetros ❏ Não pode ser armazenado como propriedades ✓ Pode ser construído com literais Cypher Os tipos compostos compreendem: • As listas são heterogêneas, ordenaram coleções de valores, cada uma das quais possui qualquer tipo de propriedade, estrutural ou composta. • Os mapas são heterogêneos, coleções não ordenadas de pares (chave, valor), onde: ◦ a chave é uma String ◦ o valor possui qualquer tipo de propriedade, estrutural ou composto •
- Nos bancos de dados de gráficos, os índices são usados apenas para encontrar o ponto de partida para consultas, Um índice de banco de dados é uma cópia redundante de informações no banco de dados com o objetivo de tornar a recuperação desses dados mais eficiente. Isso ocorre à custa do espaço de armazenamento adicional e das escritas mais lentas, de modo a decidir o que indexar e o que não indexar é uma tarefa importante e muitas vezes não trivial. O Cypher habilita a criação de índices em uma ou mais propriedades para todos os nós que possuem um determinado rótulo: • Um índice que é criado em uma única propriedade para qualquer rótulo específico é chamado de índice de propriedade única . • Um índice que é criado em mais de uma propriedade para qualquer rótulo específico é chamado de índice composto. As diferenças nos padrões de uso entre os índices composto e de propriedade única são detalhadas nos exemplos abaixo.
- A primeira entidade que identificaremos em nosso domínio são os nós. As unidades fundamentais que formam um gráfico são nós e relacionamentos. Etiquetas Agora que temos uma idéia do que nossos nós serão, nós decidiremos quais rótulos (se houver) para atribuir nossos nós. Um rótulo é uma construção de gráfico com nome que é usada para agrupar nós em conjuntos. Todos os nós rotulados com o mesmo rótulo pertencem ao mesmo conjunto. Muitas consultas de banco de dados podem funcionar com esses conjuntos em vez de todo o gráfico, tornando as consultas mais fáceis de escrever e mais eficientes. Um nó pode ser rotulado com qualquer número de rótulos, incluindo nenhum, tornando as etiquetas uma adição opcional ao gráfico. Respondendo a perguntas Passamos pelo processo de criação de um modelo básico de dados gráficos para as interações entre pessoas e livros. Podemos levar este modelo de dados ainda mais, definindo os atributos dessas entidades como propriedades de valor-chave. Liste suas perguntas Primeiro, comece por listar suas perguntas que você deseja responder sobre seus dados. A partir desta lista de perguntas, você pode identificar os atributos que devem pertencer a entidades dentro do seu modelo de dados.
- ◦ Cada tabela de entidade é representada por um rótulo em nós ◦ Cada linha em uma tabela de entidade é um nó ◦ As colunas dessas tabelas tornam-se propriedades do nó. ◦ Remova as chaves primárias técnicas, mantenha as chaves primárias de negócios ◦ Adicione restrições únicas para chaves primárias de negócios, adicione índices para atributos de pesquisa freqüentes ◦ Substitua chaves estrangeiras por relações com a outra tabela, remova-as depois ◦ Remova dados com valores padrão, não é necessário armazenar aqueles ◦ Os dados em tabelas que são desmoronados e duplicados podem ter que ser puxados para nós separados para obter um modelo mais limpo. ◦ Nomes de coluna indexados, podem indicar uma propriedade de matriz (como email1, email2, email3) ◦ As tabelas de associação são transformadas em relacionamentos, as colunas dessas tabelas se tornam propriedades de relacionamento É importante ter uma compreensão do modelo de gráfico antes de começar a importar dados, então ele simplesmente se torna a tarefa de hidratar esse modelo.
Advertisement