Quando devo usar uma base de dados NoSQL em vez de uma base de dados relacional? Pode usar ambos no mesmo site?
6 answers
As bases de dados relacionais impõemÁcido . Então, você terá arquivos de dados baseados em esquemas baseados em transações. Está provado e adequado para 99% das aplicações do mundo real. Você pode praticamente fazer qualquer coisa com bases de dados relacionais.
Mas, há limitações de velocidade e escala quando se trata de grandes reservas de dados de alta disponibilidade. Por exemplo, o Google e a Amazon têm terabytes de dados armazenados em grandes centros de dados. Questionar E Inserir não é performante nestes cenários devido à natureza de bloqueio/esquema/transacção dos RDBMs. Essa é a razão pela qual eles implementaram suas próprias bases de dados (na verdade, lojas de valor-chave) para o ganho de desempenho e escalabilidade massiva.
As bases de dados NoSQL existem há muito tempo - apenas o termo é novo. Alguns exemplos são bases de dados de grafos, objetos, colunas, XML e documentos.
Para a sua segunda pergunta: pode-se usar ambos no mesmo site?
Porque não? Ambos servem de forma diferente. propósitos, certo?As soluções NoSQL são normalmente destinadas a resolver um problema para o qual as bases de dados relacionais não são adequadas, demasiado caras para usar (como a Oracle) ou requerem que você implemente algo que quebra a natureza relacional do seu db de qualquer maneira.
As vantagens são geralmente específicas ao seu uso, mas a menos que você tenha algum tipo de problema modelando seus dados em um RDBMS eu não vejo nenhuma razão pela qual você escolheria NoSQL.
Eu próprio uso MongoDB e Riak para problemas específicos em que um RDBMS não é uma solução viável, para todas as outras coisas que eu uso MySQL (ou SQLite para testes).
Se você Precisa de um db NoSQL que normalmente conhece, as possíveis razões são:
- O cliente quer 99,999% de disponibilidade em
um local de trânsito elevado.
- os seus dados sem sentido em SQL, você se encontra a fazer várias pesquisas de junção para a aceder a alguma informação. Estás a quebrar a relacional. modelo, tens o CLOBs naquela loja. dados desnormalizados e você gerar índices externos para pesquisar esses dados.
Se você não precisa de uma solução NoSQL tenha em mente que estas soluções não eram entendidas como peças de substituição para um RDBMS, mas sim como alternativas onde o ex-falha e, mais importante, que eles são relativamente novos, como tal, eles ainda tem um monte de bugs e falta de recursos.
E quanto à segunda questão, é perfeitamente correcto usar qualquer tecnologia em conjunto com outra, por isso, só para ser completa a partir do meu experiência MongoDB e MySQL trabalham bem juntos desde que não estejam na mesma máquina.Você tem grandes quantidades de dados - especialmente se você não pode caber tudo em um servidor físico como NoSQL foi projetado para escalar bem.
Desfasamento de impedância Objeto-Relacional - seus objetos de domínio não se encaixam bem em um esquema de banco de dados relacional. NoSQL permite que você persista seus dados como documentos (ou gráficos) que podem mapear muito mais perto do seu modelo de dados.
O NoSQL é um sistema de bases de dados onde os dados são organizados no documento (MongoDB), par de valores-chave (MemCache, Redis), forma de estrutura de grafos(Neo4J).
Talvez aqui estejam perguntas possíveis e respostas para "quando ir para NoSQL":
Necessita de esquemas flexíveis ou lidar com dados de árvore?
Geralmente, em desenvolvimento ágil começamos a projetar o sistema sem conhecer todos os requisitos iniciais, onde mais tarde em todo o sistema de banco de dados de desenvolvimento pode precisar acomodar mudanças de design frequentes, showcasing MVP (mínimo produto viável). Ou você está lidando com o esquema de dados que é dinâmico na natureza. por exemplo, registos do sistema, exemplo muito preciso são registos de cloudwatch AWS.O conjunto de dados é vasto / grande?
Sim NoSQL banco de dados são o melhor candidato para aplicações onde banco de dados precisa gerenciar milhões ou mesmo bilhões de registros sem comprometer o desempenho.Troca entre uma escala sobre a consistência
Ao contrário do RDMS, o NoSQL banco de dados pode perder pequenos dados aqui e ali(Nota: probabilidade é .x%), mas é fácil de escalar em termos de desempenho. Exemplo: isso pode ser bom para armazenar pessoas que estão on-line em aplicativo de mensagens instantâneas, tokens em db, registrando estatísticas de tráfego do site web.A Efectuar Operações De Geolocalização: MongoDB hash suporte rico para fazer operações de GeoQuerying & Geolocation. Adorei esta característica do MongoDB.
Existe um grande post de Julian Brown que lança luzes sobre restrições dos sistemas distribuídos. O conceito é chamado Teorema do CAP de Brewer que em resumo vai:
E isto ... foi assim que o resumi:Os três requisitos dos sistemas distribuídos são: consistência, disponibilidade e tolerância à partição (em resumo). Mas só podes ter dois de cada vez.
É melhor você ir para NoSQL se a consistência é o que você está sacrificando.
Faltam algumas informações essenciais para responder à pergunta: Quais os casos de utilização que a base de dados deve poder cobrir? Têm de ser efectuadas análises complexas a partir de dados existentes (OLAP ) ou a aplicação tem de ser capaz de processar muitas transacções (OLTP)? Qual é a estrutura de dados? Isso está longe do fim do período de perguntas.
Na minha opinião, é errado tomar decisões tecnológicas com base em palavras ousadas sem saber exactamente o que está por trás o. NoSQL é muitas vezes elogiado por sua escalabilidade. Mas você também tem que saber que a escala horizontal (sobre vários nós) também tem o seu preço e não é livre. Então você tem que lidar com questões como eventual consistência e definir como resolver conflitos de dados se eles não podem ser resolvidos ao nível da base de dados. No entanto, isto aplica-se a todos os sistemas de bases de dados distribuídos.A alegria dos desenvolvedores com a palavra "schema less" em NoSQL também é muito grande no início. Presente buzzword é rapidamente desencantado após a análise técnica, porque ele corretamente não requer um esquema ao escrever, mas entra em jogo ao ler. É por isso que deveria ser corretamente "schema on read". Pode ser tentador ser capaz de escrever dados a seu próprio critério. Mas como lidar com a situação se há dados existentes, mas a nova versão do aplicativo espera um esquema diferente?
O modelo do documento (como em MongoDB, por exemplo) é não adequado para modelos de dados onde existem muitas relações entre os dados. Joins tem que ser feito em nível de aplicação, que é um esforço adicional e por que eu deveria programar coisas que o banco de dados deve fazer.
Se você faz o argumento de que o Google e a Amazon desenvolveram suas próprias bases de dados porque os RDBMS convencionais não podem mais lidar com o fluxo de dados, você só pode dizer: Você não é o Google e a Amazon. Estas empresas são a ponta de lança, cerca de 0,01% dos cenários em que as bases de dados tradicionais são já não são adequados, mas são para o resto do mundo.
O que não é insignificante: SQL existe há mais de 40 anos e milhões de horas de desenvolvimento foram para grandes sistemas como Oracle ou Microsoft SQL. Isto tem de ser conseguido através de novas bases de dados. Às vezes também é mais fácil encontrar um administrador SQL do que alguém para MongoDB. O que nos leva à questão da manutenção e gestão. Um assunto que não é propriamente sexy, mas que faz parte do decisão tecnológica.