Esses dois cenários seriam bons candidatos para um banco de dados NoSQL?

5

Eu verifiquei alguns outros tópicos em torno do tópico e pesquisei por aí, estou querendo saber se alguém pode me dar uma orientação clara sobre por que devo considerar o NoSQL e qual um (uma vez que existem alguns deles cada um com finalidades diferentes)

Como muitos outros - eu comecei com bancos de dados relacionais e trabalhei neles desde então, assim, quando apresentado com um problema, o primeiro instinto é sempre pensar em "Eu posso criar essas tabelas, com essas colunas, com esta chaves estrangeiras ", etc

Meu objetivo geral é Como entrar na mentalidade "NoSQL" ? ou seja, ficar longe da inclinação de sempre pensar em tabelas / colunas / FKs (eu entendo que há casos em que o RDBMS ainda é o melhor caminho a percorrer)

Estou pensando em dois cenários, por exemplo, apenas para obter uma direção mais concreta

Cenário 1

Imagine um banco de dados para modelar a construção de instruções de mobília (pense nas instruções da IKEA) onde você teria o objeto "mobília" que teria uma lista de "materiais" e teria uma lista de "instruções"

  • Móveis - teria simplesmente um nome com uma lista de Materiais e instruções
  • Materiais - seria um nome + quantidade, pode ser que tenhamos também a tabela "Categoria de material"
  • Instruções - seria simplesmente uma lista ordenada de textos

Meu primeiro instinto seguiria o caminho do RDBMS:

  • Crie uma tabela chamada "Mobiliário", "Material" e "Instrução" e as colunas apropriadas
  • Crie as tabelas de JOIN apropriadas, conforme necessário e FKs

O uso deste sistema pode incluir pesquisa com base em materiais ou pode ser uma combinação de materiais. E pode-se pensar em estender os dados armazenados para incluir informações sobre quantas pessoas são necessárias para construí-lo? Nível de dificuldade? quanto tempo levaria?

Será que algo assim seria um bom candidato para um banco de dados NoSQL?

Cenário 2

Imagine um banco de dados para modelar um banco de dados do usuário com informações básicas (por exemplo, nome, e-mail, número de telefone, etc.), mas também deseja ter a flexibilidade de adicionar campos personalizados.

Pense em diferentes sistemas que consomem este banco de dados do usuário, cada sistema desejará ter seu próprio atributo personalizado para ser anexado ao usuário

Minha inclinação seria do modo RDBMS:

  • Crie uma tabela para "USER" com colunas: ID, nome, email, telefone
  • Crie uma tabela para "USER_ATTRIBUTE" com colunas: ID, USER_ID, attr_name, attr_type, attr_value

O USER_ATTRIBUTE permitirá essa customização e flexibilidade sem precisar desligar o sistema, alterar o banco de dados e reiniciá-lo.

Será que algo assim seria um bom candidato para um banco de dados NoSQL?

    
por tsOverflow 13.08.2014 / 15:01
fonte

2 respostas

3

NoSQL não é um termo muito bem definido e todas as soluções que funcionam com este nome têm características muito diferentes, portanto, muito pode ser possível ou não, dependendo do que exatamente você está planejando fazer com ele.

Basicamente, você pode usar algumas das soluções mais gerais, como talvez o MongoDB ou o Cassandra, para simplesmente substituir seu banco de dados relacional atual. Em alguns casos, isso faz mais sentido nos outros menos, mas funcionará quando a equipe se acostumar com isso. Certas coisas serão mais fáceis então, outras serão mais difíceis e você deve ponderar essas opções umas contra as outras e decidir (o que muitas vezes significará que não há vantagens grandes o suficiente e o simples fato de que todos na equipe se sentem mais à vontade com os relacionais). e o SQL facilitará a decisão)

Outras soluções NoSQL que são mais especializadas não são boas candidatas para substituir seu banco de dados relacional, como bancos de dados de gráficos ou armazenamentos de valores chave simples. Então, vamos aqui falar principalmente sobre os bancos de dados que são, pelo menos em algum grau, semelhantes aos bancos de dados relacionais.

Cenário 1

Onde eu trabalho, nós temos exatamente este cenário, apesar de bem mais complexo, com muitos atributos diferentes por artigo. Alguns desses atributos em hierarquias como a Apple - > iPad - > Ar.

Os dados ainda são armazenados em um banco de dados relacional. Mas: pesquisar isso em tempo real se tornou uma dor. Com o SQL, era lento e o código teria sido terrivelmente complexo. Seleciona várias tabelas, com a opção adicional de excluir determinados atributos como "não azul".

Neste caso, o Apache Solr ou o Elastic Search são uma solução. Embora, é claro, os dados sejam duplicados do banco de dados relacional.

Mas a partir daqui nossa experiência com esse tipo de armazenamento de documentos mostrou que ele pode lidar com certos problemas muito bem e vamos considerar substituir parte da estrutura relacional existente por algum outro tipo de armazenamento. Portanto, não o banco de dados inteiro onde também armazenamos todos os dados transacionais, como pedidos, etc., mas, por exemplo, retiramos todas as informações de atributos que podem ser manipuladas muito melhor no agregado, como estruturas de dados do NoSQL.

Cenário 2

É difícil dizer, já que o que você descreve provavelmente é apenas uma parte muito pequena do tratamento do usuário. Ter armazenamento sem esquema é uma vantagem em muitos bancos de dados NoSQL. Mas alguns bancos de dados relacionais permitem armazenar esses dados também (desde que você não precise consultá-los via SQL na maioria dos casos).

O Cassandra, por exemplo, permitiria que você definisse famílias de colunas nesse caso, onde seu primeiro conjunto de atributos seria uma dessas famílias e os atributos da variável outro.

Como alguém disse: NoSQL é menos sobre armazenamento e mais sobre a consulta. Então, a questão é qual será o caso de uso típico para essas consultas.

Um problema típico seria os dados transacionais aqui. Se você quiser armazenar pedidos, um caminho seria um esquema em que os usuários e seus pedidos formam um agregado (tipo de documento do usuário que contém os pedidos como subdocumentos). Isso tornaria o usuário junto com seus pedidos muito simples e rápido, mas tornaria muito difícil recuperar todos os pedidos do mês passado para as estatísticas de vendas.

Além disso, os pontos strongs das soluções NoSQL são que pode ser mais fácil executá-los em vários clusters, se você tiver que trabalhar com conjuntos de dados muito grandes.

Conclusão: Ambos os cenários podem ser modelados com certas soluções NoSQL, mas não acho que (supondo que eles tenham que ser executados em um ambiente maior) eles realmente justificam um grande esforço extra no aprendizado , treinamento e implementação e talvez algumas outras desvantagens adicionais, porque ambos não são específicos o suficiente para realmente alavancar os pontos strongs do NoSQL. Pelo menos não nessa forma simples que você descreve. As coisas podem se tornar muito diferentes, uma vez que alguns aspectos que você descreveu seriam muito proeminentes em seu cenário de uso, como no cenário um, os dados do atributo se tornam muito complexos ou no cenário dois, os campos variáveis se tornam a maior parte dos dados armazenados com cada usuário.

    
por 13.08.2014 / 15:42
fonte
1

Eu tenho usado o dbs de documentos (ravendb para ser específico) como minha loja de dados de escolha por mais de 3 anos e eu realmente não quero olhar para trás.

Pelo menos para esse tipo de banco de dados nosql, a maior questão é "o que acontece neste documento? O que acontece em outro documento? O que acontece em um documento relacionado?" Infelizmente não há muita boa orientação sobre isso. Então, novamente, os RDBs são uma tecnologia de mais de 30 anos, então ainda há um trabalho muito massivo, mas ainda não há respostas perfeitas para todos os problemas - por exemplo, eu rejeitaria qualquer solução de valor de atributo de entidade como seu cenário # 2 sem reais, reais boas razões para ir EAV - Eu prefiro modelar extensões de dados como sub-tipos de tabelas ou usando algum tipo de campo de extensões que compreende dados serializados.

De qualquer forma, não há princípios perfeitos, mas há alguns bons princípios que podemos seguir. Os dois que mais me ajudaram são:

  1. Modele seus documentos em torno dos limites da transação. As junções são muito mais caras para trabalhar e usar com objetos, portanto, ser capaz de selecionar um Foo por ID e obter todo o foo faz muito sentido e facilita o trabalho em muitos níveis. Agora, isso não quer dizer que tudo precisa ser um documento massivo - limites de transações podem ser mais confinados do que "tudo a ver com uma peça de mobília". No caso do seu cenário nº 1, provavelmente verificaria os limites da transação como o Mobiliário, incluindo Materiais, e depois um documento de Instruções separado. A lógica é que você provavelmente gerencia móveis e materiais juntos, mas as instruções provavelmente vêm de algum outro lugar. Tenha em mente que a agregação no front end é bem barata. Categorias é um exemplo interessante que me leva a. . .

  2. A duplicação de dados é ok se você administrá-lo corretamente. Um dos principais princípios subjacentes do RDBMS é "não duplicar dados" em grande parte porque cresceu em um mundo onde o armazenamento em disco era muito mais caro do que em 2014. Para bancos de dados de documentos, pode fazer sentido ter cópias de coisas dentro de seus limites de transação. Por exemplo, vamos pegar as categorias de mobília do cenário # 1 - Eu provavelmente teria um FurnitureCategoryDocument que teria todas as informações sobre a categoria. Eu também teria algumas informações importantes - ID e nome, pelo menos - embutidas nos documentos para facilitar o uso. Isso é bom, desde que você possa fazer atualizações em cascata, o que requer mais código que ON UPDATE CASCADE, em seu aplicativo.

Espero que isso ajude a desmistificar as coisas um pouco.

    
por 13.08.2014 / 18:22
fonte