Existe algo inovador no NoSQL? [fechadas]

Eu sou um cara de banco de dados relacional muito sólido e entendo até a terceira forma normal, aprecio as raízes algébricas da teoria dos conjuntos do SQL e provavelmente posso relacionalizar um coração partido (ou não).

Ainda não descobri uma estrutura de banco de dados relacional para noites com minha esposa, mas pensei em projetos de bancos de dados relacionais em noites com minha esposa.

Agora estou ouvindo sobre o NoSQL e pesquisando. Indo direto ao ponto, existe algo no NoSQL inovador, matematicamente novo ou um "ei, você nem precisa realmente organizar seus dados de forma relacional, isso é muito mais fácil"?

O NoSQL é como um super shell para a estrutura de dados? Em minha opinião, os dados devem ter estrutura a ser recuperada e a recuperação deve ser definida em algum tipo de linguagem.

O NoSQL é mais evolutivo do que revolucionário. Essencialmente, combina as idéias existentes de "armazenamento externo de banco de dados" com "o uso de estruturas de dados familiares, e não de tabelas relacionais".

Existem mais tipos de bancos de dados do que relacionais, por exemplo, bancos de dados hierárquicos . Embora arcaico pelos padrões de hoje, combinou muito bem com as estruturas de dados de seus dados (por exemplo, registros COBOL ). O ponto é que os dados no banco de dados foram modelados de perto como os registros foram dispostos nas linguagens de programação que os usavam.

Avançando rapidamente para a invenção de bancos de dados relacionais , onde finalmente o banco de dados separava preocupações e, quando normalizado adequadamente, é uma ótima maneira de visualizar a maioria dos tipos de dados e relacionamentos entre eles. É realmente fácil de entender em comparação com outros tipos de bancos de dados. No entanto, o que falha totalmente é armazenar dados de uma maneira que espelha objetos e classes em um programa. Portanto, a invenção do mapeamento objeto-relacional . Em outras palavras, o design do banco de dados é realmente um obstáculo ao design do programa que o utiliza, e é por isso que precisamos de bibliotecas ORM como o Hibernate. Embora limpo e consistente, sempre há aquela dúvida persistente no fundo da minha mente de que algo não está bem ali.

Isso deu origem a mais dois tipos de bancos de dados, bancos de dados de objetos e NoSQL .

Ambos tentam resolver os problemas introduzidos pelos bancos de dados relacionais, sem nos expor aos horrores alucinantes dos bancos de dados hierárquicos. Os dados ainda são dispostos em repositórios que se parecem vagamente com tabelas, mas, na realidade, são mais como estruturas de dados de programação do que tabelas relacionais. Enquanto os bancos de dados de objetos seguem regras bem definidas, meu entendimento é de que o NoSQL é arbitrário. Por exemplo, uma tabela pode ser visualizada como uma tabela de hash ou uma matriz. Não há uma maneira fácil e bem definida de consultá-los usando uma ferramenta arbitrária análoga ao Oracle SQL Developer ou SQL Server Management Studio .

A idéia é que se possa definir estruturas de dados que são facilmente pesquisadas em código, em vez de reunir consultas SQL que são mais adequadas para um mecanismo de banco de dados SQL, em vez de expressar a consulta desejada. Por exemplo, correspondências parciais ou difusas são mais difíceis e apresentam pior desempenho em um banco de dados relacional, enquanto um banco de dados NoSQL pode ter uma estrutura otimizada para essa pesquisa e concluída em uma fração do tempo.

Existem idiomas para consultar o NoSQL. No entanto, não existe uma linguagem universal como o que é o SQL para bancos de dados relacionais.

Edição tardia:

Embora eu esteja familiarizado o suficiente com os bancos de dados NoSQL, essa pergunta foi o ímpeto para eu comprar um livro de qualidade sobre o tópico e começar a lê-lo com o objetivo de ser um verdadeiro especialista no assunto. Os comentários restantes são baseados no NoSQL Distiled: um breve guia para o mundo emergente da persistência poliglota de Pramod Sadalage e Martin Fowler .

Os autores afirmam que os bancos de dados relacionais não se adaptam bem aos clusters capazes de atender aos dados necessários para sites como Amazon e Google: o NoSQL foi desenvolvido para atender a esse nicho, relaxando a simultaneidade e a durabilidade no ACID para atender ao grande número de consultas que usam amplamente dados estáticos (portanto, as transações ACID não são tão importantes).

Além disso, eles afirmam que os bancos de dados NoSQL operam sem um esquema (página 10) que permite que os bancos de dados NoSQL modifiquem a estrutura dos dados mais facilmente. Não tenho certeza de que a presença ou ausência de um esquema formal seja importante a esse respeito, pois os bancos de dados SQL também permitem modificar esquemas. Independentemente disso, os dois autores renomados fazem a alegação, portanto vale a pena examinar.

Acredito que esses dois pontos principais servem apenas para reforçar meu argumento principal de que o NoSQL é evolutivo, não revolucionário. Eles ainda armazenam dados e fazem melhorias incrementais na escala e modificabilidade. Eles também argumentam que o NoSQL não busca usurpar bancos de dados relacionais como o rei do armazenamento de dados, apenas para fornecer um meio alternativo de armazenamento de dados para os tipos de dados que precisam ser escalados e transformados de uma maneira que (eles acreditam) bancos de dados não suportam o suficiente.

Eu acho que você definitivamente gostaria de olhar para este artigo de Erik Meijer e Gavin Bierman, intitulado "Ao contrário da crença popular, SQL e NoSQL são realmente apenas dois lados da mesma moeda" . Em suma, afirma que matematicamente falando ambas as abordagens baseiam-se na mesma teoria, mas com algumas diferenças.

Algumas diferenças interessantes são, na minha opinião, as seguintes: a direção das dependências de tipo cruzado (FK no SQL) é oposta no SQL e NoSQL e o tipo de coleções não se limita ao conjunto no NoSQL (e, portanto, algumas operações teóricas de conjunto pode não se aplicar mais no mundo NoSQL, mas outros ainda são válidos). Outro ponto interessante do artigo é a linguagem de consulta única proposta para consultar os bancos de dados SQL e NoSQL. Chama-se LINQ e, se você acha que já ouviu esse nome antes, está correto: essa é a linguagem de consulta da Microsoft em C #.

A resposta de Snowman descreve corretamente como o SQL e o NoSQL diferem em suas estruturas de dados e como eles são acessados. No entanto, uma diferença provavelmente ainda mais importante é o respectivo domínio do problema.

O NoSQL não é um sucessor do SQL. Em vez disso, os vários ramos do NoSQL sacrificam algumas qualidades do SQL para serem melhores em outros . O teorema do CAP afirma que é impossível para qualquer sistema de banco de dados distribuído satisfazer todas as seguintes propriedades:

• Consistência
• Disponibilidade
• Tolerância de partição

Assim, algumas variantes do NoSQL seguem o princípio BASE , que relaxa a restrição de consistência sempre completa do ACID , que é a base para os bancos de dados SQL clássicos. Ao perderem algumas garantias de consistência, elas ganham a possibilidade de combinar alta disponibilidade e tolerância a partições em sistemas amplamente distribuídos, como em sites com grandes quantidades de dados e consultas de usuários, mas com pouca demanda por consistência perfeita. Portanto, esses bancos de dados NoSQL estão no coração do Google , Facebook e Amazon . Portanto, para responder à sua pergunta: Sim, o NoSQL é inovador , pois possibilita serviços Web tão grandes.

Este é apenas um exemplo, já que o NoSQL é um campo diversificado e suas variantes cobrem praticamente todas as combinações possíveis de parâmetros dentro do triângulo CAP .

Os casos de uso comuns do NoSQL são inovadores em seus ganhos de produtividade em comparação com os bancos de dados comuns baseados em SQL. Existem vários fatores nisso.

Um deles é arrumação. A maioria dos NoSQLs é de código aberto e pode ser instalada em uma estação de trabalho ou em uma VM com alguns comandos, além de trabalhar com padrões razoáveis ​​prontos para uso. Na minha experiência, mesmo o Postgres e o MySQL não são assim; A configuração geralmente é necessária para iniciar mesmo em uma estação de trabalho para fins de desenvolvimento.

Outro é o desenvolvimento conveniente, como outras respostas descritas em detalhes. Os recursos de indexação JSON do Mongo, ou a semântica de chave / valor de redis e Riak, podem ser todos os aplicativos da web necessários para realizar o trabalho, e as APIs são fáceis. Alguns NoSQLs fornecem suas próprias APIs RESTful, enquanto que com o SQL você normalmente precisa escrevê-las.

Esses fatores tornam os bancos de dados NoSQL atraentes para projetos de pequena escala. O tempo de coleta tende a ser baixo. Certamente, quando você vai para a produção, precisa configurar para segurança e escala, mas a capacidade de começar a codificar e colaborar rapidamente é poderosa e, argumento, inovadora.

Além disso, relacionado ao acima, para aplicativos de pequena escala (como serviços internos da empresa ou aplicativo a aplicativo), uma equipe pode suportar um banco de dados NoSQL de produção sem envolver suas equipes de DBA e sem sofrer desempenho ou integridade problemas como resultado. Os DBAs profissionais podem não gostar disso, mas os desenvolvedores que veem os DBAs como uma fonte de obstrução (certa ou errada) às vezes veem o NoSQL como uma maneira de evitar ter que lidar com eles. Confesso: uma vez mudei um aplicativo de pequena escala do Postgres para o SQLite para eliminar o DBA adversário, e optei por implementar no Mongo, e não no Oracle, para evitar processos de aprovação do DBA e restrições de acesso. Sem consequências adversas em ambos os casos.