Em que tamanho de dados se torna benéfico mudar do SQL para o NoSQL?

Como programador de banco de dados relacional (na maioria das vezes), li artigos sobre como os bancos de dados relacionais não são dimensionados, e as soluções NoSQL, como o MongoDB. Como a maioria dos bancos de dados que desenvolvi até o momento é de pequena e média escala, nunca tive um problema que não tenha sido resolvido por alguma indexação, otimização de consulta ou redesenho de esquema.

Com que tipo de tamanho eu esperaria ver o MySQL lutando. Quantas linhas?

(Eu sei que isso vai depender da aplicação e do tipo de dados armazenados. Aquele que me chamou foi basicamente um banco de dados de genética, portanto, haveria uma tabela principal, com 3 ou 4 tabelas de pesquisa. A tabela principal conterá entre outras coisas, uma referência cromossômica e uma coordenada de posição.É provável que seja consultado um número de entradas entre duas poções em um cromossomo, para ver o que está armazenado lá).

Qual o tamanho dos dados?

Existem dois limites significativos:

1. dados completos cabem na RAM
2. todos os dados do índice se encaixam na RAM

Com SSDs rápidos, o primeiro limite se tornou um pouco menos problemático, a menos que você tenha um tráfego alto e louco.

Acidez

Um dos problemas com o dimensionamento de RDBMSes é que, por design, eles são ACID, o que significa transações e bloqueios de nível de linha (ou mesmo nível de tabela em alguns RDBMSes mais antigos / mais simples). Pode ser um fator limitante se você tiver muitas consultas modificando muitos dados em execução ao mesmo tempo. As soluções NoSQL geralmente usam um modelo de consistência eventual .

Como o RDBMS é escalado no tamanho dos dados?

Não é inteiramente verdade que o RDBMS não pode ser dimensionado no tamanho dos dados, existem duas alternativas: particionamento vertical e horizontal (também conhecido como sharding).

O particionamento vertical é basicamente manter tabelas não relacionadas em servidores de banco de dados separados, mantendo assim o tamanho de cada um abaixo dos limites mencionados acima. Isso torna a junção dessas tabelas usando SQL simples menos direta e menos eficiente.

Sharding significa distribuir dados de uma tabela entre vários servidores, com base em chaves específicas. Isso significa que, para pesquisas, você sabe qual servidor consultar com base nessa chave. No entanto, isso complica consultas que não são pesquisas na chave de fragmentação.

No caso de ambos os tipos de particionamento, se você for a extremos, basicamente acaba com a mesma situação que os bancos de dados NoSQL.

Não acho que o tamanho dos dados seja o único fator. "Modelo de dados" também é uma parte muito importante.

As páginas do catálogo de comércio eletrônico (Solr, ElasticSearch), dados de análise da web (Riak, Cassandra), preços das ações (Redis), conexões de relacionamento nas redes sociais (Neo4J, FleetDB) são apenas alguns exemplos quando uma solução NoSQL realmente brilha.

IMHO, o modelo de dados tem um papel mais importante que o tamanho dos dados ao considerar uma solução NoSQL ou RDBMS.

Se os bancos de dados relacionais não escalam, nada faz. Não se preocupe com problemas de dimensionamento.

O SQL tem problemas com alguns tipos de análise, mas não são necessários muitos dados para acionar o problema. Por exemplo, considere uma única tabela com uma coluna que faça referência a outras linhas com base em uma chave exclusiva. Normalmente, isso pode ser usado para criar uma estrutura em árvore. Você pode escrever instruções SQL rápidas que fazem referência à linha relacionada. Ou a linha relacionada da linha relacionada. Na verdade, você pode fazer qualquer número específico de saltos. Mas se, para cada linha, você deseja selecionar um campo na primeira linha relacionada da cadeia que atenda a algum critério, fica complicado.

Considere uma tabela de locais de escritórios nos níveis de país, província / estado, município, cidade e vila, com cada escritório referenciando o escritório ao qual se reporta. Não há garantia de que o escritório de relatórios de cada escritório esteja apenas um nível acima. Para um conjunto selecionado de escritórios, nem todos em um nível, você deseja listar o escritório nacional associado de cada um. Isso requer loops de instruções SQL e levará muito tempo até hoje. (Eu costumava ter 30 segundos em uma seleção de 30 escritórios, mas isso foi há muito tempo - e mudar para procedimentos armazenados ajudou um pouco.)

Portanto, a alternativa é colocar toda a estrutura em um grande bloco de dados, rotular e armazenar. Quando quiser analisar os dados, leia tudo na memória de uma só vez, configurando indicadores para rastrear a estrutura e você poderá processar alguns milhões de escritórios em um piscar de olhos.

Nada disso tem muito a ver com a quantidade de dados. A chave é a natureza da organização dos dados. Se um layout relacional ajudar, então um RDBMS é o que você deseja. Caso contrário, algum tipo de armazenamento em massa será ligeiramente mais rápido que um quatrilhão de vezes.

Observe que, se um desses conjuntos de dados se tornar muito grande para caber na memória, seu banco de dados não-SQL não funcionará mais. Outro problema é quando você precisa de dados de mais de um bloco por vez; você pode fazer isso se , e somente se, todos os blocos couberem na memória de uma só vez. E o usuário tem que esperar enquanto você os carrega.

Se o seu banco de dados relacional lhe causar problemas, ele será feito antes de você colocar muitos dados nele. O único problema de dimensionamento que você pode ter é com o seu programa quando o bloco de dados que você está montando para um banco de dados nosql - se você precisar usá-lo - se torna grande demais para ele. (Leia sobre erros de falta de memória. Os idiomas mais novos às vezes fazem coisas estranhas com a memória.)

Acho que o primeiro motivo para acessar uma solução NoSQL ou Distribuída não é tanto o tamanho de todos os dados, mas o tamanho das tabelas. O que as soluções distribuídas fazem bem é dividir as tabelas em diferentes nós; quando você precisar consultar as tabelas, cada nó processará sua parte da tabela.

Os RDBMSs podem fazer isso, mas a nova onda de bancos de dados NoSQL foi criada para fazer isso. Oracle, MSSQL, MySQL pegaram seu modelo centralizado e o aprimoraram para fazê-lo funcionar em um ambiente distribuído. No entanto, eles ainda seguem regras estritas de ACID, enquanto alguns dos novos bancos de dados não seguem regras estritas, como o uso de consistência eventual.

Não há uma quantidade definida de dados em que você deve escolher um sobre o outro. O que precisa ser levado em consideração são as necessidades do banco de dados e a quantidade de uso que ele recebe. Os bancos de dados NoSQL podem processar conjuntos de dados maiores mais rapidamente, enquanto os bancos de dados relacionais dão a você a confiança de que seus dados estão corretos com os princípios do ACID.

Também vale a pena mencionar que seu modelo de dados tem uma grande influência sobre as coisas. Se você precisar criar alguma forma de estrutura em árvore (ou seja, você tiver uma chave estrangeira auto-referente em uma tabela que contenha a chave estrangeira em uma chave primária composta), provavelmente deverá fazer isso em algum tipo de banco de dados que lida com esses tipos de dados muito bem (como mongodb ou couchdb).

Como outras pessoas disseram, você também deve levar em consideração o que está acontecendo no seu aplicativo. se você realmente precisar de ACID em várias tabelas, precisará realmente usar um RDBMS, mas se tiver algo em que possa ter alguns dados obsoletos e precisar da flexibilidade de um esquema NoSQL (chame-o sem esquema, se quiser, mas sim ainda possui alguma forma de esquema implícito), então você pode considerar comprar uma loja NoSQL ( http://www.10gen.com/customers/craigslist) aqui está um exemplo de por que o craigslist mudou ... mas é certo que eles estão arquivando ~ 10 TB de que eu sei que não se encaixam no tamanho de seu banco de dados, de tamanho pequeno a médio. Mas o caso de uso pode ser útil).

Lembre-se de que os sistemas NoSQL não estão necessariamente lá para substituir os RDMSs, mas, em muitos casos, você pode complementar seu RDBMS com a idéia de Polyglot Persistence e pode armazenar a maioria dos seus dados em um RDBMS, mas em casos específicos de nicho, pode descarregar alguns de seus dados para alguma forma de armazenamento NoSQL.

Mongopode ser instalado em vários computadores / nós. PostgreSQLnão fornece ferramenta interna para sharding, no entanto, o citus existe.

O MongoDB suporta bancos de dados de até 64 terabytes e o tamanho do documento é de 16 megabytes.

O MySQL possui um limite de banco de dados de 256 terabytes, 64 terabytes do tamanho máximo de uma tabela e limite de registro de 4 gigabytes

O PostgreSQL não tem limite no banco de dados (existem 4 terabytes em algum lugar para teste) e um limite de 1 gigabyte para o tamanho de qualquer campo em uma tabela e novamente 64 terabytes para o tamanho máximo de uma tabela.