NoSQL utilizar cenários de Utilização ou quando utilizar NoSQL [fechados]

com toda a publicidade, parece muito difícil encontrar informações fiáveis sobre quando usar isto. Por isso, faço as seguintes perguntas, e peço desculpa se estas são perguntas realmente estúpidas com antecedência:

  1. devo usar o NoSQL para os dados do utilizador? Por exemplo, perfis, nomes de utilizador + senhas, etc.
  2. devo usar NoSQL para conteúdo importante? Por exemplo, artigos, posts em blogs, inventário de produtos, etc.
Presumo que não. E eu sinto que NoSQL é apenas para coisas rapidamente acessíveis de o que não faz mal perder dados. Mas eu também li que aplicativos NoSQL têm redundância embutida para que eu não perca dados?

também se os dois exemplos acima são maus, poderia dar-me casos específicos de uso comercial em que eu usaria NoSQL? Vejo muitas descrições gerais, mas não muitos exemplos do mundo real. As únicas coisas que consigo pensar são mensagens de utilizador a Utilizador e análises.

Obrigado!

Author: Shimmy, 2012-05-11
Source

2 answers

É mesmo uma pergunta do tipo" depende". Alguns Aspectos gerais Pontos:
  • NoSQL é tipicamente bom para dados não estruturados/ "schemaless" - normalmente, você não precisa definir explicitamente o seu esquema na frente e pode apenas incluir novos campos sem qualquer cerimônia
  • a NoSQL normalmente favorece um esquema desnormalizado devido à ausência de suporte para as ligações no mundo RDBMS. Então você normalmente teria uma representação plana e desnormalizada de seus dados.
  • utilizar NoSQL não significa que possas perder dados. Diferentes DBs têm estratégias diferentes. por exemplo, MongoDB - você pode essencialmente escolher qual o nível para negociar o desempenho vs potencial para a perda de dados - melhor desempenho = maior escopo para a perda de dados.
    • Muitas vezes é muito fácil dimensionar as soluções NoSQL. Adicionar mais nós para replicar dados é uma maneira de a) oferecer mais escalabilidade e B) oferecer mais proteção contra a perda de dados se um nó cair. Mas, novamente, depende da configuração NoSQL DB/. NoSQL não significa necessariamente "perda de dados" como você infere.
  • IMHO, consultas/relatórios complexos/dinâmicos são melhor servidos a partir de um RDBMS. Muitas vezes a funcionalidade da consulta para um DB NoSQL é limitada.
    • Não tem de ser um 1 ou outra escolha. A minha experiência tem usado RDBMS em conjunto com NoSQL para certos casos de Utilização.
  • o DBS NoSQL muitas vezes não tem a capacidade de realizar operações atómicas através de múltiplas "tabelas".
Precisas mesmo de olhar e entender. quais são os vários tipos de lojas NoSQL, e como eles vão sobre o fornecimento de escalabilidade/segurança de dados, etc. É difícil dar uma resposta abrangente, pois eles são todos diferentes e lidam com as coisas de forma diferente.

Para MongoDb como exemplo, confira seus usar casos para ver o que eles sugerem como sendo "bem adequado" e "menos adequado" usos do MongoDb.

 143
Author: AdaTheDev, 2017-11-15 11:17:27

Eu acho que Nosql é "mais adequado" nestes cenários pelo menos (mais suplementar é bem-vindo)

  1. Fácil de escalar apenas adicionando mais nós.

  2. Consulta em grandes conjuntos de dados

    Imagine toneladas de tweets postados no twitter todos os dias. Em RDMS, pode haver mesas com milhões (ou bilhões?) de linhas, e você não quer fazer consulta nessas tabelas diretamente, nem mesmo mencionando, na maioria das vezes, as junções de tabelas também são necessários para complexos consulta.

  3. Ponto de estrangulamento do disco I/O

    Se um site precisa de enviar resultados a diferentes utilizadores com base na informação em tempo real dos utilizadores, estamos provavelmente a falar de dezenas ou centenas de milhares de pedidos de leitura/escrita SQL por segundo. Em seguida, disco I / o será um sério gargalo.

 10
Author: otm, 2017-11-15 11:18:49