Quanto o modelo de dados afeta a escalabilidade e o desempenho no chamado banco de dados "NoSQL"?

Você nunca pode falar sobre o chamado banco de dados "NoSQL" sem trazer o teorema do CAP (Consistência, Disponibilidade, Partição: escolha dois). Se você precisar escolher entre o MongoDB (Partição, Consistência) e o CouchDB (Disponibilidade, Partição), o primeiro que você precisará pensar é em "Preciso de dados corretos ou preciso acessar o tempo todo?".

Esses novos bancos de dados foram criados para serem particionados. Mas e se eu não fizer ? E se eu achar que é muito legal ter uma Chave / Valor, Coluna, Documento, qualquer banco de dados em vez de relacional, e apenas criar uma instância de servidor e nunca fragmentá-la? Nesse caso, eu não teria disponibilidade e consistência? O MongoDB não precisaria replicar nada, portanto estaria disponível. E o CouchDB teria apenas uma fonte de dados, portanto seria bastante consistente.

Então, isso significaria que, nesse caso, o MongoDB e o CouchDB teriam pouca diferença em termos de caso de uso? Bem, exceto, obviamente, o desempenho, API e tudo mais, mas isso seria mais como escolher entre o PostgreSQL e o MySQL do que ter dois conjuntos de requisitos fundamentalmente diferentes.

Estou bem aqui? Posso alterar um banco de dados AP ou CP para um AC, não criando mais de uma instância? Ou há algo que estou perdendo?

Vamos fazer a pergunta ao contrário. E se eu pegar um banco de dados relacional, digamos MySQL, e colocá-lo em uma configuração master / slaves. Não uso transações ACID Se eu exigir que qualquer gravação seja sincronizada com o escravo imediatamente, isso não tornaria um banco de dados do CP? E se eu sincronizá-lo em alguns intervalos predefinidos, e não importa se um cliente lê dados antigos de um escravo. Isso não tornaria um banco de dados AP? Isso não significa que, se eu desistir da conformidade com o ACID, ainda posso usar o modelo relacional para um banco de dados particionado?

Em essência: a escalabilidade sobre o que você está pronto para desistir no teorema da PAC é mais do que o modelo de dados subjacente? Ter Coluna, Documento, Valor-chave, qualquer que seja, impulsiona a escalabilidade em relação a um modelo relacional? Poderíamos projetar um banco de dados relacional projetado desde o início para tolerância à partição? (Talvez já exista). Poderíamos tornar o banco de dados NoSQL compatível com ACID?

Desculpe, são muitas perguntas, mas li muito sobre o banco de dados NoSQL recentemente e me parece que o maior benefício de usá-los é que eles se encaixam melhor na "forma" dos seus dados, em vez de apenas na partição, CAP e desistir da conformidade com o ACID. Afinal, nem todos têm tantos dados que precisam particioná-los. Existe um benefício em desempenho / escalabilidade por não usar o modelo relacional antes mesmo de pensar em particionar meus dados?

O uso de um banco de dados NoSQL aumenta a escalabilidade, mesmo que você não esteja compartilhando dados? Bem, vamos definir escalabilidade. Se você está se referindo à escalabilidade no que diz respeito aos sistemas de banco de dados / back-end, na medida em que você tem dimensionamento vertical e horizontal em que o dimensionamento horizontal é compartilhar dados, isso se torna uma pergunta trivial, porque a resposta seria absolutamente não, porque a única opção que você deixou é a escala vertical (ou seja, a obtenção de melhor hardware). Se, no entanto, você está falando sobre escalabilidade em um sentido mais amplo, referindo-se à flexibilidade do aplicativo, valor dos dados, etc ... Então essa é uma pergunta completamente diferente, com várias respostas. E, como você mencionou, muitas vezes se resume ao que você está fazendo com os dados e como eles devem ser armazenados. Permitam-me que anteceda tudo aqui com a declaração de que na maioria dos casos você ainda deve usar um RDBMS e o NoSQL deve preencher um nicho. A seguir, é apresentada uma descrição de uma instância específica em que um banco de dados NoSQL seria mais benéfico, devido a requisitos específicos, e onde podemos ignorar o dimensionamento horizontal.

Tomemos, por exemplo, a idéia de que você está criando um sistema de armazenamento em nuvem semelhante ao google drive, dropbox ou box, mas, em vez de usar um sistema de arquivos real, decide que seria mais benéfico para virtualizar o sistema de arquivos. Agora você tem um problema porque, de repente, seu modelo de dados é a estrutura em árvore que será terrivelmente ineficiente em um RDBMS (apesar do fato de que é assim que tudo é indexado). Porque agora você tem uma tabela de 3 colunas com Nome, Usuário e Pai. User é uma chave estrangeira para uma tabela de usuários e Parent é uma chave estrangeira anulável que se auto-faz referência (anulável porque o diretório raiz não pôde ter um pai). Então, qual é a chave primária? Nesse caso, é uma chave composta em todas as colunas ... O que de repente faz de Parent nosso pior inimigo.

Agora, pense em como você colocaria isso em alguma forma de armazenamento de documentos? Em vez de combater os dados, você pode trabalhar com eles e armazená-los como a estrutura da árvore, que por sua vez diminuirá o tempo de desenvolvimento e os custos de manutenção. Se você está diminuindo os custos, isso não permite um tipo diferente de escalabilidade? Além disso, neste caso, você está criando o sistema corretamente desde o início, o que deve dar mais flexibilidade ao próprio aplicativo. Atualmente, estou executando isso em um único servidor usando o MongoDB, que, como você explicou, me fornece um modelo Disponível e Consistente que não é muito diferente do que observar a diferença entre MySQL ou Postgres.

Com o MongoDB, pelo menos, você pode definir com quantos servidores você precisa se comunicar para que uma consulta seja bem-sucedida. Sim, você pode convertê-lo em um modelo Disponível e Consistente, se você solicitar que todas as consultas se comuniquem com todas as instâncias do servidor.

Então, acho que você tem o direito de que há um grande benefício em como os dados são armazenados. Há coisas que não se encaixam bem em um modelo relacional que se encaixam bem em outros modelos (como outro breve exemplo, a Amazon usa alguma forma de banco de dados de gráficos como mecanismo de recomendação para produtos).

Entendi sua pergunta corretamente?

Edit: Mais dados vão atrasar as coisas? Sim. Quanto vai atrasar as coisas? Sinceramente, não tenho experiência suficiente para dar uma resposta adequada. Chave / valor: essencialmente uma tabela de pesquisa com grandes quantidades de dados associados à chave de pesquisa. Isso será realmente muito rápido, porque você só pode procurar as coisas pela chave. Coluna / Família: Essencialmente, um armazenamento de Chave / Valor muito mais estruturado. Você pode consultar apenas com base na coluna e, portanto, isso também deve ser muito rápido. Documento: Esquema de estilo de agregação. Aqui você deseja agregar dados semelhantes. A desnormalização está ok e é esperada para esse tipo de banco de dados. Dependendo de você estar fazendo muitas gravações ou leituras, você pode organizar seus dados para que sejam distribuídos por vários shards para distribuir as gravações ou as leituras (observe que você pode criar uma abordagem híbrida que seja boa para ambos, mas geralmente você precisa escolher a otimização para um ou outro) Gráfico: A força deste é que ele pode criar e derrubar relacionamentos muito rapidamente. Se você possui alguns dados em que possui relacionamentos que precisam mudar entre os dados (pense em alguma forma de mecanismo de recomendação), use-o.

Como você armazena dados em qualquer um desses bancos de dados influenciará o desempenho (semelhante ao fato de que se você armazenar dados incorretamente em alguns RDBMS, eles influenciarão o desempenho). Portanto, para tornar isso mais claro, esperamos que você precise saber qual sistema de banco de dados você deve usar e como armazenar dados nesse sistema de banco de dados.