Estou relativamente recém-saído da faculdade, por isso a maior parte da minha familiaridade com bancos de dados relacionais é do meu curso de bancos de dados, onde qualquer coisa que não esteja no BCNF ou no 3NF é uma farsa. Certamente esse é um extremo, mas minha equipe no trabalho realmente leva isso ao extremo oposto.
Em nossos esquemas de microservice db, as entidades raramente têm mais de uma única tabela. Tudo o que você normalmente normalizaria em outra tabela é armazenado em uma coluna json. Se for descoberto posteriormente que uma das propriedades desse json precisa ser consultada, uma nova coluna será adicionada e os dados serão armazenados nos dois locais (sim, em duas colunas diferentes na mesma tabela).
Em muitos casos, essas colunas json definitivamente têm uma vantagem. Se você nunca precisar consultar esses dados e nunca precisar fazer uma alteração unilateral nesses dados (o que obviamente não pode prever), não é uma má idéia. Além disso, muitos de nossos serviços não veem servidor ou estão hospedados em máquinas com uma quantidade obscena de espaço em disco para o que precisavam, portanto a duplicação de dados não é um grande problema. (Embora algo que eu geralmente gostaria de evitar fora da filosofia)
Atualmente, estamos construindo um serviço que corresponde às regras com base em um conjunto de condições que elas possuem e, em seguida, executa um conjunto de ações associadas a essas regras quando as regras são verdadeiras (por exemplo, todas as condições são verdadeiras). Minha sub equipe que mais imediatamente construiu esse serviço acredita que há um benefício substancial em normalizar ações e condições fora das regras do esquema. Obviamente, essas tabelas mantêm relacionamentos de chave estrangeira com o ID da regra. Da nossa perspectiva, podemos evitar a duplicação de dados em condições, o que nos permite garantir que eles sejam avaliados apenas uma vez e é fácil encontrar as condições e regras necessárias quando precisar delas, sem precisar extrair todas as regras e fazer a pesquisa na memória.
Hoje, conversando com um de nossos principais engenheiros, ele tentou me afastar desse esquema. Tentar argumentar de todas as maneiras que nós realmente não precisamos, isso causará problemas de desempenho no futuro, referenciando um antigo monólito que possuímos que é um travesti de design. Ele se referiu ao que estamos fazendo como "o caminho antigo" e as tabelas planas com json como "o novo caminho". Ele argumentou que em lugares onde eu quero atomicidade, não precisamos dela e que, em vez de consultas, devemos fazer mais coisas na memória. Esse é um princípio de design que muitos de nossos serviços seguem agora. Não prevemos que o volume de nossos dados aumente substancialmente, o que deve manter nossas consultas rápidas. O que antecipamos é muito tempo gasto na avaliação de regras e na execução de ações.
Entendo que bancos de dados não relacionais se tornaram mais populares nos últimos anos, mas mesmo ao pesquisar ativamente informações sobre as implicações de desempenho dos relacionamentos com chaves estrangeiras, não vejo muita informação justificando seu argumento. Suponho que eles tendem a introduzir grandes transações que podem causar problemas, mas isso parece ser um problema independente da própria chave estrangeira.
Esta é a minha ingenuidade? Ou existe realmente algo que eu e minha sub-equipe estamos perdendo? Eu explicitamente não forneci informações detalhadas sobre o nosso problema, porque não estou necessariamente procurando uma solução para isso. Dado que é uma tendência comum em nossa equipe maior, estou realmente curioso para saber se eles estão envolvidos com isso.
fonte
Respostas:
A palavra-chave aqui para entender de onde vem sua equipe é "microsserviços". Vale a pena ler primeiro esse conceito, principalmente para as seguintes informações:
Como em qualquer maneira relativamente nova de fazer as coisas (e 5 a 10 anos é relativamente novo quando se trata de arquitetura de software), você verá que os ideais e a realidade são um pouco diferentes.
Um dos ideais é que todo microsserviço tenha seu próprio armazenamento de dados. NOTA: Eu disse armazenamento de dados, não banco de dados. Há casos em que você simplesmente deseja um mecanismo de pesquisa, armazenamento de blob ou cache simples, em oposição a um banco de dados comum. Dependendo de quem você fala, esse ideal pode até ir a um repositório de dados por instância de microsserviço!
Resumindo, quando você está falando sobre ir para a escala da Internet, a segurança e a familiaridade das transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade) simplesmente não aumentam quando você tem milhões de usuários em um banco de dados. Com o advento do NoSQL, o paradigma mudou mais para o BASE (Basicamente disponível, estado flexível, consistência eventual). ( referência )
Há um impacto na alteração do PH de como você gerencia dados:
Não posso responder pelos detalhes de sua equipe ou por quanto eles pretendem que a solução seja, mas normalmente você não precisa ter uma solução de tudo ou nada. Não vou me sentar aqui e julgar se a equipe está fazendo as escolhas certas. Estou apenas fornecendo a você algum contexto para que você possa pelo menos entender de onde eles vêm.
fonte
OK, não sendo o principal engenheiro do projeto, você realmente precisa seguir as instruções dele para esse projeto.
Gostaria de encorajá-lo a trabalhar com seu próprio design do sistema e com o protótipo dele em casa, para que você entenda as vantagens e desvantagens. Faça isso para sua própria educação e mencione apenas no trabalho quando puder demonstrar exemplos de trabalho.
Minha experiência foi que há uma alegação de que restrições causam uma lentidão no desempenho do banco de dados. E sim, você terá que verificar essas restrições. No entanto, é um problema muito maior quando o banco de dados é inconsistente e isso faz com que você escreva SQL e mais código para compensar, geralmente aumentando a complexidade do sistema e diminuindo a velocidade.
O 3nf, quando feito de maneira apropriada, tornará o banco de dados mais rápido, pois mais deles podem ser armazenados em cache, pois há menos dados redundantes sendo armazenados. No entanto, em seu trabalho atual, pode não haver um conjunto de dados grande o suficiente para realmente ver a diferença de desempenho entre um banco de dados normalizado e um não normalizado.
fonte
Eu acho que eles têm medo de recriar o mesmo velho "travesti" que existia antes, em vez da própria Integridade Referencial.
Se você pode apresentar um argumento sólido (também conhecido como Requisito Não-Funcional) por precisar de atomicidade, eles precisarão de um bom e sólido contra-argumento para não fornecê-lo.
Vamos torcer você esteja certo. Eu sugeriria que confiar nos dados permanecendo "pequenos o suficiente" para permanecer com desempenho é arriscado.
Além disso, qual é a taxa de alteração dessas regras? Quanto mais duplicação você tiver, mais tempo (também conhecido como dinheiro) estará perdendo atualizando a mesma coisa em vários lugares.
fonte
Os principais conceitos por trás dos RDBMSs têm mais de 40 anos. Naquela época, o armazenamento era muito caro e qualquer tipo de redundância era desaprovada. Embora os conceitos por trás dos RDBMSs ainda sejam sólidos, a idéia de desnormalização do desempenho (para reduzir junções) tornou-se comumente aceita nas últimas décadas.
Portanto, para um RDBMS de um determinado tamanho, você normalmente tem seu design lógico (sem redundância) e seu design físico (com redundância) para desempenho.
Avançando hoje, onde o armazenamento é barato e os processadores estão mais rápidos do que nunca, algumas dessas pressões de design não são tão importantes. Por fim, é uma decisão sobre se você se importa com redundância e registros órfãos. Para alguns setores, como o setor bancário, a correção dos dados é vital, por isso é difícil ver como eles se afastarão dos RDBMSs. Para outras indústrias, novos players estão entrando no mercado o tempo todo, portanto as opções são inúmeras.
Quanto à sua equipe se sentir desconfortável com as restrições que um RDBMS pode trazer - quem sabe? Certamente os desenvolvedores juniores que eu vejo não têm o RDBMS nous que os desenvolvedores das gerações anteriores tinham, mas isso provavelmente está mais relacionado à proliferação de tecnologias para desenvolvedores e plataformas de banco de dados.
Não existe um fim para as tecnologias que um desenvolvedor pode aprender e pode ser difícil dar o pontapé certo para sua carreira. Certamente, os dias em que os desenvolvedores são o principal alvo de todas as negociações já se foram há muito tempo - há muito que se pode aprender.
Mas - para a pergunta em questão. Por sua própria admissão, você não espera que o volume de dados aumente e o sistema tenha um bom desempenho. Seria um exagero vender a ideia de reprojetar coisas sem nenhum benefício perceptível. Talvez se você pudesse fazer uma prova de conceito em que uma abordagem RDBMS tivesse benefícios, isso seria uma história diferente.
fonte
Depende do banco de dados que você está usando.
Em um RDBMS tradicional, você está certo. A duplicação de dados é uma abominação. As colunas e sua equivalência json inevitavelmente ficarão fora de sincronia porque não há nada para aplicá-las. O suporte a chaves estrangeiras é bem conhecido, faz um ótimo trabalho na descrição e aplicação de relacionamentos. E a atomicidade é vital para fazer quase qualquer coisa com dados.
Em um tipo de configuração nosql, é menos claro. Como não existem relações firmes, a aplicação das relações se torna menos importante. Esse tipo de conteúdo json com índice de coluna é muito mais comum nesses sistemas, porque nenhuma relação significa menos probabilidade de ficar fora de sincronia. E a atomicidade é restrita à tabela única, porque é assim que o nosql funciona.
O que é melhor depende do que você está realmente fazendo e do que realmente precisa.
Mas parece que seus colegas de trabalho estão em um culto à carga. Eles foram picados por coisas velhas e ruins, então agora as coisas precisam ser a nova coisa brilhante. Em alguns anos, depois de serem mordidos pela nova coisa brilhante, esperançosamente perceberão que SQL vs noSQL é um conjunto de vantagens e desvantagens.
Mas eles não vão. Espero que você vai embora.
fonte